Hi Jim, it is tempting to write a short mail with some random thoughts about various protocols design aspects. Everyone can do that. That will not get you anywhere. If you want to be understood by others then you have to * write a draft with a consistent story, and * convince others that it is a good idea. >From the way you have posted your messages so far it seems likely that you do not able to develop a consistent story. Sorry to say that. Ciao Hannes On Mar 29, 2012, at 4:37 AM, Jim Fleming wrote: > ZOOM://IETF.Fact.Check > > http://tools.ietf.org/html/draft-montenegro-httpbis-speed-mobility-00 > > "Improving HTTP starts with speed." > > Improving the Inter.NET starts with speed. > > "HTTP Speed+Mobility," > > Locator-ID Separation ? > Locator (60) + ID (68) > 60-bit Symmetric Addressing in the IPv4 160-bit Header > 68-bit Symmetric Addressing in the IPv16 320-bit Header with Data > AAAA DNS ~ 60+68 ~ VRHL+000.T1.111+PORT12+ASN30+FRAG6 + LAN4+60+CPE4 > > "The proposal starts from both the Google SPDY protocol and the work > the IETF has done around WebSockets." > If you start with a HAMMER everything may look like a NAIL. > > Improving the Inter.NET starts with speed. > A Comprehensive (Modern) Architecture may be better than the old > Hammer and Nails? > > Removing TCP may help. > Re-Tooling UDP for Peer-2-Peer may help. > [The 12-bit Port value also rides in the old Identification Field in > the IP Header - are three copies needed?] > 2 Protocol Bits frees up 6 bits for addressing > 4 TTL Bits encourages less hops and frees up addressing bits > Less.is.More may result in Speed > > IPv6 is not built for Speed - Yet people sure are trying to sell it - > Do consumers want it ? > > They may prefer a Net.Work as opposed to a Not.Work > > ZOOM://IETF.Fact.Check "Improving HTTP starts with speed."