Subject: Re: [NSIS] New NSIS-related drafts

From: Bob Braden <[email-masked]>
Date: Sat, 5 Oct 2002 14:35:38 -0700 (PDT)

Rüdiger Geib wrote:

  *> One such capability could be "QoS". The second draft describes a
  *> QoS client. The casp-qos draft is not as elaborated as the CASP
  *> draft. It repeats one of the major drawbacks of IntServ/RSVP: it
  *> doesn't separate a service identifier from a service descriptor.

I would say that this criticism is largely incorrect.  The int-serv
folks defined a family of service descriptors, with some common
elements.  It was expected that this family would be extended, and the
syntactic hooks for extension are there.  If for some reason this does
not work for you, e.g., because (unwisely, I believe) you did not want
the common elements defined by int-serv, you have only to define new
formats of Flowspecs, etc.  The CType seems to work just fine as a
service identifier.  I would therefore say that IntServ/RSVP DOES
effectively separate service identifier from service descriptor.

I also find it a little strange that you consider this a "major drawback".

 Different services will require different descriptors. Some examples:
  *> 
  *> - Internet2's Scavenger Service requires signalling 
  *>   of a DSCP only. It is just turned on or off (it 
  *>   is "Less Than Best Effort").

I must be dense here... isn't the DSCP number a parameter to the
signaling?

  *> - A globally well defined service only requires a 
  *>   limited set of parameters (ideally, bandwidth 
  *>   will do it) and a DSCP.
  *> - IntServ may require a couple of other parameters.
  *>   A DSCP may be required.
  *> 
  *> I'd suggest the following:
  *> A Service Identier MUST be present in every CASP-QoS reservation message. Depending on the service identified, a service descriptor containing service specific parameters is present. If the service itself doesn't require further description than just a service ID, we are fine.

  *> 
  *> Assuming the CASP-QoS protocol to establish signalling for DiffServ domains, PHB-ID and DSCP MUST be present and could form parameters outside of the service dewscriptor (they could be part of the Service ID).

I fail to understand the distinction you are making between service ID
and service descriptor.  I assumed that by service descriptor you meant
the set of parameters needed to describe a service -- that would be the
PHB-ID and the DSCP number in the case you cite -- and identified by a
Service ID that is an assigned number.  If the service ID is somehow a
compound data structure that contains some of the service description,
why have a separate service descriptor?  I don't get it.

Thanks,

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

---

From: "Xiaoming Fu" <[email-masked]>
Date: Tue, 8 Oct 2002 15:13:37 +0200

Hi Rüdiger,

Thanks for your comments. My remarks inline [XF]:

---Original message---
From: "Geib, Ruediger" <[email-masked]> 
To: [email-masked] 
Cc: [email-masked] 
Subject: Re: [NSIS] New NSIS-related drafts 
Date: Mon, 30 Sep 2002 16:50:50 +0200 

The maximum/minimum bandwidth procedure seems to be the only feasible
way of realising a simple negotiation mechanism. I still feel it to be
too complex and would favor a single bandwidth as only requirement for
the protocol. I'd be curious in learning more about application
developers views on that.

[XF] We thought this is helpful particullarly in wireless mobile
environments; people may use only one bandwidth if a single bandwidth
information is available. Meanwhile we would also like to see how this
could or could not well-fit the QoS provisioning techniques and
applications.

If negotiation is kept, how are things handled for bidirectional
reservations? A reservation will still be accepted if one direction gets
maximum resources while the other gets minimum? 

[XF]IMO the space left for bidirectional reservations in CASP is small.
In general, bidirectional ones introduce new error message types,
related control  and increased protocol complexity. 

I'd also favour the basic CASP-QoS protocol to be free of any
pre-emption mechanism. Not every QoS service does require support of
emergency calls (e.g. Internet2's Scavenger Service doesn't).
Pre-emption adds signaling load and operational complexity and should at
best be optional.

Further, there's a parameter "L2 properties". It should be removed
without replacement. Layer 2 issues are opaque to NSIS signalling. A
network operator learns which service is required by NSIS signaling. The
operator then decides whether his network meets these service
requirements or whether it doesn't. If NSIS signaling will contain a
Layer 2 specific service descriptor combining every possible layer 2
with every possible interpretation of service mapping per operator, we
don't need NSIS. by the way, didn't we agree to limit NSIS strictly to
layer 3?

[XF] Pre-emption and L2 properties have been tentatively discussed
because we learned such requirement from some operators. We'd also be
listening to others whether it makes sense for supporting local objects.

Cheers,

Xiaoming Fu
University of Goettingen, Telematics Group
Lotzestr. 16-18, 37083 Goettingen, Germany
Tel.+49-551-39-14411, Fax.+49-551-39-14403
mailto:[email-masked]

---

From: Bob Braden <[email-masked]>
Date: Tue, 15 Oct 2002 22:14:03 GMT

*> 
  *> Further, there's a parameter "L2 properties". It should be removed
  *> without replacement. Layer 2 issues are opaque to NSIS signalling. A
  *> network operator learns which service is required by NSIS signaling. The
  *> operator then decides whether his network meets these service
  *> requirements or whether it doesn't. If NSIS signaling will contain a
  *> Layer 2 specific service descriptor combining every possible layer 2
  *> with every possible interpretation of service mapping per operator, we
  *> don't need NSIS. by the way, didn't we agree to limit NSIS strictly to
  *> layer 3?
  *> 

