Shim6, was: Re: filtering /48 is going to be necessary

Tue Mar 13 17:26:10 UTC 2012

2012/3/13 Masataka Ohta <mohta at 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 at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004