[NSIS] MIP QoS requirements draft - modification proposal for Section 3.3.2

Hemant.Chaskar@nokia.com Mon, 22 April 2002 19:49 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10468 for <nsis-archive@odin.ietf.org>; Mon, 22 Apr 2002 15:49:06 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA14869 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 15:49:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13180; Mon, 22 Apr 2002 15:31:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13139 for <nsis@ns.ietf.org>; Mon, 22 Apr 2002 15:31:25 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09847 for <nsis@ietf.org>; Mon, 22 Apr 2002 15:31:20 -0400 (EDT)
From: Hemant.Chaskar@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3MJVfF16272 for <nsis@ietf.org>; Mon, 22 Apr 2002 22:31:41 +0300 (EET DST)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5a6c383e8bac158f24078@esvir04nok.ntc.nokia.com>; Mon, 22 Apr 2002 22:31:21 +0300
Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 22 Apr 2002 22:31:21 +0300
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 22 Apr 2002 14:30:48 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EA34.344098D3"
Date: Mon, 22 Apr 2002 15:30:47 -0400
Message-ID: <E320A8529CF07E4C967ECC2F380B0CF94F596B@bsebe001.NOE.Nokia.com>
Thread-Topic: MIP QoS requirements draft - modification proposal for Section 3.3.2
Thread-Index: AcHqNDQ65uuu1j4tQ4WuZBhJMq4cBQ==
To: mobile-ip@sunroof.eng.sun.com
Cc: nsis@ietf.org
X-OriginalArrivalTime: 22 Apr 2002 19:30:48.0853 (UTC) FILETIME=[34D30C50:01C1EA34]
Subject: [NSIS] MIP QoS requirements draft - modification proposal for Section 3.3.2
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi:
 
I received some comments privately that the text in Section 3.3.2 of draft-ietf-mobileip-qos-requirements-02.txt, is not clear enough. In response to that, I propose the following modification to this text. Please let me know if you have any comments, else I will go ahead and incorporate it in the next version (03) of the draft.
 
Thanks,
Hemant
 
Old text:
----------
 
2. Interactions with link-layer support for QoS:
 
The QoS mechanism MAY provide some information to the link layers for them to support the required QoS. Since a vast number of devices using Mobile IP will be connected to the Internet via wireless links, QoS parameters relevant for wireless links, such as error rate, MAY have to be included in the set of IP-level QoS parameters to be possibly considered by the underlying link layer.
 
An example scenario will be two UDP streams requiring different levels of error protection at the link layer. For such cases, an IP-layer QoS mechanism may indicate some generic parameters such as acceptable IP packet loss rate to link layers.
 
New text:
-----------
 
2. Interactions with wireless link-layer support for QoS:
 
Since a vast number of devices using Mobile IP will be connected to the Internet via wireless links, the QoS mechanism for Mobile IP MAY provide some information to the wireless link layers for them to support the required QoS. 
   
An example scenario that may benefit from such information is that of the two UDP streams associated with the same media, but requiring different levels of error protection at the wireless link layer due to certain characteristics of their respective encoding schemes. The packets of these two streams are equally delay sensitive (so as to maintain playout synchronization at the receiver), and hence, may be treated equally (as regards queuing) by IP layer. But they may need to be transmitted on wireless channels of different error characteristics(say different FEC coding or power levels).
   
The QoS information included for the benefit of wireless link layers SHOULD be such that it is meaningful both ways: to applications that reside over IP so that they can choose the IP service of certain QoS characteristics and to wireless link QoS managers so that they can then map this information to the details of lower layer mechanisms and their parameters.
 
In the example scenario described above, such a QoS information could be expressed as the acceptable loss rate of IP packets in the UDP stream. This parameter enables the UDP application to choose the IP service having QoS that matches its requirements, and it also enables the wireless link QoS managers to choose the right wireless channel to transmit the packets of this UDP stream.