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

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 07 Jul 2005 09:08:34 +0200

Hi all,

After taking a look at this I-D I've have some comments.

First of all I want to say that the draft looks pretty good to me. Now
it is closer to achieve the goals that are in the charter.

After saying that, here are my comments:

- 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.

- Section 2.2. I think that this section could be an additional bullet
in Section 2.1. I see the HA being a single point of failure (and the
Home Network a bottleneck) as a direct consequence of the MRHA tunnel
introduced by the NEMO Basic Support protocol, so I don't see why it has
to be in a different subsection.

- Section B. Typo: I think it should be "involve" (second line) instead
of "involves".

- Section B.1.3. I would remove the last paragraph (the one starting
with "Providing Route Optimization..."), since it is related to the
solution space, not to a problem statement.

- Section B.4.3. I would add a comment clarifying that a VMN could also
communicate with a node using its CoA as source address (Mobile IPv6 and
RFC3484 offer also the possibility of using the MN's CoA as source
address). In Case L , there are some communication scenarios that seem
to be very convenient for the VMN to choose its CoA address instead of
its HoA (for example if the communication is known to be short-lived in
advance, like in DNS queries for example).

Thanks a lot for the draft.

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

---

From: Chan-Wah Ng <[email-masked]>
Date: Thu, 07 Jul 2005 16:06:26 +0800

> it is closer to achieve the goals that are in the charter.

Thanks for reading the draft, and your kind comments.

> testbed, showing the performance decrease.
You are right. We would add something there too.  About your test
results, any paper we can reference?

> to be in a different subsection.

True.  The authors had a similar discussion too.  It was my editorial
decision to separate the two, since (1) we don't want to bloat sect 2.1,
and (2) the nature of the problem is slightly different in that sect 2.1
views the problem from the perspective of a single flow and Sect 2.2
view the problem from the home perspective which is the aggregation of
multiple flows. 

One other point worthy of note is that Sect 2.1 will happen to any flow
that pass through the MRHA tunnel, whereas Sect 2.2 may happen only if
there is a lot of flows.  Conversely, the implications of Sect 2.2 is
more severe, as it will affect all flows, even those that does not pass
through any MRHA tunnel.

> - Section B. Typo: I think it should be "involve" (second line) instead
OK.

> solution space, not to a problem statement.
I would discuss this with Watari-san, but I don't see any concern why
not.

> advance, like in DNS queries for example).

OK.

Thanks again for the comments and feedback.

/rgds
/cwng

---

From: Masafumi Watari <[email-masked]>
Date: Thu, 07 Jul 2005 17:56:58 +0900

Hello Carlos,

Thanks for your comments.  Please see my reply inline;

> I would discuss this with Watari-san, but I don't see any concern why

Yes, this should have been removed.
Thanks for pointing this out.

>>advance, like in DNS queries for example).

Right... I missed this one from my previous draft.
Thanks for the reminder.

regards,
watari

---

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

Hi Chan-Wah,

> results, any paper we can reference?

We have already published one [1], that includes some preliminary
results. We have also results from intense testing, but the paper has
just been submitted, so there are no public available results.

Anyway, I can elaborate something (write one or two paragraphs, maybe
summarising also some of our experimental results) so it can be added to
the draft if you think it could be useful and valuable.

Thanks a lot.

Kind Regards,

Carlos J.

[1] A. de la Oliva, C. J. Bernardos and M. Calderón, "Practical
evaluation of a network mobility solution", EUNICE 2005: Networked
Applications - 11th Open European Summer School, July 6-8 2005,
Colmenarejo, Madrid (Spain)