Subject: RE: [NSIS] A few comments to draft-fodor-reqts-cellular-netwks-00 .txt

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 20 Feb 2002 14:18:45 -0000

Hi Jukka, Gabor,

On the UDP-lite issue, my understanding is that UDP-lite only tells you that some of the packet is checksum protected and some isn't. The sophistication of signalling required for full UEP (e.g. to support AMR codec operation) is much greater. I guess if you had UEP QoS signalling you wouldn't need UDP-lite, you could just switch the checksum off altogether (at least for IPv4).

I was more concerned about whether the scenario as presented really justifies the need for wireless-related parameters at all. It seems to concentrate on the case where the wireless link is the last hop, directly connected to the node where the end application is running. In that case, it's clear that good quality IP QoS (fine grained, efficient, local etc.) is important, more so than in fixed networks. I think it's less clear that the IP layer signalling needs to have link (or 'link-ish') parameters in it. After all, the link layers already have their own signalling, and can tune the link to the required QoS even more tightly.

It's true that if applications use the IntServ classes to request QoS from their network stack, these classes need to be extended with wireless hints. But that's a comment on the deficiency of basing inter-layer interfaces on protocols, not a requirement to extend the protocol itself.

One reason we thought to be very careful here was that if you have wireless-related parameters being exchanged at both IP (RSVP) and link layers, it might be hard for independent implementors of each end to work out which layer to use for negotiation and in which order, and which layer was in charge. This was raised after SLC as an open issue on the list, but the argument wasn't really clear (partly my fault).

I think there _is_ actually a good case for having wireless related parameters, but that the justifying scenario is where the wireless link is 'interior' (e.g. 3G mobile acting as a wireless router for a local subnet), but in that case you might need take into account other considerations as well. Then you need to get the wireless-related information from the application into the router. But in either case, we need to have a clear model of how the link layer negotiation interacts with the IP layer negotiation.

Or did I miss something?

Robert H.

> -----Original Message-----
> From: Jukka Manner [mailto:[email-masked]]
> Sent: 20 February 2002 12:00
> To: Gabor Fodor
> Cc: [email-masked]
> Subject: [NSIS] A few comments to
> draft-fodor-reqts-cellular-netwks-00.txt
> 
> 
> 
> 	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
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
>

---

From: Gabor Fodor <[email-masked]>
Date: Wed, 20 Feb 2002 23:50:30 +0100

Hi Robert,

I agree that we need to have a set of scenarios in the contect of which
we can discuss both the protocol requirements and the use of the 
wireless hint
parameters. And I also agree that the scenario you are mentioning here
with the 'interior' wireless link can be one of  these relevant scenarios,
but I am not sure if I understand your concern regarding the scenario 
presented
in the draft.

That scenario assumes that the application requests a QoS service via the
"IP QoS module", and cannot configure the wireless link directly. It is 
true that
the link layers already have their own signaling and can tune to the 
required
QoS _provided_ that they know what this required QoS is ! Please note 
that we
are not proposing a huge number of strange paramaters, just a very few
generic and qualitative indications. I envisage that this kind of 
scenario becomes
especially important in a multi-access environment, where the mobile node
moves accross multiple and diverse accesses, like between a cellular and a
hot spot area, (while accessing the same IP core network)
and the application is not even aware of the specific L2 technology,
so it cannot configure it. On the other hand, the application may need 
to adjust
adaptively on the fly for instance its bit rate, simply because the 
available bandwidth differs
over these accesses, so the application needs to be able to control QoS 
during
run-time (but in an access agnostic manner). 

I think that it is useful to actually seprate the paramater discussion 
from the
actual protocol requirement discussion, and R1 actually only talks about
per-flow QoS and traffic characterization.

I also agree that we need to be careful about exchanging parameters both at
the IP and the link layer, but I don't think this should keep us from 
providing
the really necessary information at the IP layer to the link layer. 
After all, such
scenarios already exist in some cellular standards.

I would be open to start working on a small set of scenarios where we go 
through
what paramaters are needed, where they are translated to link layer 
paramaters, and
in which ones the requirements R1-R7 are important/luseful, etc. 
Likewise, I do
agree with the proposal of developing a model of how the link layer 
negotiation
interacts with the IP layer negotiation, this is important.

(Regarding the UDP discussion, please see my previous mail to Jukka and 
to the list.)

/Gabor

Hancock, Robert wrote:

>>------------------------------------------------------------------------
>>
>>The information contained in this e-mail and any attachments is confidential to Roke 
>>Manor Research Ltd and must not be passed to any third party without permission. This 
>>communication is for information only and shall not create or change any contractual 
>>relationship.
>>

---

From: Brian Williams <[email-masked]>
Date: 21 Feb 2002 18:40:53 +1100

Hi Robert.
I would definitely agree that there are many different scenarios, and
one with the application node sitting behind a wireless router/gateway
is the most obvious situation which introduces signalling requirements.

I would also add though that even within one physical node, there can be
scenarios that effectively become an equivalent to this application node
behind a gateway router. For example, on my PC I have run multiple
virtual machines. The communication between these virtual machines
occurs over a virtual ethernet, but it is all within one node.

There can also be cases where a node works towards one logical interface
internally, which is then adapted one or more times until it reaches the
real interface such as with levels of tunneling.

And finally, we should not rule out that other wireless networks could
control the link layer signalling from the network instead of from the
terminal.  

In all of these cases, there are reasons to have additional information
important for the wireless operation available from the application
level QoS interface, and possibly carried in the IP level QoS protocol.
I do agree though that dependent on the exact scenario, this information
may not need to be transmitted over the wireless link.
/brian

On Thu, 2002-02-21 at 01:18, Hancock, Robert wrote:
> ----