Subject: [NSIS] I-D ACTION:draft-fodor-reqts-cellular-netwks-00.txt

From: Gabor Fodor <[email-masked]>
Date: Tue, 19 Feb 2002 20:55:39 +0100

Hi All,

I relaize that  the group is in the process of working on 
the requirements draft and that Marcus' draft is the 
basis for that.  However, I hope that the following draft 
can still highlight some important requirements 
from the point of view of multi-mode (mobile) terminals 
that use IP level signaling to request 
QoS enabled services from an IP backbone.  

I expect that during the lifetime of the NSIS
signaling protocol multiple access technologies 
(including wireless, cellular, WLAN and wired ones)
will be widely used to access IP based services, 
and we therefore list a few key requirements 
on the signaling protocol that is used in such a scenario.
Applications that use the protocol may not be even aware 
of the specific access technology that they are using 
at a given time. 

In such a scenario, the IP level
QoS parameters are not only used to specify the requested 
IP level service, but also 
(through an access specific translation function)
to help the mobile node's wireless link manager to configure the
wireless bearer service. 
In such a scenario, the IP level QoS
signaling must meet special requirements in order to 
support the spectrum efficient management 
of the wireless resources.

I hope that these requirements can serve as an input towards
the doc.

/Gabor

-------- Original Message --------
Subject: I-D ACTION:draft-fodor-reqts-cellular-netwks-00.txt
Date: Tue, 19 Feb 2002 07:01:48 -0500
From: [email-masked]
Reply-To: [email-masked]
To: IETF-Announce:;@loki.ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: NSIS QoS Signaling Requirements from a Multi-access 
                          Wireless Perspective
	Author(s)	: G. Fodor
	Filename	: draft-fodor-reqts-cellular-netwks-00.txt
	Pages		: 9
	Date		: 18-Feb-02
	
We consider access technology agnostic applications that use IP level
QoS primitives to specify their QoS requirements. In future wireless
systems (beyond what is often referred to as 3G), where mobile nodes
may access an IP backbone over diverse access networks, the IP level
QoS primitives are not only used to specify the requested IP level
service, but also (through an access specific translation function)
to help the mobile node's wireless link manager to configure the
wireless bearer service. In such a scenario, the IP level QoS
primitives must meet special requirements in order to support the
spectrum efficient management of the wireless resources.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-fodor-reqts-cellular-netwks-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-fodor-reqts-cellular-netwks-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-fodor-reqts-cellular-netwks-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Jukka Manner <[email-masked]>
Date: Wed, 20 Feb 2002 13:59:32 +0200 (EET)

Hi,

	As I read the draft, two requirements left me wondering:

	R2: how does this match with the UDP-lite proposal, where the UDP
header indicates the need for UEP. Thus, does the QoS primitives /
signalling need to indicate the need for UEP? If the transport protocol
does not support UEP, you won't get the packet sent to/accepted at the
receiver. Also, you don't even need any QoS mechanism to use UDP-lite.

	R3: you seem to assume that doing bi-directional resource 
allocations also implies that routing is symmetric for uplink and 
downlink. Since IP routing is asymmetric, I doubt that bi-directional 
reservations are possible with a single mechanism, but rather imply that 
there must be separate signalling for the two directions. Thus, eg. RSVP 
makes it possible to have asymmetric reservations on the two directions.

	Cheers,

	Jukka

---

From: Gabor Fodor <[email-masked]>
Date: Wed, 20 Feb 2002 22:52:15 +0100

Jukka,

good questions ! Please consider my answers below :

>receiver. Also, you don't even need any QoS mechanism to use UDP-lite.
UDP Lite together with quite a large number standard  RTP payload formats
(AMR, AMR WB, MPEG4, etc) allows the link layer
to perform QoS differentiation between the different parts of the RTP 
payload. 
For instance, in some cellular systems, the RTP payload may be segmented 
into
different parts, and these different parts  are transported over 
different radio channels
that are associated with different QoS. This technique can be especially 
important for
instance for AMR speech samples, but in theory the link layer can use 
this technique for
any other application. (Provided that it has some knowledge about the 
payload format
and what QoS it should associate with each part.)

You are perfectly right in saying that in practice you need UDP Lite for 
this, but UDP Lite
in itself  does not help the link layer to configure the proper QoS for 
the different parts
of the (typically RTP) payload. Therefore, R2 is concerned to support 
this kind of differentiation
by requiring from the IP level QoS signaling that it should allow for 
the indication of multiple
QoS levels.

You are also right in saying that you do not need any QoS mechanism to 
use UDP Lite,
but if an application wants to use and is able to indicate its (unequal) 
multiple QoS levels
(say an application that uses a standardized RTP format), then it should 
be able to do so.
(Let me also point out, that we are at the requirement discussion now, 
so we in fact should not
discuss the solution, but I am not thinking of quantitive QoS values 
here (that would be
unaccepatble from the application programmer's perspective), rather 
qualitative indications.)

Surely, if an application does not want this, it could simply ignore 
this capability of the
protocol.

>makes it possible to have asymmetric reservations on the two directions.
I would say that at this stage R3 is just stating the requirement that 
it must be able to set up
asymmetric bi-directional bearers between the parties. If  we in the 
solution phase find that
an existing protocol can do this, then it is fine. But of course we need 
to consider all requirements
when deciding on the solution approaches (such as extensions to existing 
protocols or new protocol(s)).
I am open to consider and discuss whether bi-directional reservation is 
possible/advantageous
with a single mechanism or we had better use two separate (instances of) 
mechanisms.

Jukka, thanks for the questions and I hope these answers help the 
discussion further ! 

Cheers /Gabor