Subject: another requirements question (was: RE: [NSIS] A few comments to draft-fodor-reqts-cellular-netwks-00 .txt)

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 27 Feb 2002 17:27:22 -0000

Hi Brian,

[others: the requirements question is at the end if you want to skip to it.]

It seems we all probably agree that the scenario where the node responsible for requesting QoS (which might commonly be the application node) is not attached to the wireless link is an important one, in which case it's clear (to me) that wireless related parameters are relevant to NSIS QoS classes. We should probably have a scenario like this in the requirements draft. [I might have described this as 'QoS initiator not directly attached to the wireless link' but some people might have regarded this phrasing as provocative...]

But the more general question of NSIS-L2 interactions (also stimulated by your point about 'other wireless networks') raises a requirements/scope issue about NSIS:
Given a pair of independently implemented NSIS signalling entities (either side of the wireless link), it should be the case that NSIS protocol(s) will define how the QoS negotiation proceeds. But is this enough to make the lower layer negotiation proceed in a sensible way, or could there be reservation collisions (or neither side bothers at all...)?

In our framework document (draft-hancock-whatsit), we basically assumed that this would be defined somehow specifically to the lower layers in use (maybe in some kind of NSIS-over-foo document), but I'm not certain this is good enough. For example, if we believe that NSIS might get used in UMTS packet domain [warning: abandon all hope of following the rest of this sentence those not familiar with UMTS], then either the GGSN or UE or both or neither could do PDP context activation when they saw an NSIS message at the upper layers - the same ambiguity arises currently when they see an RSVP RESV (and I don't believe there is a standardised way for things to be done in that case either).

*** Requirements question ***
Does the NSIS signalling need to be able to convey/negotiate information about which end of a link is going to be responsible for initiating lower layer bearer setup?

I don't think the answer is obviously yes or no here. There's a lot of different wireless link types out there.

Yours,

Robert H.

> -----Original Message-----
> From: Brian Williams [mailto:[email-masked]]
> Sent: 21 February 2002 07:41
> To: Hancock, Robert
> Cc: 'Jukka Manner'; Gabor Fodor; [email-masked]
> Subject: RE: [NSIS] A few comments to
> draft-fodor-reqts-cellular-netwks-00 .txt
> 
> 
> 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:
> > 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
> > > 
> > 
> > ----
> > 
> 
> > 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: [email-masked] (Gabor Fodor)
Date: Thu, 28 Feb 2002 17:13:28 +0100 (MET)

Hi Robert,

thnaks for these comments, please see my comments inline :

> From [email-masked] Wed Feb 27 18:29:21 2002
> From: "Hancock, Robert" <[email-masked]>
> To: "'Brian Williams'" <[email-masked]>
> Cc: "'Jukka Manner'" <[email-masked]>,
>         Gabor Fodor
> 	 <[email-masked]>, [email-masked]
> Subject: another requirements question (was: RE: [NSIS] A few comments to 
> 	draft-fodor-reqts-cellular-netwks-00 .txt)
> Date: Wed, 27 Feb 2002 17:27:22 -0000
> MIME-Version: 1.0
> X-Status: 
> X-Keywords:
> X-UID: 18
> 
> Hi Brian,
> 
[GF]
Yes, I agree that we definitely need such a scenario. Actually, the scenario that we have
in the draft can be developed further to such a scenario quite easily. I understand from
the comments on the draft that such a scenario would be useful to clarify further our
requirements (R1-R7). 
[GF]

> I don't think the answer is obviously yes or no here. There's a lot of different wireless link types out there.
[GF]
Good point and I agree that the answer to this important question is not obvious.
The general intention with the wireless hints is to help the lower
layers to establish a L2 bearer, and from this point of view any information
element that helps to eliminate such an ambiguity is useful.
For instance, it may cause an additional delay if there is ambiguity at L2
which node should initiate the setup or the modification of a L2 bearer.

I would also find it useful at a later stage if such an NSIS-over-foo 
document provided guidelines as to how to use the protocol over some important
L2 technologies.
[GF]

> Robert H.

/Gabor

---

From: [email-masked]
Date: Fri, 1 Mar 2002 00:08:52 +0200

Hi Robert,

> Does the NSIS signalling need to be able to convey/negotiate 
> information about which end of a link is going to be 
> responsible for initiating lower layer bearer setup?

One problem with the above requirement might be that the
entity that does that layer 2 bearer setup might not be
visible to the IP layer.

However, we could put some fuzzyness into the requirement,
such as:

 NSIS signaling MAY interact with layer 2 entities for 
 setting layer 2 resources.

Or something like that.

John