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

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Tue, 06 September 2005 15:18 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECfCy-0001vt-53; Tue, 06 Sep 2005 11:18:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECfCw-0001vD-0g for nemo@megatron.ietf.org; Tue, 06 Sep 2005 11:17:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03391 for <nemo@ietf.org>; Tue, 6 Sep 2005 11:17:53 -0400 (EDT)
Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECfFr-0008Ac-VA for nemo@ietf.org; Tue, 06 Sep 2005 11:21:01 -0400
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 9B7AA88D0C; Tue, 6 Sep 2005 17:17:43 +0200 (CEST)
Received: from acorde (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 172F888C04; Tue, 6 Sep 2005 17:17:43 +0200 (CEST)
From: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
To: Chan-Wah Ng <chanwah.ng@sg.panasonic.com>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>, Masafumi Watari <watari@kddilabs.jp>, Fan Zhao <fanzhao@ucdavis.edu>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-06AosfvGSo5DojtrLjXm"
Organization: UC3M
Date: Tue, 06 Sep 2005 17:17:42 +0200
Message-Id: <1126019862.7897.165.camel@acorde>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.2
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: IETF NEMO WG <nemo@ietf.org>
Subject: [nemo] Proposal of some text for draft-ietf-nemo-ro-problem-statement-00.txt
X-BeenThere: nemo@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NEMO Working Group <nemo.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nemo@ietf.org>
List-Help: <mailto:nemo-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=subscribe>
Sender: nemo-bounces@ietf.org
Errors-To: nemo-bounces@ietf.org

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