Subject: RE: [nemo] Comments on draft-ietf-nemo-ro-problem-statement-00.txt

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 7 Jul 2005 12:00:48 +0200

Hi Carlos

Thanks a lot for your review :)

>>
>> - Section 2.1. I would add some comments on TCP performance in the
>> paragraph that deals with the longer route leading to increased delay...
>> The increased delay has not only a significant effect on real-time
>> multimedia streaming applications (here the effect of the delay is more
>> obvious and maybe it is the kind of application most affected, but it is
>> not the only one). The delay has also a severe effect on the obtained
>> throughput by TCP applications, since the throughput is related to the
>> RTT, therefore, if the RTT is inflated due to the MRHA tunnel, then an
>> application may experience a low TCP throughput compared to hosts that
>> communicate directly. Then, if a Route Optimisation mechanism allows to
>> overcome this tunnel (and reduce the delay) that would help at improving
>> the overall TCP performance. We have performed some measurements in a
>> testbed, showing the performance decrease.
>>
>You are right. We would add something there too.  About your test
>results, any paper we can reference?
>
[<PT>] The 2 usual things, rate and latency. 

At a given rate, the window size must be big enough to cover the latency, like window >= rate * TAT-delay. In particular, if one router on the way is responsible for the rate limitation (say it has a slow link) then it will also be the queueing point where all the extra (window - rate * TAT-delay) will be queued up. 

So if TCP windows is too large on the host, this router queue builds up and he enters random early discard. In turn, this causes TCP to backoff and the end point of the connection.

As a result, if the window is too large, then additional latency would reduce the queueing at the congestion point, if it is common to RO and non RO path. Which is the case of the mobile router egress interface...

So it's not really simple :)

Pascal

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 07 Jul 2005 14:45:58 +0200

Hi Pascal,

Please, see comments inline.

> As a result, if the window is too large, then additional latency would reduce the queueing at the congestion point, if it is common to RO and non RO path. Which is the case of the mobile router egr…

Maybe I've not understood you well. Let's me explain again. The case I had in mind, as an example, is the following (btw, it is one of the scenarios we have tested):

     "slow"             ============
 CN -------- R ---- R --| Internet |-- R -- HA
      link   O          ============
            O O
           O   O
          o     o
         o       o
        ·         ·
        |         |
      IPv6       MR -- MNN
      host        

In the previous scenario, the performance obtained by the MNN compared with the one obtained by the "non-mobile" IPv6 host (for example when both are downloading a file from the CN) is significantly better than the one obtained by the MNN. We also tested to vary the delay introduced by the "Internet" cloud to check how this affects the performance of the MNN.

We also performed tests enabling our approach of RO in the NEMO, and in that case the performance obtained was much better. Therefore, I don't get what you said about same performances in the RO and non-RO paths. Could you please clarify me this?

> So it's not really simple :)

Fortunately! no complexity, no fun! :-)

Kind Regards,

Carlos J.

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: BFF1 7C7A 6AA7 BCE3 885A  4DF1 ED0C 5952 BF89 B974