[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RAM] Re: the separation of ID/RLOC
Dino:
>> update speed and reliability of the mapping function are not just needed
>> for access network mobility. Its also needed for provider fail-over.
>
> It is needed as well for regular packet forwarding when nodes are
> stationary.
Exactly. You might allow for a bit more delay in the mapping update if
a provider change is not critical because the old provider still works.
But for fail-over, you really want to be quick.
>> Access network operators want to be able to switch providers quickly
>> when one goes down. This is one of the main goals for multi-homing.
>
> For what value of "quickly"? Please quantify.
I am looking at this from the perspective of a pair of communicating
hosts. A provider change initiated by either host's edge network
operator will lead to delay and packet loss, and both should be small.
Let's take a look at the typical case of a TCP connection. Here we will
see substantial throughput degradations after a provider change if the
delay is more than 1 RTT: Since TCP's retransmission timeout period is
1 RTT (plus variability), the sending TCP will run into two successive
retransmission timeouts. This means that the congestion window and
slow-start threshold will be set to 1 and 2 packets, respectively. TCP
then cannot recover in slow-start mode (which would be efficient), but
only in congestion avoidance mode (which is highly inefficient,
especially if you start with a congestion window of 1).
If the delay caused by a provider change can be limited to 1 RTT, then
TCP will run into only a single retransmission timeout, and it will
efficiently recover in slow-start mode afterwards. So my preferred
definition of "quickly" is 1 end-to-end RTT.
Whether or not long update delays are an issue depends, as you say, on
the change frequency and granularity. However, any assumptions that we
make in this regards should be very careful. Our goal is to give edge
networks more freedom in traffic engineering and provider selection.
And it would be great if we could reach this goal without restrictions
-- such as in terms of change frequency or granularity.
Best,
- Christian
_______________________________________________
RAM mailing list
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram