[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RAM] Re: the separation of ID/RLOC

On 9-jul-2007, at 11:59, Christian Vogt wrote:

1. It's doubtful that detecting, let alone restoring, a failure within
an RTT is doable. If it is, the costs of doing so will be significant.

You are raising an interesting point. The process of detecting failure
of a provider may indeed be a bottleneck today.

Actually, this is the easy part, because you can simply send hello packets at a pretty high rate across a link. Or even better: let a watchdog timer go off when no packets have been received for a certain time. The latter has the advantage that you don't need to inject keepalives when there is real traffic and you aren't bound by round trip time speed. (Which isn't too bad for a single layer 2 link in almost all cases, though, especially if you can get rid of the variability by bypassing any queues for the keepalives.)

But we were talking end-to-end, or at least across a number of links. This means the keepalive traffic explodes and there are no longer any interface-specific tricks that can be done for optimization.

One possible improvement would call for an edge network operator to
redirect part of its traffic to an alternative provider as the delays
incurred by the current primary provider increase.


This is susceptible to oscillations.

In my opinion, the correct way to handle this stuff is with multipath transport protocols.

2. When you lose part of your connectivity, a substantial reduction in
the traffic offered to the network is exactly the appropriate response.

If you have an alternative provider to switch to, then it would be good 

This sounds very much like optical restoration to me.  :-)

With IP, "backup" paths are rarely idle when the "primary" path is active, so loss of the path that's currently used means a reduction of total available bandwidth which can easily reduce this to less than the amount of traffic generated. So backing off until a new equilibrium is found is a good idea.

if the mapping function would allow you to do this quickly enough to not
impact ongoing communications too much.

If you were using a TCP-like transport protocol that works over multiple paths at the same time, you'd already have RTT times and window sizes for the other path so switching could happen without reducing bandwidth more than necessary. And load balancing would happen automatically.

_______________________________________________
RAM mailing list
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram