Subject: comments on: RE: [NSIS] suggestions for draft-ietf-nsis-req-00.tx t

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 28 Feb 2002 16:40:34 -0000

hi all,

A number of these issues are to do with flow/aggregate identification/classification, which we did not write a specific definition for. Identification can be a hard issue (especially for aggregates or fragments), and there's a dependency on router technology (some routers may only be capable of classifying on particular fields, for example). However, from a definition point of view, it seems that the 'filter spec' concept of RSVP is directly applicable here, with the exception that
*) we aren't prejudging what fields the filter spec might refer to (OR people should say what they think should be possible)
*) the filter spec might be mutable (e.g. DSCP might change).
Given a definition of 'filter', we could then amend the definition of aggregate to say
"To be of practical use, an aggregate must be associated with a filter."
[We could say the same about flows as well.] Would this address the concerns?

On the fragmentation issue, it was certainly (IIRC) the intention that this applied to QoS treatment for fragmented user packets. So, maybe 5.2.5 should contain
"User data flows [or aggregates] which contain IP-fragmented packets should not have their QoS degraded."
In practical terms, this is mainly about having filters that can identify the fragments, which can be hard (unless you allow state in the classifier, you are restricted to traffic class fields, or the flow label for IPv6). I'm not sure whether there is any other practical impact of this requirement.
Since it's hard/restrictive, do people want to leave this out (in which case we should state it explicitly as a non-requirement)?

On the QSC case, I think the term is not overloaded, but some of the other definitions might make it look that way. In particular, 'Mapping' is just a statement that QSCs are pieces of data that are subject to transformation into other pieces of data; 'QoS initiator' is a statement that the QI is responsible for working out what the QSC for a flow is from upper layer information. The QSC is not invoked, the QSC is some of the data that is transferred in the invocation. Maybe we should change QI to
"this is responsible for initiating the QoS signaling for user traffic flow(s). This includes deriving the QSCs used in the signaling, based on user or application requirements (from the higher layers). The Initiator can also invoke local QoS provisioning mechanisms.  It can be located in the end system, but may reside elsewhere in network."

Is this clearer?

Robert H.

> -----Original Message-----
> From: Roland Bless [mailto:[email-masked]]
> Sent: 28 February 2002 13:14
> To: Martin Karsten
> Cc: [email-masked]
> Subject: Re: [NSIS] suggestions for draft-ietf-nsis-req-00.txt 
> 
> 
> Hi Martin,
> 
> > > > 'Aggregate'
> > > > - add an explicit statement that packets belonging to 
> an aggregate must be
> > > >   commonly and uniquely identifiable, because otherwise 
> aggregation doesn't
> > > >   make much sense.
> > > 
> > > I disagree here, because aggregation is usually performed 
> at service level,
> > > i.e., the service has to have technically the same 
> characteristics/attributes,
> > > e.g., a guaranteed rate. If one considers DiffServ 
> domains as a possible QoS 
> > > implementation architecture, each DiffServ domain may use 
> different PHBs 
> > > (with different codepoints) to provide an equivalent 
> service. Therefore,
> > > packets will usually be different along the path of an aggregate.
> > 
> > Correct, but then all packets will all have the same DSCP 
> within a domain,
> > which essentially is the common and unique identifier I'm 
> referring to.
> > 
> > Let me rephrase:
> > ... packets belonging to an aggregate must be commonly and uniquely
> > identifiable per QoS domain ...
> 
> Ok, I considered the multi-domain case...
> 
> > > > Section 5.2.5, IP Fragmentation
> > > > 
> > > > I would suggest to remove this requirement as it 
> increases the complexity
> > > > without much benefit. There are good reasons, why IP 
> fragmentation is
> > > > usually not supported by QoS signalling. Further, IPv6 
> does not support IP
> > > > fragmentation at forwarding nodes.
> > > 
> > > IPv6 is definitely not a problem in this context, because 
> nsis signaling
> > > will always mean fragmentation from end to end between to 
> adjacent nsis
> > > nodes. Thus, every nsis node will able to fragment its signaling
> > > messages and any router will be able to forward these 
> messages (but it
> > > will not fragment by itself at all). On the other hand, 
> why shouldn't we
> > > allow fragmentation? It will be an implementation 
> decision whether the
> > > nsis protocol should require a reliable transport 
> protocol such as SCTP
> > > or whether it should do all the stuff by itself (IMHO it 
> shouldn't).
> > > Sure, in the latter case an implementation without fragmentation 
> > > will be easier.
> > 
> > I was assuming that the requirement in 5.2.5 refers to the 
> data packets
> > rather than signalling packets. If it only refers to 
> signalling packets,
> > then of course, forget my comment.
> 
> Conclusion: This different interpretation indicates that 
> 5.2.5 needs to be 
> more precise... :-)
> 
> Cheers,
>  Roland
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
>

---

From: Martin Karsten <[email-masked]>
Date: Thu, 28 Feb 2002 18:04:59 +0100 (CET)

> [We could say the same about flows as well.] Would this address the concerns?

Yep.

> On the fragmentation issue, it was certainly (IIRC) the intention that
> this applied to QoS treatment for fragmented user packets. So, maybe 5.2.5
> should contain "User data flows [or aggregates] which contain
> IP-fragmented packets should not have their QoS degraded." In practical
> terms, this is mainly about having filters that can identify the
> fragments, which can be hard (unless you allow state in the classifier,
> you are restricted to traffic class fields, or the flow label for IPv6).
> I'm not sure whether there is any other practical impact of this
> requirement. Since it's hard/restrictive, do people want to leave this out
> (in which case we should state it explicitly as a non-requirement)?

Another practical issue is that of translating an NSIS QoS specification
into anything that is handed over to the QoS enforcement system (QoS
technology?). Many QoS technologies and algorithms need or benefit from
(some) knowledge about the packet rates in order to decide about admission.
I believe that allowing fragmentation increases complexity here, as well.

> On the QSC case, I think the term is not overloaded, but some of the other
> definitions might make it look that way. In particular, 'Mapping' is just
> a statement that QSCs are pieces of data that are subject to
> transformation into other pieces of data; 'QoS initiator' is a statement
> that the QI is responsible for working out what the QSC for a flow is from
> upper layer information. The QSC is not invoked, the QSC is some of the
> data that is transferred in the invocation. Maybe we should change QI to
> "this is responsible for initiating the QoS signaling for user traffic
> flow(s). This includes deriving the QSCs used in the signaling, based on
> user or application requirements (from the higher layers). The Initiator
> can also invoke local QoS provisioning mechanisms.  It can be located in
> the end system, but may reside elsewhere in network."
> 
> Is this clearer?

I'm undediced and I would draw the following analogy. In an OO programming
language, there are 'classes' and 'objects'. I believe that terms like
'service class' and 'service invocation' are needed to express a similar
distinction in the context of QoS signalling.

Martin