Subject: [nemo] Proposal of some text for draft-ietf-nemo-ro-problem-statement-00.txt

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 06 Sep 2005 17:17:42 +0200

Hi draft authors, and all,

As presented in Paris, it was agreed to include some changes on the the
draft-ietf-nemo-ro-problem-statement-00.txt, to solve some of the issues
raised on the ML. Here I propose some text for discussion:

In the section 2.1, in the part describing "Longer route leading to
increased delay and additional infrastructure load", it is stated that
applications such as real-time multimedia streaming may not be able to
tolerate the increased delay. I'd suggest adding the following:

"Besides, the increase in delay impact also the performance of transport
protocols such as TCP, since the rate at which a TCP nodes send packets
is driven by the congestion control algorithm, which is related to the
RTT perceived by the communication peers. If the RTT is inflated due to
the MRHA tunnel, the effective throughput obtained by an application
will decrease, especially in those cases in which there are several
competing flows sharing a bandwidth-limited link (those flows with less
RTT will obtain higher throughput)".

A minor remark about the effect of increased packet loss probability
when using the MRHA tunnel and the TCP performance may be also included
here (or in the "Increased susceptibility to link failure" subsection).

In the section B.4.3, I'd suggest to add the following text to comment
about the possibility of using the VMN's CoA for communication in
short-term communications:

"The MNN may also decide to use its Care-of Address as the source
address of the packets, thus avoiding the tunnelling with the MNN's HA.
This is particularly useful for a short-term communication that may
easily be retried if it fails. RFC 3484 (Default Address Selection)
provides some mechanisms for controlling the choice of the source
address. An API may also be alternatively used for those applications
running on the MNN that have enough knowledge of the communication being
sent to decide whether to use the MNN's Home Address or the MNN's
Care-of Address as the source address of the packets being sent."

Hope it helps.

Thanks a lot.

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: Masafumi Watari <[email-masked]>
Date: Thu, 08 Sep 2005 11:28:23 +0900

Hello Carlos,

Thanks for providing the text.

> RTT will obtain higher throughput)".

The multiple flows sutff may be more to the bottle neck discussion.
Besides that, I'm positive on adding the text.  I will leave this for
Chan-Wah, but how about;

"In general, the increase in delay also impact the performance of
transport protocols such as TCP, since the rate at which a TCP nodes
send packets is driven by the congestion control algorithm, which is
related to the RTT perceived by the communication peers. If the RTT is
inflated due to the MRHA tunnel, the effective throughput obtained by an
application will decrease."

> here (or in the "Increased susceptibility to link failure" subsection).

I thought we already have some text on the possibility of packet
losses...

> Care-of Address as the source address of the packets being sent."

I would rather not go into the API stuff.  I think the first part is
sufficient for the text here.

thanks again,
watari

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 08 Sep 2005 11:11:58 +0200

Hi Watari,

	Please, see comments inline...

> application will decrease."

	OK, it's fine for me.

> I thought we already have some text on the possibility of packet

	Yes, you have. I meant adding some text in the effect of packet losses
in TCP, but I agree, that maybe it would be going into too much detail.

> sufficient for the text here.

	OK.

	Kind Regards,

	Carlos J.

---

From: Masafumi Watari <[email-masked]>
Date: Fri, 09 Sep 2005 16:09:56 +0900

Hi Carlos,

>>application will decrease."

It's been applied for -01.

> in TCP, but I agree, that maybe it would be going into too much detail.

Ok.  Let's keep the document short.

>>sufficient for the text here.

Also added for -01.

thanks again,
watari