2012/3/13 Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>:
William Herrin wrote:
http://bill.herrin.us/network/bgpcost.html
If you believe there's an error in my methodology, feel free to take issue with it.
Your estimate on the number of routers in DFZ:
somewhere between 120,000 and 180,000 with the consensus number near 150,000
is a result of high cost of routers and is inappropriate to estimate global cost of a routing table entry.
Hi, Please elaborate. In what way is the average cost of routers carrying the DFZ table an inappropriate variable in estimating the cost of the routing system?
Because DFZ capable routers are so expensive, the actual number of routers is so limited.
If the number of routes in DFZ is, say, 100, many routers and hosts will be default free.
If wishes were horses, beggars would ride. The number of routes in the DFZ isn't 100 and is trending north, not south.
Often overlooked is that multihoming through multi-addressing could solve IP mobility too.
Not.
What is often overlooked is the fact that they are orthogonal problems.
I respectfully disagree.
My statement is based on my experience to implement locator/ID separation system with multi-address TCP and IP mobility.
They need separate mechanisms and separate coding.
I've been an IRTF RRG participant and in my day job I build backend systems for mobile messaging devices used in some very challenging and very global IP and non-IP environments. If we're done touting our respective qualifications to hold an opinion, let's get back to vetting the idea itself.
Current mobility efforts have gone down a blind alley of relays from a home server and handoffs from one network to the next. And in all fairness, with TCP tightly bound to a particular IP address pair there aren't a whole lot of other options. Nevertheless, it's badly suboptimal. Latency and routing inefficiency rapidly increases with distance from the home node among other major problems.
That is a mobility issue of triangle elimination having nothing to do with TCP.
Au contraire. Triangle elimination is a problem because the IP address can't change with session survivability. But that's because TCP and UDP require it. If A follows from B and B follows from C then A follows from C: TCP is at fault.
But suppose you had a TCP protocol that wasn't statically bound to the IP address by the application layer. Suppose each side of the connection referenced each other by name, TCP expected to spread packets across multiple local and remote addresses, and suppose TCP, down at layer 4, expected to generate calls to the DNS any time it wasn't sure what addresses it should be talking to.
Ignoring that DNS does not work so fast, TCP becomes "it wasn't sure what addresses it should be talking to" only after a long timeout.
Says who? Our hypothetical TCP can become "unsure" as soon as the first retransmission if we want it to. It can even become unsure when handed a packet to send after a long delay with no traffic. There's little delay kicking off the recheck either way.
And if the node gets even moderately good at predicting when it will lose availability for each network it connects to and/or when to ask the DNS again instead of continuing to try the known IP addresses you can
What? A node asks DNS IP addresses of its peer, because the node is changing its IP addresses?
A re-verify by name lookup kicks off in a side thread any time the target threshold for a certainty heuristic is hit. Inputs into that heuristic include things like the TTL expiration of the prior lookup, the time since successful communication with the peer and the time spent retrying since the last successful communication with the peer. If you have any communication with the peer on any address pair, he can tell you what addresses should still be on your try-me list. If there's a reasonable chance that you've lost communication with the peer, then you ask the DNS server for the peer's latest information.
The only end to end way to handle multiple addresses is to let applications handle them explicitly.
For connection-oriented protocols, that's nonsense. Pick an appropriate mapping function and you can handle multiple layer 3 addresses just fine at layer 4.
It will require the applications perform reverse mapping function, when they require raw IP addresses.
No. The application passes the IP address in a string the same way it passes a name. The layer 4 protocol figures out how it's going to map that to a name. It could do a reverse mapping. It could connect to the raw IP and request that the peer provide a name. There are several other strategies which could be used independently or as a group. But you avoid using them at the application level. Keep that operation under layer 4's control.
For connectionless protocols, maybe.
I'm afraid you are unaware of connected UDP.
Your fears are unfounded.
However, I'm not convinced that can't be reliably accomplished with a hinting process where the application tells layer 4 its best guess of which send()'s succeeded or failed and lets layer 4 figure out the resulting gory details of address selection.
It's a lot easier for UDP-based applications directly manage multiple IP addresses.
I'll say it's fair to call that correct until disproven. However, it's worth noting that UDP is used to implement a lot of protocols which are connection-oriented but have characteristics (such as error tolerance and timely delivery requirements) which are inconsistent with TCP. Multiple address management for such protocols could almost certainly be handled below the application level, same as with other connection-oriented protocols. Regardless of the above, it might actually be worth defining a streaming data protocol to operate in parallel with UDP and TCP instead of being loaded on top of UDP. We probably know enough now Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004