Subject: RE: [NSIS] Two kinds of requirements

From: "Schneider, Marco" <[email-masked]>
Date: Wed, 23 Jan 2002 12:03:53 -0600

Brian,

Thanks for your discussion. So if I understand your comments correctly, you
are concerned with NSIS QOS mapping to layer 2 QOS. Is there any way in
which these requirements would impact the actual signaling protocol?

Marco

-----Original Message-----
From: Brian Williams [mailto:[email-masked]]
Sent: Wednesday, January 23, 2002 4:32 AM
To: Schneider, Marco
Cc: 'Gary Kenward'; 'Roy, Radhika R, ALASO'; Loughney "John
(NRC/Helsinki); [email-masked]; Yaron Kahana; Geib, Ruediger;
[email-masked]; [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi Marco.
On Wed, 2002-01-23 at 09:48, Schneider, Marco wrote:
> Garry,
>  
> >From an architectural/software perspective there is a session layer that
> is logically built on top of the transport capability. From a protocol
> stack perspective the session signaling is not layered on top of the
> transport signaling in the framework I described. 
>  
> Aside: The following scenario is conceivable but not desireable.
> Consider an ADSL customer that is logically connected to an edge router
> via a DSLAM and an edge switch. Thus the layer 3 hop is realized by
> multiple hops at layer 2. 
A similar but slightly different situation exists also with cellular
wireless networks. The layer 3 hop runs over one layer 2 hop, but this
layer 2 hop is actually overlayed on top of multiple underlying layer 2
hops. 

> Existing deployments that I am aware of use a
> preprovisioned PVC for this. Now imagine that the customer does session
> signaling resulting in NSIS signaling at layer 3. This could result in
> the need for a new layer 2 connection because the existing PVC will not
> do the job. 
Certanly the case for cellular that a new lasyer 2 connection coule be
required.

> Thus ATM UNI signaling might be initiated from the ADSL
> Customer to allocate the resources for the layer 3 logical link. Yuck!
> Obviously it is better to avoid this by pre-provisioning the access
> network appropriately. Nevertheless, there may be other circumstances
> where this type of situation will occur and one could imagine promoting
> the layer 2 devices to be aware of NSIS so as to avoid multiple levels
> of signaling. 
For the cellular case, the end host is the device that sets up the layer
2 connection. This connection must use separate signalling to allow
separate development of the layer 2 capabilities (ie dependent on
cellular technology). The host though must be able to relate the QoS
requirements signalled by NSIS to the layer 2 signalling. We are in the
process of producing a draft to clarify these requirements based on
typical layer 2 characteristics of cellular networks.
/brian
  
> Marco
>  
> -----Original Message-----
> From: Gary Kenward [mailto:[email-masked]]
> Sent: Tuesday, January 22, 2002 3:34 PM
> To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John
> (NRC/Helsinki); [email-masked]; Yaron Kahana; Geib, Ruediger;
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> 
> Marco:
>  
>    Good question: what do I mean by layering. I assume you are familiar
> with protocol layers and their
> properties. My major concern would be in the replication of information
> exchanges at each layer, resulting
> in greater overhead/delay. The end systems must to be involved in
> establishing the necessary QoS, including
> negotiation if viable, but the number of bits that are transported
> through the network to set up this QoS
> end to end must be kept to a minimum. Thus, I cringe at the possibility
> of an end-to-end application exchange
> triggering an RSVP request, triggering . . . in telephony terms, the
> analogy is the call setup delay, which has
> to be acceptable to the user, and, for wireless, has to be bandwidth
> efficient.
>  
>   I hope I have explained my concern.
>  
> Cheers,
> Gary
>  
>  
> 
> -----Original Message-----
> From: Schneider, Marco [mailto:[email-masked]]
> Sent: January 22, 2002 15:35
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Roy, Radhika R, ALASO'; Loughney
> John (NRC/Helsinki); [email-masked]; Yaron Kahana; Geib, Ruediger;
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> Gary,
> 
> -----Original Message-----
> From: Gary Kenward [mailto:[email-masked]]
> Sent: Tuesday, January 22, 2002 9:02 AM
> To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John
> (NRC/Helsinki); [email-masked]; Yaron Kahana; Geib, Ruediger;
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> 
> Marco: 
> 
> -----Original Message----- 
> > [MS]  Yes, exactly. 
> >   I don't believe you are proposing a "layering" of signalling
> protocols, 
> > one for session establishment, then one for transport, etc. 
> > [MS]  This is exactly what has been proposed in RAP and SIP working
> groups to the best 
> > of my understanding. Because there does not exist a proxy signaling
> capability that 
> > allows a session to setup a connection on the users behalf, the
> session forwards a 
> > token to the end-system and then the end-system includes that token in
> the RSVP path 
> > message so that the reservation will go through. In this manner the
> session layer does 
> > not need to communicate directly with the transport layer. 
> 
> [gwk] I do not understand what "the session" represents in the above. It
> would seem 
> to me that you must have a session level entity, and that to "forward a
> token to the 
> end-system", it must have an interface/api to the "end-system". If this
> "end-system" 
> is including tokens in RSVP, then it is the entity setting up the
> transport QoS (although 
> it is not necessarly a transport layer entity, but rather a signalling
> entity. If these 
> two entites are co-located, then you do not have layered signalling
> protocols. 
> 
> Have I missed something? 
> 
> [Schneider, Marco] I don't think you have missed anything. I may not
> have understood what you meant by a layering of signaling protocols.
> Please define this.
> 
> BTW: for many links, particularly wireless, layered signalling is not a
> good idea. 
> And, in general, layered signalling will always be slower then a single
> signalling protocol. 
> > So, the question, 
> > becomes, how are the QoS transport mechanisms established? In the
> internet 
> > model there is only one end-to-end transport session (e.g. TCP, RTP,
> UDP), 
> > but underneath the transport is a series of inter-connected networks,
> each 
> > with potentially different characteristics. 
> >   This is end-to-end QoS support structure has to be set up and
> maintained 
> > in order for the end to end session QoS to be realized. The solution
> may be 
> > a single protocol that travels from host to host, such as RSVP, or it
> may 
> > be a collection of protocols that are optimized for each portion of
> the 
> > end-to-end path: e.g. host to access network, access to core network, 
> > core to core network, etc. 
> >   It is too early to determine which approach is best, but in either
> case, 
> > do we not need to understand the end-to-end requirements for this
> signalling 
> > capability? 
> > [MS]  So by end-to-end you are referring to both the end-systems and
> the devices in 
> > between. As a point of clarification, I asked Roy what he meant by
> "End-to-End 
> > Application Layer QOS Signaling" and his answer implied user
> (end-system) to user (end- 
> > system).  We have been using the term end-to-end in different ways
> (contexts). The way 
> > I normally use the term "end-to-end" is to include everything in
> between (all the 
> > hops). 
> 
> [gwk] I see the difference. I would say that I tend towards your
> definition, in the 
> following sense: the only QoS that matters is what the end-user sees, so
> as a service 
> characteristic, it must be provided between the two end systems / hosts.
> In order to do 
> this, however, some level of support is required at each hop along the
> path. 
> For me the term end-to-end (for example end-to-end call flow) includes
> the components within the network that must come together to make it
> work. The term end-to-end application level signaling seems like an
> oxymoron since this signaling occurs with no involvement of the network
> except to transfer the data packets but perhaps there is something I am
> missing. 
> 
>  So, establishing QoS between the end systems requires a peer-to-peer
> agreement between 
> the end systems, a host-to-cloud agreement for the transport of the
> packets, and 
> some mechanism within the cloud to ensure that the agreed upon QoS is
> provided. 
> Depending upon the complexity of the cloud, the latter could imply all
> sorts of QoS 
> agreements between networks and even nodes, for packet forwarding. 
> 
>   Note that I have purposely NOT stated that any of these agreements are
> negotiated or 
> require a signalling protocol. My opinion is that it is better in the
> long term to 
> support negotiated services using signalling, as it provides more
> flexibility. However, 
> this can be overdone, say, as a silly example, by having the end-system
> negotiate with 
> every node in the network. So, the compromise is that some of the QoS
> agreements will 
> be incorporated into the network design (e.g. Diff Serv), some will be
> configured by 
> the operator(s) (e.g. through traffic engineering and policy
> management), and others 
> will be signalled. NSIS seems to be about determining where signalling
> is appropriate, 
> and what are the signalling peers, and what is the best protocol
> solution or solutions. 
> The catch is that the first two approaches actually encompass a wide
> variety of technologies 
> and scenarios. 
> [Schneider, Marco]  I think you have articulated this very well and I am
> in general agreement. 
> 
>   Sorry for stating the obvious. There is clearly some concern over the
> use, for example, 
> of RSVP, and I suspect that some people are concerned that "end-to-end
> signalling" also 
> means "hop-by-hop" ala RSVP. It could, but it does not have to. 
> [Schneider, Marco] I think this is a very important distinction. I think
> that the reverse is true as well in that some people are assuming a hop
> by hop linear signaling model wherein the signaling takes place in order
> along the path that the data will follow. The transport signaling that
> is going to occur within the core of our network will be at a different
> timescale than UNI signaling and there are a variety of solutions for
> this including RSVP-te and CR-LDP which were developed for the purpose
> of allocating traffic trunks.
> 
>   So, my view is that NSIS needs to ensure that the end-to-end QoS is
> provided for, and 
> develope the protocols where they are needed (but not where they are
> not). At this point, 
> that would seem to be host to edge, edge to edge, and at the very least,
> with enough 
> end to end semantics to ensure that the complete path supports QoS. I am
> concerned about 
> node to node signalling, as there are so many different approaches to
> supporting node-to-node 
> QoS. At the very least, I would like to see a framework, and the edge
> solutions defined 
> before we delve into "intra-network" issues. 
> [Schneider, Marco] I think it all begins with the fact that a user must
> be able to request a QOS/COS connection/flow to another user. If we
> can't do that then everything else would appear to be pointless. The
> next question is whether we want to develop protocols that assist the
> network portion in delivering this capability and in what context(s).
> 
> 
> BTW: in writing this, it dawned upon me that it might be best to write a
> series of 
> requirements rather then just one - i.e. tackle the problem piece by
> piece. This approach 
> does have drawbacks, but working groups seem to work better when they
> focus on contained 
> problem domains. A strawman framework might be useful in keeping the
> incremental solutions 
> coherent. 
> [Schneider, Marco] I agree with the idea of tackling the requirements by
> breaking the problem up. There is a catch 22 in that in order to breakup
> it up we must to some degree presuppose a solution. 
> 
> 
> > [MS] I think our basic requirement is that an end-system be able to
> request (and 
> > receive) a QOS connection to some other end-system (NSIS UNI). The
> request part entails 
> > an NSIS UNI. As you say the realization of this request can be
> achieved in a number of 
> > different ways. Now one solution is to invent an NSIS NNI that runs
> between domains. If 
> > we develop requirements for such an NSIS UNI then we have already
> preproposed a 
> > solution ahead of requirements. 
> 
> [gwk] We have to be extremely careful not to become pre-occupied with
> requirements 
> definition. All productive requirements definition efforts begin with
> assumptions 
> concerning the solution. In my view, requirements specifications are a
> balance between 
> presumption and prediction, particularly when dealing with "soft"
> techologies such as 
> protocols. The issue really is not whether a requirement is a "MAY" or a
> "SHOULD" or 
> whatever, the issue is whether a requirement actually helps us define
> the solution 
> (there are lot's of examples of "SHOULD" requirements that do not bring
> value to the 
> design process). 
> [Schneider, Marco] I think there is a danger in implicit assumptions
> that may not lead to the best solution. With respect to network support
> of a QOS request, there are many different solutions and I am afraid
> that some participants have presupposed a hop by hop signaling solution.
> 
> 
> Given my observation above about writing a series of requirements, I
> would recommend 
> that we roughly map out the solution(some would call this a
> "framework"). This map would 
> form the preliminary list of deliverables for the wg charter, and then
> pick a focussed 
> problem area to begin with requirements. This is not "top down" design,
> but "top down" 
> processes seldom work. If this seems too abstract, what I am saying is
> that I have no 
> problem identifying that there are N problem areas to be addressed -
> e.g. host to edge, 
> edge to edge, node to node, etc. - and picking anyone for the first
> design attempt. Of 
> course, the challenge would be to keep an eye on the "big picture" or
> end-to-end 
> requirements in the process. 
> [Schneider, Marco] I think that the network context for supporting NSIS
> UNI is a quagmire, albeit a very fun one. The problems we need to
> address depend upon what end-to-end architectures we wish to support.
> There are a number of capabilities already being developed for network
> QOS and there may be a number of ways to "glue" these together.
> 
> Deludedly yours,
> 
> Marco
> 
> Just my deluded point of view. 
> Cheers, 
> Gary 
> 
> [Schneider, Marco]  
> *snip* 
> 

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

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

---

From: Brian Williams <[email-masked]>
Date: 24 Jan 2002 20:19:57 +1100

Hi Marco.

> which these requirements would impact the actual signaling protocol?
The comments highlighting the different network architectures was of
course simply to identify that the solution must allow for different
layering of communication in different networks. This is only to ensure
that limited views of networks and QoS layering don't lead to solutions
only tailored to one type.

The other aspect which I think you are actually questioning is whether
the layer 2 QoS mechanism shall impact the signalling protocol. My
position here is the actual signalling mechanism should be independent
of the lower layers, but the data carried to express the traffic and QoS
requirements can vary. 
/brian