On Sun, 15 May 2005, Haudy Kazemi wrote:

> 4.) have a way to contribute to/participate in the system without requiring
> subscribing and monthly fees.  For this I suggest that current broadband
> users could make their connections publicly available to anyone authorized

This is probably against your ISP's TOS, unless you specifically purchased 
bandwidth for resell.  It would also make it nearly impossible to 
troubleshoot speed and connectivity issues, or provide any sort of 
bandwidth commitment, firewalling, etc.

Also, consider the implications of roaming between AP's (and therefore, 
exitpoints to the Internet).  Any sessions in-progress will terminate, 
since any incoming packets for you will be going to the 1st AP (the 2nd AP 
on a 2nd broadband connection will have a different public IP).  And the 
2nd AP won't have any existing NAT translations for you anyways (assuming 
the device is doing NAT, which it almost certainly would have to)

I would therefore argue that #4 and #6 are mutually-exclusive.  Even if 
that problem could be solved (by using PI space, and having participating 
ISP's that are providing bandwidth announce that space), NAT is still 
impossible because of the translation table problem.  Unless there exists 
a clustered NAT product where all nodes of the cluster maintain copies of 
a single xlate table.  I believe the new PIX v7 can do this, but I don't 
think it scales to this level.

In short, I agree that sharing participant's broadband connections is a 
great idea IN THEORY, but the issues above make it more or less impossible 
to do in practice.

Better would be to route all wireless traffic back to a central exitpoint 
to the Internet, or have a small number of "certified" exitpoints, where 
service levels and billing can be closely monitored and maintained.

<Everything below is off-the-cuff, I haven't thoroughly thought anything 
out.  Comments welcome.>

For instance, the city could colo boxes at a small number of ISP's.  The 
box would have a wireless interface for an antenna on the roof, and would 
BGP peer with the ISP and announce the city's PI space.  The city would 
have 100% control over these boxes, which would facilitate 
troubleshooting, monitoring, and billing (and later, HTTP proxies, 
firewalls, NAT, etc.)

To get even more fancy, (and add a layer of complexity that would arguably 
provide little benefit compared to the headache of maintaining it...) 
These boxes could peer with each other over the wireless network (or more 
likely, with one of a handful of route reflectors, for scalability), and 
the box the user is connected to could make the decision that another box, 
on another ISP's network, has a better route to the destination, and 
re-route the traffic over the wireless, to a different exitpoint. 
Obviously, some traffic would be sent over the wireless twice, but this 
should be "cheaper" bandwidth than the colo bandwidth.

In fact, at this point it starts to make sense to deploy one of these 
boxes with each AP, regardless of if the AP is at an exitpoint or not. 
Then you'd have a BGP speaker at each AP, which would make traffic 
engineering easier.  Each AP would know the best exitpoint to route your 
traffic to, so it only gets routed over the wireless once.

These boxes could also run Asterix (or something), and you could have each 
exitpoint (at a participating ISP) have a VOIP phone to route support 
calls to, so the city wouldn't need to maintain their own helpdesk. 
(This is getting way out of hand)  Since the city would have control over 
the box, it should be easy to fairly distribute support calls, and simple 
to watch #/duration of support calls so the ISP's could be paid 
accordingly.  The techs would have to have some sort of standard training 
and troubleshooting guides, and there'd have to be a shared ticket 
system...yada yada.

All of the above is stream-of-conciousness, I haven't really put the time 
and thought into any of it.  I'm supposed to be working.

Adam Maloney