[Cu-wireless] HSLS?

[David Young]

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