[Cu-wireless] HSLS?

[Joe Pickert]

Hi Dave,

I certainly think HSLS will need some adaptive tuning. In the long term,
if the local cloud includes enough resources (whatever "local" happens to
mean), perhaps gateway selection becomes a non-issue or easy to fix. In
the short term, however, I am thinking about making the network usable
enough that participants don't throw up their hands in frustration. I may
be wrong, but initially this means virtually 100% internet-centric usage.

Toward this end, I think it should be as simple as possible for people or
businesses to "donate" usage of their hardwired bandwidth when they don't
need it, and take it back when they do. So, if a gateway can advertise
itself and its excess capacity "schedule" (e.g., you can use 0% of my T1
line from 8am-5pm, 40% from 5pm-10pm, etc.), then I think getting gateways
on board becomes a lot easier. Of course, they must also be able to change
the advertised shedule with little or no notice.

In this scenario, I don't think most current heuristics (that I know of
anyway) will work very well because they assume relatively static
gateways and centralized authority(s). The selection mechanism needs to be
decentralized and dynamic. I am sure this issue must be addressed in the
literature somewhere. Anyone have any pointers?

Joe

On Mon, 8 Mar 2004, David Young wrote:

> On Mon, Mar 08, 2004 at 05:25:22PM -0600, Joe Pickert wrote:
> > Having just jumped on the bandwagon, I was reading the BBN paper on HSLS.
> > A number of things struck me, but I most wonder about a couple of the
> > assumptions in this algorithm with respect to its expected performance.
> > A.5 (as network size increases, node generated traffic remains constant)
> > and A.6 (all possible node destinations are equiprobable) do not seem to
> > hold (even in the abstract) for the cuwireless topology, as I understand
> > it anyway. Rather it seems that a relatively small subset of nodes (those
> > with the broadband connections to the "outside") will see significant
> > increases in traffic as the network topology size increases, and that
> > traffic to and from these "gateway" nodes must be handled with the utmost
> > overall efficiency, while the routing of the pedestrian traffic between
> > the other nodes is much less crucial (maybe even totally unimportant in
> > terms of bandwidth usage). This topology seems to argue for some variation
> > of a gateway routing protocol (i.e., where gateways confer with each other
> > to develop routing tables that equalize traffic and maximize bandwidth). I
> > have just starting reading through the grant, so if this is addressed in
> > there, I will eventually find it. Otherwise, can someone clarify?
> 
> We certainly do anticipate a lot of Web-browsing, e-mail, FTP downloads,
> ssh, and other Internet-centered uses for the network, and I think that
> under "Internet-centric" loads, you are right that A.5 and A.6 will not
> both hold for any single node. Maybe some fine-tuning of HSLS will be
> necessary to achieve optimal scalability. What do you think?
> 
> BTW, we hope that a high-speed community network will foster the use and
> development of peer-to-peer applications, support local IP telephony,
> home & business web-publishing, etc. Traffic like that will tend to meet
> the assumptions unless and until our network starts to show "Slashdot
> effects."
> 
> It seems to me that your general concern is that gateway selection
> will be suboptimal using HSLS. We don't actually intend to let HSLS
> select gateways.  In our present thinking, the HSLS "cloud" will be
> "default-free," because there can be bad consequences having to do with
> NAT and 6to4 when a router sees two or more default routes and flip-flops
> between them. Gateway selection looks like a complicated function,
> and we are going to have to shake-out a few ideas before we hit on the
> right solution.  Right now, we think that our Gateway Selector module (you
> will not find it in the grant) will choose gateways according to both the
> path metric and heuristics designed to keep us from "flapping" between
> gateways. The module will create a tunnel to its chosen gateway. If
> gateways will confer to "equalize traffic and maximize bandwidth,"
> I think that they will do it through the Gateway Selector.
> 
> I am hopeful that some equalization and maximization of bandwidth will
> happen just by virtue of nodes choosing gateways with better metrics.
> 
> Dave
> 
> -- 
> David Young             OJC Technologies
> dyoung at ojctech.com      Urbana, IL * (217) 278-3933
> 
> _______________________________________________
> CU-Wireless mailing list
> CU-Wireless at lists.groogroo.com
> http://lists.cu.groogroo.com/cgi-bin/listinfo/cu-wireless
> Project Page: http://cuwireless.ucimc.org
>