[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
shim - transport/network communication
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
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...