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

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 1 Mar 2002 09:45:42 -0000

John,

I think we need to distinguish a requirement on what information the signalling is capable of conveying, from a requirement on how lower layer entities might be affected by that signalling.

If the lower layer isn't visible to the IP layer, it doesn't matter what L2-related requirements we write (and this applies to many of the other requirements in draft-fodor-... as well). Your additional text basically clarifies this, but I see it in fact as more of a statement about the scope/boundary of the NSIS problem as a whole.

So, maybe we should have something like it in the earlier sections of the requirements i-d; later requirements would be about specific capabilities that it might be useful for NSIS signalling to have to support certain link types, but the 'hints' term in 'wireless hints' conveys exactly the right impression.

Robert H.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 28 February 2002 22:09
> To: Hancock, Robert; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: RE: another requirements question (was: RE: [NSIS] A few
> comments to draft-fodor-reqts-cellular-netwks-00 .txt)
> 
> 
> 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
>

---

From: Brian Williams <[email-masked]>
Date: 04 Mar 2002 11:24:16 +1100

Hi Robert.
See my 2c on the requirements question.
/brian
On Thu, 2002-02-28 at 04:27, Hancock, Robert wrote:
> Hi Brian,
> 
> [others: the requirements question is at the end if you want to skip to it.]
<snip>
 
> *** 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.
I haven't thought about this previously, but my opinion is that it
should not be necessary.

I think that layer 2 managers must have rules to deal with deciding
which end controls L2 establishment, and they already have to deal with
RSVP which does not provide negotiation on which end does this. Thus,
the L2 manager must be able to deal with protocols which do not provide
control negotiation already, and I don't see a strong requirement to
solve this at present.

> Yours,
> > 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.
> > > 
> > > > 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.
> > 
> > 
> 
> ----
> 

> 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.

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