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

From: [email-masked]
Date: Fri, 1 Mar 2002 22:55:58 +0200

Hi all,

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

Taking a page from AAA work, the domains are termed 'realms' - 
somehow, I think that term might be sidestep some of the issues
with the terminology.  Actually, on a theoretical basis 
(and probably because I have been editing the Diameter
base spec) I do see a lot of comonalities between NSIS
and AAA.  Perhaps we should consider some of the terminology
from that work, however, we can always stick QoS in front, 
just to be explicit.

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

Would a better requirement be something like:

 NSIS SHOULD provide a robust solution for signaling
 and handling of data packets irrespective of MTU
 (maximum transport unit) size.

Would that be something that would cover what you were thinking?

John

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

---

From: Martin Karsten <[email-masked]>
Date: Sat, 2 Mar 2002 17:08:23 +0100 (CET)

Hi John.

> from that work, however, we can always stick QoS in front, 

That might be fine, but I don't know the current AAA terminology. I was
referring to the fact that one cannot just arbitrarily aggregate IP flows
and then treat it as an IP aggregate. A common identifier, e.g. MPLS label,
DSCP, IP tunnel, CIDR prefix, or anything else is always needed to achieve
anything with respect to QoS aggregation. I thought that an explicit
statement might be useful to avoid too optimistic assumptions resulting from
the requirements. Of course, the mapping between a set of flow filters and
the common identifier might be hidden within a QoS domain and since NSIS is
focusing on inter-domain QoS signalling, it is debatable what level of
detail should be included in the requirements.

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

I don't know whether I fully understand the meaning of this statement. The
way I understand it, it sounds correct, but maybe trivial. The essential
question is whether the MTU of data packets must be fixed along a path or
whether it can vary in a sense that IPv4 fragmentation requires to transform
the QoS specification. I would think that requiring support for the latter
does not make much sense, because it increases complexity and is obsolete
for IPv6.

Greetings,
Martin