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."