shim - transport/network communication

[Baker Fred <fred@cisco.com>]

On Mar 19, 2005, at 2:02 PM, Miika Komu wrote:
> Maybe you are referring something similar to [HIP]

I might be; that remains to be shown. The spec you pointed me to, 
unless I missed it, gave me no sense of make-before-break behavior in 
the mobility it discussed, and no sense of route optimization in the 
address management it discussed. Show me those, and I might be in your 
game.

When I talk about these things, I am referring to the fact that the 
shared state in a TCP/SCTP/whatever session includes the current 
address pair - when I send, I send from an address and to an address - 
and the pair of addresses I select determines a number of things about 
the connection. Several years ago, in the context of the IAB, I asked 
Geoff Huston to prototype my concerns here - imagine that a machine 
that he is sitting at in Canberra wants to talk with a machine in 
Singapore that has two addresses and the two addresses have wildly 
different routes which result in dramatic differences in delay. He 
prototyped that by doing a traceroute to two systems there, the .sg 
server and www.singtel.com (IIRC). One gave him a ping RTT of ~100 ms, 
and the other gave him a ping RTT of ~650 ms. The difference was a 
direct route vs a route via the US west coast. In the mobility context, 
a device that is in the process of changing its COA has a similar 
issue, except that one of the addresses suddenly has infinite delay. 
RFC 3704 brings other concerns to the table - ingress filtering by ISPs 
can have truly interesting impacts on the routing of address pairs.

I would like the multihoming facility we develop to have the 
characteristic of always picking a pair of addresses, and therefore a 
route, that gives among the best available RTTs (note I didn't say "the 
best"; I want to avoid the worst and accept a reasonable choice) to the 
current instantiation of the exchange.

A simple way to prototype this in a wired network is this. If two 
machines A and B each have sets of addresses A' and B', then the set of 
routes between them is characterized by the cross product of those 
sets. A TCP could send a SYN on each address pair and ACK the first 
SYN-ACK it gets back, RST'ing the rest. This may not be the best route 
long term, but it will be a reasonable one in the near term. There are 
thoughts that come to mind quickly on scaling features of the approach 
(the net already is ~40% TCP control traffic, so I'm told), but as a 
benchmark of a simple way to calculate a reasonable result, it's not 
all bad. I would like the algorithm we use to generate at least as 
reasonable a route.

I find myself wondering whether we could use something akin to an 
ICMPv6 Route Redirect to ask the network to cache such disparities and 
advise a host of a superior next hop and address pair to use at the 
network layer when instantiating a host-host exchange...

In mobility, the counterpart of that issue is in a cell handoff or 
equivalent. There are of course cases where the device simultaneously 
loses connectivity one way and regains it another, resulting in a 
handoff that loses traffic. However, it would be really nice if (as is 
in fact done in at least some telephone models) in some cases we could 
presume that the device was reachable by two addresses and could advise 
its peer that it was in the process of changing. That would allow it to 
continue to receive on the old address for an interval while also being 
willing to receive on the new address, and when the peer made that 
change seeing its data stream change. It would further be nice of it 
could inject advice to its new router interface (which might even be on 
the same router) asking that the old address be temporarily routed by 
the network to that interface, so that even the old-address traffic 
could find its way to the device subsequent to connectivity loss.

I realize I'm asking a lot.

But I don't, I really don't, want the application to have to know 
ANYTHING about that...