I would suggest that this issue needs more thought.  I can tell you
that our ATM friends are adding a whole new object class to RSVP[-TE]
to carry one 3-bit integer encoding the ATM Qos class -- CBR, etc.  I
know because the IANA asked me as RSVP expert to comment on the
assignment of an RSVP class number.  I think that this particular
extension is severely brain-dead; it should rather be a single CType
for an L2 properties object (or be in a flowspec).  Unfortunately this
work, like a lot of the stuff going on now, is outside the IETF so I
have no say.  However, it does show that L2 properties may have a place
in the general signaling regime (which *I* think is what the present
NSIS WG should be addressing, not just a particular subset such as QoS).

Bob Braden

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 16 Oct 2002 13:15:42 +0200

Bob,

if you use C-Type to identify a single service,
I would agree with you. By single service I mean:
- Less Than Best Effort -> own C-Type
- IntServ Guaranteed -> own C-Type
- IntServ Controlled -> own C-Type

IntServ doesn't make this distinction in the 
C-Type, there's only one C-Type saying "IntServ".
The two IntServ services are identified 
explicitely where required (Receiver FLOWSPEC,
9th octet). Prior to this separation IntServ 
signals information about policing and MTU sizes 
(Sender). Services specified in other ways than 
IntServ may not require signaling of this 
information. I continue to look at this as a 
major drawback of IntServ/RSVP (using IntServ 
signaling for one of these other services is 
somewhat unattractive). Please note that I've 
put "IntServ" in front of RSVP already in my 
first message.

C-Type is an 8-bit field. Instead of 
identifying individual services it may be useful
to identify "Meta services" only (e.g QoS, 
MidBox) and have the service ID / service 
descriptor there. I didn't read the RSVP related 
drafts yet, please don't critisise me if this is 
already proposed there.

To me the "elements common" to all DiffServ 
based QoS services are a service name, a PHB, 
and a DSCP as part of a service ID. This allows
flexible addition of a service specfic parameter 
TLV. If it is required. 
Examples:
Service specific parameters are absent by 
definition the case of Less Than Best Effort.
They must be the IntServ Guaranteed service 
parametrisation (like Flowspec etc.), should 
the latter be signaled that way. 

Regards, Rüdiger 

> -----Original Message-----
> From: Bob Braden [mailto:[email-masked]]
> Sent: Saturday, October 05, 2002 11:36 PM
> To: [email-masked]; Geib, Rudiger
> Cc: [email-masked]
>   *> A Service Identier MUST be present in every CASP-QoS 
> reservation message. Depending on the service identified, a 
> service descriptor containing service specific parameters is 
> present. If the service itself doesn't require further 
> description than just a service ID, we are fine.
> 
>   *> 
>   *> Assuming the CASP-QoS protocol to establish signalling 
> for DiffServ domains, PHB-ID and DSCP MUST be present and 
> could form parameters outside of the service dewscriptor 
> (they could be part of the Service ID).
>

---

From: Bob Braden <[email-masked]>
Date: Thu, 24 Oct 2002 18:02:01 GMT

*> Bob,
  *> 
  *> if you use C-Type to identify a single service,
  *> I would agree with you. By single service I mean:
  *> - Less Than Best Effort -> own C-Type
  *> - IntServ Guaranteed -> own C-Type
  *> - IntServ Controlled -> own C-Type
  *> 
  *> IntServ doesn't make this distinction in the 
  *> C-Type, there's only one C-Type saying "IntServ".
  *> The two IntServ services are identified 
  *> explicitely where required (Receiver FLOWSPEC,
  *> 9th octet). Prior to this separation IntServ 
  *> signals information about policing and MTU sizes 
  *> (Sender). Services specified in other ways than 
  *> IntServ may not require signaling of this 
  *> information. I continue to look at this as a 
  *> major drawback of IntServ/RSVP (using IntServ 
  *> signaling for one of these other services is 
  *> somewhat unattractive). Please note that I've 
  *> put "IntServ" in front of RSVP already in my 
  *> first message.
  *> 
  *> C-Type is an 8-bit field. Instead of 
  *> identifying individual services it may be useful
  *> to identify "Meta services" only (e.g QoS, 
  *> MidBox) and have the service ID / service 
  *> descriptor there. I didn't read the RSVP related 
  *> drafts yet, please don't critisise me if this is 
  *> already proposed there.
  *> 
  *> To me the "elements common" to all DiffServ 
  *> based QoS services are a service name, a PHB, 
  *> and a DSCP as part of a service ID. This allows
  *> flexible addition of a service specfic parameter 
  *> TLV. If it is required. 
  *> Examples:
  *> Service specific parameters are absent by 
  *> definition the case of Less Than Best Effort.
  *> They must be the IntServ Guaranteed service 
  *> parametrisation (like Flowspec etc.), should 
  *> the latter be signaled that way. 
  *> 
  *> Regards, Rüdiger 
  *> 
  *> 

Rudiger,

I'm sorry, I don't seem to have made myself clear.

The Int-serv CType defines the format for an IntServ flowspec for a
family of Intserv services.  This format is very general.  It includes
some common fields like MTU sizes and policing, because in our judgment
these will often be of concern to applications.  [I suggest that you
think very carefully about ignoring this wisdom and omitting these
common fields; they are born out of quite a lot of Internet experience.]

However, you are free to create a new format, say a DiffServ flowspec
format.  That's fine, you define that format (which presumably includes
a service type number,a service name, a PHB, a DSCP, ... whatever you
need.  And for this format you get ONE new CType.

I hope this is clearer.

Bob Braden