[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
- [nemo] Proposal of some text for draft-ietf-nemo-… Carlos Jesús Bernardos Cano
- [nemo] Re: Proposal of some text for draft-ietf-n… Masafumi Watari
- [nemo] Re: Proposal of some text for draft-ietf-n… Carlos Jesús Bernardos Cano
- [nemo] Re: Proposal of some text for draft-ietf-n… Masafumi Watari