Subject: [NSIS] suggestions for draft-ietf-nsis-req-00.txt

From: Martin Karsten <[email-masked]>
Date: Thu, 28 Feb 2002 11:21:16 +0100 (CET)

I have a few suggestions for draft-ietf-nsis-req-00.txt. Apologies, if these
have already been adressed.

Section 2, Terminology

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

'Edge-to-edge QoS'
- change "administrative domain" to "QoS domain" (as it is defined earlier)
- remove second half of the sentence (beginning with "that connects"),
  because it unnecessarily restricts the scope of the definition

'QoS Service Class'
- The term seems to be overloaded. Its definition is similar to the usual
  definition of "service class" as describing a particular set of QoS
  parameters. However, the usage of QSC e.g. in 'Mapping' and 'QoS
  Initiator' does not seem to make sense (a service class is not initiated). 
  It might be more suitable to additionally use a term like "service
  invocation" to describe actual instances of QoS requests.

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.

Greetings,
Martin

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

---

From: Roland Bless <[email-masked]>
Date: Thu, 28 Feb 2002 13:38:58 +0100

Hi Martin,

>   commonly and uniquely identifiable, because otherwise aggregation doesn't

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.

>   because it unnecessarily restricts the scope of the definition

The most general case should be the one where we have several "QoS
domains" that are grouped together within an Autonomous System. 
I'm a little bit confused about the overloaded term "edge". In one case,
"edge-to-edge" means boundary to boundary within a single domain,
whereas in other cases "edge-to-edge" means edge _network_ to edge
_network_. Shouldn't we be more precise here?

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

Best regards,
 Roland

-- 
Roland Bless -- e-Mail: [email-masked]
Institute of Telematics, University of Karlsruhe, Germany  
Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358
Phone: +49 721 608-6413 Fax: +49 721 388097

---

From: Martin Karsten <[email-masked]>
Date: Thu, 28 Feb 2002 14:01:35 +0100 (CET)

Hi Roland.

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

> Sure, in the latter case an implementation without fragmentation 

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.

Best,
Martin

---

From: Roland Bless <[email-masked]>
Date: Thu, 28 Feb 2002 14:13:38 +0100

Hi Martin,

> identifiable per QoS domain ...

Ok, I considered the multi-domain case...

> then of course, forget my comment.

Conclusion: This different interpretation indicates that 5.2.5 needs to be 
more precise... :-)

Cheers,
 Roland