From rbt at alum.mit.edu Mon Jan 4 08:17:22 2010 From: rbt at alum.mit.edu (Brough Turner) Date: Mon, 04 Jan 2010 08:17:22 -0500 Subject: [Rooftops] NxtGen mesh to support an end run around ILECs? In-Reply-To: <3c62cd100912231152r5e3718d7hc0a8adf9c93ceee5@mail.gmail.com> References: <4B326F12.8050209@alum.mit.edu> <3c62cd100912231152r5e3718d7hc0a8adf9c93ceee5@mail.gmail.com> Message-ID: <4B41EA62.3060008@alum.mit.edu> Thanks Jack, Sorry I've been mostly offline during the holidays - back now. The reason I'm now interested in mesh (versus a few years ago) is I believe we're on the verge of being able to make a dense mesh of links, each with >100 Mbps capacity. Such a mesh could provide more than just a "secondary" connection (although I concede I don't know what sorts of SLAs are plausible). In any event, I'd be very interested in talking (and will contact you off-list). Thanks, Brough On 12/23/09 2:52 PM, Jack Boyle wrote: > I am interested in this discussion. My company provides IT support to > downtown businesses and we have access to many buildings. Some of my > clients might be interested in a secondardy Internet connection in > case primary connection fails. Not sure how many users a mesh network > would support but it could be enough for a few users during an emergency. > best, > jack > > On Wed, Dec 23, 2009 at 2:27 PM, Brough Turner > wrote: > > If there is anyone left on this list who is still interested in > Internet > connectivity or wireless mesh networks, I'm an engineer/ entrepreneur > investigating the feasibility of doing a wireless end run around the > duopoly here in the US. So far this is an investigation only - > I'm not > to the point of a business plan, but I'm getting rather optimistic. > > I'm looking for useful people to bounce ideas off. I'm also > running an > event during IAP: http://student.mit.edu/searchiap/iap-a194.html > > My theses: > > There is a 20x cost difference between Internet connectivity at a > competitive IXP like One Summer Street in Boston and buildings > even one > block away. This creates enough of a gap to support a services > business > based on a freemium business model and BYOC (bring your own capital, > i.e. subscribers purchase mesh nodes). > > There's the potential for a 100x increment in mesh performance, at > least > in dense urban areas, because: > While 5 GHz is absorbed by masonry, there is significant difference > in propagation through air or glass btwn 5 GHz, 2.4 GHz or 700 MHz. > MIMO makes 5 GHz more valuable than lower frequencies, at least in > dense urban areas where MIMO is effective. > There's vastly more spectrum available at 5 GHz (11 - 40 MHz > channels > versus 3 - 20 MHz channels at 2.4 GHz). > DSP controlled beamforming significantly improves MIMO performance > DSP controlled beamforming achieves the performance and SDMA > advantages of highly directional antennas without requiring > professional > or enthusiast installers. > 802.11n today and 802.11ac in the future are leading silicon vendors > to incorporate ever higher order MIMO and software controlled > beamforming. > > If there is anyone here on this list who's interested in talking, my > contact info is below. (You're also welcome to attend the January > 27th > IAP event). > > Thanks, > Brough > > Brough Turner > Ashtonbrooke.com > Mobile: +1 617 285-0433 Skype: brough > Also: broughturner at gmail.com > Web: http://www.broughturner.com/ > Blog: http://blogs.broughturner.com/ > > _______________________________________________ > Rooftops mailing list > Rooftops at mit.edu > http://mailman.mit.edu/mailman/listinfo/rooftops > > > -- > > Jack Boyle > (617) 894-1282 > CleverMinds, Inc. | 77 Franklin St, Suite 300 Boston, MA 02110 > Help Desk Hotline (617) 848-8978 > www.cleverminds.net | Small Business > Technology Experts -- Thanks, Brough Brough Turner Ashtonbrooke.com Mobile: +1 617 285-0433 Skype: brough Also:broughturner at gmail.com Web:http://www.broughturner.com/ Blog:http://blogs.broughturner.com/ From rbt at alum.mit.edu Mon Jan 4 10:53:21 2010 From: rbt at alum.mit.edu (Brough Turner) Date: Mon, 04 Jan 2010 10:53:21 -0500 Subject: [Rooftops] I assume In-Reply-To: <200912300154.UAA27134@out-of-band.media.mit.edu> References: <200912300154.UAA27134@out-of-band.media.mit.edu> Message-ID: <4B420EF1.3050206@alum.mit.edu> Thanks Lenny, Sorry for the long holiday delay here, but I'm back now... I agree that existing mesh networks have significant problems with latency. There are at least two significant issues here. The largest has been serialization delay for which one thinks of cut through routing schemes. The second is wireless layer retransmissions. I'm not an expert on Wi-Fi as yet, but this is a significant issue in HSPA mobile networks (like AT&T's) as the necessary extra buffer length at the RNC significantly increases RTTs during periods of congestion (a current problem for iPhones in the US). My (perhaps naive) approach is the brute force one, i.e. drive up useful link speeds so multiple hops are not important. At >100 Mbps per link, a 1500 byte packet sees a fraction of one millisecond of added latency per node. With multiple radios on discrete channels, MIMO and beamforming, this seems possible. It's the potential for high capacity links that aroused my interest in meshes (at least in a new generation of meshes) and that high capacity should also be the cure for latency issues of the past. Thanks, Brough On 12/29/09 8:54 PM, Lenny Foner wrote: > Every time I think about this sort of thing, I worry about latency. > An RF mesh tends to have a lot of hops. Even if you start transmitting > on the next hop as soon as you can, you still have to get enough of a > packet preamble to know which of your (virtual?) beams to send it on. > That means that each hop adds some amount of latency that's hard to > get around, even if it's only a few bits of header (and not, say, > all the bits of a large packet). > > Mitigating factors of course include: > (a) Assume users aren't using ssh. (I do, but I'm a fossil.) > [And assume that Skype traffic will instead use the real trunks? > Ick. So there's a case millions use where real latency will > really matter. Simple web browsing may be one of them, too, alas.] > (b) Any increment in bits/second on the links shortens the amount of > time you have to wait for that preamble, so speak as fast as you > can. You'd want that anyway, of course. :) > (c) Any increment in hop length helps. Of course, this has a direct > bearing on (b). Even with beamforming, at some point you'll hit > annoying limits (or obstacles :). > (d) Assign flow tags that can be abbreviated to a very few bits, and > preface packets with them. Won't help you for a coast-to-coast > UDP query (think DNS), but those are rare. Will help you for > virtual circuits, which describe most of the cases where latency > gets noticeable (ssh, voice, etc). This is analogous to Van > Jacobson compression back when 9600 bps modems were all the rage; > the idea would be to use Huffman coding (for example) to identify > streams, with some hacks for flushing old state so you only have > to identify a few (dozens? hundreds?) of streams per node at any > given time. I'll bet a careful reading of the literature would be > rewarding; I'd be shocked if there isn't a ton of research on this > sort of thing. This must be Cisco's bread& butter. Zigbee might > also be rewarding to study for whatever it does; have you? > > Doing (d), in particular, assumes you can get bits as they come in > from the RF system---not after they've all be received and a packet > checksum has been computed. Does typical 802.whatever HW allow this > under any circumstances? Possibly, given Airsnort et al. And what > are the implications of noise in the channel? [Maybe you start > forwarding as soon as you think you know where the packet's going, > with an oops-never-mind-abort if some really short& simple flow > checksum comes along later and you realize you had noise, and another > never-mind-I-really-blew-it if the packet checksum fails at the end. > And if noise is rare, maybe you just don't bother letting go of the > channel early& just let the receiver drop it if a checksum's wrong. > But probably that means one error early on ripples through a -lot- of > hops before everyone abandons it, so it could cost you bandwidth.] > > I also wonder if it could ever pay off to have that preamble be > a different RF modulation---using more bandwidth or more power or > whatever to get it out faster, in the assumption that even though > you're degrading the rest of the channel slightly, the decrease in > latency is worth it. May not be worth the added RF complexity, > though. [But it might: 20 bits of header means 20 bits of delay > per hop, plus one bit of delay per hop for the payload, assuming > optimality. So either making that header shorter, or speaking it > faster, might have a big multiplier on end-to-end latency. Absolutely > don't use uncompressed TCP! 40 bytes/hop, minimum. Bleah.] > -- Thanks, Brough Brough Turner Ashtonbrooke.com Mobile: +1 617 285-0433 Skype: brough Also: broughturner at gmail.com Web: http://www.broughturner.com/ Blog: http://blogs.broughturner.com/ From jim at media.mit.edu Thu Jan 21 19:47:41 2010 From: jim at media.mit.edu (Jim Youll) Date: Thu, 21 Jan 2010 16:47:41 -0800 Subject: [Rooftops] NxtGen mesh to support an end run around ILECs? In-Reply-To: <4B41EA62.3060008@alum.mit.edu> References: <4B326F12.8050209@alum.mit.edu> <3c62cd100912231152r5e3718d7hc0a8adf9c93ceee5@mail.gmail.com> <4B41EA62.3060008@alum.mit.edu> Message-ID: <38DD23A4-5747-4F12-8D53-06584192B7A0@media.mit.edu> I've been traveling (and carrying this heavy thread around in my laptop cross-country and back a few times). Now that i'm wanted to point you guys to work that suggests that your concerns can be overcome... in real networks, that operate right now Funkfeuer Free Net http://funkfeuer.at/index.php?id=42&L=1 map of the network: https://map.funkfeuer.at/wien/ slides that don't say a lot: http://freedom-to-connect.net/2009/04/presentations-from-f2c09/ http://www.slideshare.net/f2c/aaron-kaplan http://cyber.law.harvard.edu/node/5154 On Jan 4, 2010, at 5:17 AM, Brough Turner wrote: > Thanks Jack, > Sorry I've been mostly offline during the holidays - back now. > > The reason I'm now interested in mesh (versus a few years ago) is I > believe we're on the verge of being able to make a dense mesh of links, > each with >100 Mbps capacity. Such a mesh could provide more than just > a "secondary" connection (although I concede I don't know what sorts of > SLAs are plausible). > > In any event, I'd be very interested in talking (and will contact you > off-list). > > Thanks, > Brough > > > On 12/23/09 2:52 PM, Jack Boyle wrote: >> I am interested in this discussion. My company provides IT support to >> downtown businesses and we have access to many buildings. Some of my >> clients might be interested in a secondardy Internet connection in >> case primary connection fails. Not sure how many users a mesh network >> would support but it could be enough for a few users during an emergency. >> best, >> jack >> >> On Wed, Dec 23, 2009 at 2:27 PM, Brough Turner > > wrote: >> >> If there is anyone left on this list who is still interested in >> Internet >> connectivity or wireless mesh networks, I'm an engineer/ entrepreneur >> investigating the feasibility of doing a wireless end run around the >> duopoly here in the US. So far this is an investigation only - >> I'm not >> to the point of a business plan, but I'm getting rather optimistic. >> >> I'm looking for useful people to bounce ideas off. I'm also >> running an >> event during IAP: http://student.mit.edu/searchiap/iap-a194.html >> >> My theses: >> >> There is a 20x cost difference between Internet connectivity at a >> competitive IXP like One Summer Street in Boston and buildings >> even one >> block away. This creates enough of a gap to support a services >> business >> based on a freemium business model and BYOC (bring your own capital, >> i.e. subscribers purchase mesh nodes). >> >> There's the potential for a 100x increment in mesh performance, at >> least >> in dense urban areas, because: >> While 5 GHz is absorbed by masonry, there is significant difference >> in propagation through air or glass btwn 5 GHz, 2.4 GHz or 700 MHz. >> MIMO makes 5 GHz more valuable than lower frequencies, at least in >> dense urban areas where MIMO is effective. >> There's vastly more spectrum available at 5 GHz (11 - 40 MHz >> channels >> versus 3 - 20 MHz channels at 2.4 GHz). >> DSP controlled beamforming significantly improves MIMO performance >> DSP controlled beamforming achieves the performance and SDMA >> advantages of highly directional antennas without requiring >> professional >> or enthusiast installers. >> 802.11n today and 802.11ac in the future are leading silicon vendors >> to incorporate ever higher order MIMO and software controlled >> beamforming. >> >> If there is anyone here on this list who's interested in talking, my >> contact info is below. (You're also welcome to attend the January >> 27th >> IAP event). >> >> Thanks, >> Brough >> >> Brough Turner >> Ashtonbrooke.com >> Mobile: +1 617 285-0433 Skype: brough >> Also: broughturner at gmail.com >> Web: http://www.broughturner.com/ >> Blog: http://blogs.broughturner.com/ >> >> _______________________________________________ >> Rooftops mailing list >> Rooftops at mit.edu >> http://mailman.mit.edu/mailman/listinfo/rooftops >> >> >> -- >> >> Jack Boyle >> (617) 894-1282 >> CleverMinds, Inc. | 77 Franklin St, Suite 300 Boston, MA 02110 >> Help Desk Hotline (617) 848-8978 >> www.cleverminds.net | Small Business >> Technology Experts > > -- > Thanks, > Brough > > Brough Turner > Ashtonbrooke.com > Mobile: +1 617 285-0433 Skype: brough > Also:broughturner at gmail.com > Web:http://www.broughturner.com/ > Blog:http://blogs.broughturner.com/ > > _______________________________________________ > Rooftops mailing list > Rooftops at mit.edu > http://mailman.mit.edu/mailman/listinfo/rooftops