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

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

Hi all,

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

I think that seperate from aggregation, there is a need for unique
identitiy - user & session identity.  Perhaps a simple requirement,
seperate from others, should state that.  User / session identity
will need to be used by any AAA solution for authorization, 
authentication & accounting purposes.

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

I think we should remove this for now.  This gets into questions such
as what is the NSIS protocol running on top of - IP/TCP/UDP/SCTP/etc.
I think it would be premature to try to sort this out.

John

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

---

From: [email-masked]
Date: Fri, 8 Mar 2002 13:51:52 +0200

Hi Martin,

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

agreed.

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

MTU should be over the entire path, so by fitting a packet within
an MTU should be enough.

I am unsure if we need to address this here, but rather
in a protocol ...

John