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

[Carlos Jesús Bernardos Cano <[e-mail]>]

Hi Pascal,

El jue, 07-07-2005 a las 16:45 +0200, Pascal Thubert (pthubert)
escribió: 
> >>
> >> 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...
> >
> >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! :-)
> >
> [<PT>] Could you play with the TCP window size? Maybe it was not enough to cope with the internet latency?

We did not play with that. We just used the default window size that
Linux-2.6 kernels use.

> 
> Was the Internet throughput higher then you "slow" link? If not, then the internet somewhere was your bottleneck and if si, it was prone to be the place for RED.

No, it wasn't. Actually, the "Internet" cloud was also a network of the
testbed, but running some software that allowed us to modify the link
characteristics (latency, bandwidth, etc.)

> 
> Which comes to the next question: Did you have a measure the packet loss over the internet? 

No, that's not needed, since the "Internet" cloud actually is just an
internal network in our lab.

> 
> One good indication to figure out what's going on is to compare the results in TCP and in UDP. Did you toy with that as well?
> 
> As you know, there are many parameters to this equation, and RO will generally - be not always and not for sure give - better performance results.

Yes, of course there are many parameters (TCP is quite complex), but we
were interested in evaluating the effect of having a longer path - since
that's one of the consequences of using the NEMO Basic Support protocol
without RO - in the TCP throughput (and the RTT usually has a
significant effect on the throughput). Additionally, we tried to
evaluate how good was the improvement - in terms of TCP performance - we
could obtain by using a RO approach instead of just the NEMO Basic
Support protocol.

One additional remark: we are considering the scenario in which there
are, besides the MNN, other nodes (not located at the NEMO), competing
(i.e., sharing) the bottleneck ("slow") link. In this case, the flows
with higher RTTs are penalised, thus the increased latency has an
impact.

Kind Regards,

Carlos J.

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