Subject: [NSIS] Further QSPEC comments

From: Roland Bless <[email-masked]>
Date: Mon, 19 Mar 2007 16:14:24 +0100

Hi,

too late for the WG last call, but I have a few comments
nevertheless [but they are no showstoppers :-)].
The document seems to come closer to a usable version,
great!
My comments:
* There seems to be a mix of different strategies:
  (A) allow to attach special parameters which may not be
  understood by every QNE (QoSM). We have the M-flags for this
  purpose etc. The QSPEC-type doesn't change, i.e.,
  we could use one QSPEC for all QoSMs. Each RMF has to
  parse all QSPEC parameters and decide on each parameter type whether
  it understands them or not (which may not be a problem if
  M-flag is not set).
  (B) allow to attach special/new parameters (and even a different
  overall layout) by defining a different QPEC-Type. In this model
  each QoSM that needs QOSM-specific parameters simply defines a
  corresponding layout of different parameters it requires and
  get a new QSPEC type. The RMF then simply knows which QSPEC
  types it understands.

  Probably we could combine both approaches, but currently
  we have more (A), so a QSPEC type would probably
  not be necessary. If this is adopted, a good idea would be
  to have a flag on a parameter level that flags it as being
  only of local significance...

* 4.3.2 defines PLR as packet loss _rate_ whereas 6.2.5
  defines PLR as packet loss _ratio_. Please clarify
  If it's ratio and not rate then you probably have a
  cut&paste error in 6.2.5:
   "value.  The PLRs are reported in units of 10^-11.  A system with
   resolution less than one microsecond MUST set unused digits to zero."
  last sentence makes no sense to me...

* 4.3.3 Traffic Handling Directives
  I'm probably don't get the full motivation for this.
  At least from a DiffServ point of view it's usually
  defined in the PDB what to do with excess packets.
  Probably in rare cases there is a choice between
  shaping or dropping, but usually the application
  cannot decide on this. So as feedback signal from
  a QNE maybe useful, but as desired by application?

* 4.3.4 Traffic classifiers
  I don't know why an _application_ should specify
  a PHB it want resources for? Usually it's up to
  the QoSM to map a QSPEC request to a particular
  service class (and thus PHB). Especially, I don't
  know what the following sentence should mean:
  "Note that PHB class is normally set by a downstream
   QNE to tell the QNI how to mark traffic to ensure
   treatment committed by admission control."
  Usually you mark packets with a _DSCP_ (may be part
  of a PHB group). This mapping may vary from domain
  to domain and normally the first-hop router will
  set/police this initially. So letting a QNE signal
  a PHB class internally (i.e. inside its DiffServ domain)
  is probably useful, but usually the QNI need not know
  about the mapping to a PHB.
  So IMHO this needs clarification!

* 4.4
  I disagree with the statement:
  "The QNI would normally signal a reservation
  according to the requirements of its supported QOSM."
  This would be counter productive when considering
  interoperability. Consider a mobile node that moves
  or roams between different domains. The QoSM may change
  with each attachment to a new domain.
  I guess it's not a good idea if the node must be aware
  of the QoSM that is used in the currently attached domain.
  (Even if it would that that Diffserv is used, it may
  not know the specific mapping to PHBs/DSCPs anyway)
.
* p.16
  "In the XG domain, the initiator QSPEC is translated into a local
   QSPEC using a similar procedure as described above.  The local QSPEC
   becomes the current QSPEC used within the XG domain, that is, the
   it becomes the first QSPEC on the stack, and the initiator QSPEC is
   second.  This saves the QNEs within the XG domain the trouble of
   re-translating the initiator QSPEC, and simplifies processing in
   the local domain.  At the egress edge of the XG domain, the
   translated local QSPEC is popped, and the initiator QSPEC returns to
   the number one position."
  I guess that there are remnants from the former stacking mechanism
  (see stack..popped...)

* 5.3
   Note that QoS NSLP does not mandate the usage of a RESPONSE message.
   In fact, a RESPONSE message will only be generated if the QNI
   includes an RII (Request Identification Information) in the RESERVE
   message.

   That's not correct, because RESPONSE messages are always generated
   in case of an error or failure IIRC. The above statement thus only
   refers to positive responses.

* 6.1
  QSPEC-Type: I already commented on that one. Is related also to first
  comment.
  QSPEC Proc.: it is confusing that the text talks about a set of bits.
  I guess it would be better to call it "field", because then it is
  less likely that someone it with flags (e.g., the following could be
  misinterpreted as being bit positions, not values...):
                The Message Sequence field can attain the following
                values:

                0: Sender-Initiated Reservations
                1: Receiver-Initiated Reservations
                2: Resource Queries
* 6.2
  Please check for clear definition of a unit for a given parameter!
  TMOD: what are the units for r,b,p and m?
  6.2.5
   "value.  The PLRs are reported in units of 10^-11.  A system with
   resolution less than one microsecond MUST set unused digits to zero."
   makes no sense if PLR is a ratio.
  6.2.6
   "   value.  The PERs are reported in units of 10^-11.  A system with
   resolution less than one microsecond MUST set unused digits to zero."
   makes no sense for a ratio.

* I already voted for removal of QOSM specific parameters in
  6.2.12, 6.2.13 and 6.2.14. They are still in. Maybe related
  to the first point. Probably needs discussion...

Regards,
 Roland

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

---

From: "ASH, GERALD R, ATTLABS" <[email-masked]>
Date: Wed, 21 Mar 2007 05:28:01 -0500

Roland, All, 

> -----Original Message-----
> From: Roland Bless [mailto:[email-masked]] 
> Sent: Monday, March 19, 2007 11:14 AM
> To: [email-masked]
> Subject: [NSIS] Further QSPEC comments
> 
> Hi,
> 
>   overall layout) by defining a different QSPEC-Type. In this model

As discussed in the NSIS meeting yesterday, IMO we don't want to
introduce a new strategy at this point such as (B) (which I don't
clearly understand).  Strategy (A) is the right approach IMO: QNI sets
the M flag = 1 for QSPEC parameters that must be interpreted by
downstream QNEs, and sets M flag = 0 for QSPEC parameters that should be
interpreted but can be ignored by the QNE if need be.
 
>   cut&paste error in 6.2.5:

PLR is packet loss ratio, will correct.

>   last sentence makes no sense to me...

Caught earlier by Robert, will correct.

>   a QNE maybe useful, but as desired by application?

So we should allow that 'setting the excess treatment parameter by a
downstream QNE/RMF is not precluded'?  I think Hannes had a similar
comment.

>   So IMHO this needs clarification!

It was added that 'setting the PHB class by the QNI is not precluded',
based on comments from Robert.  Perhaps you would like to suggest
further revised text?  

>   not know the specific mapping to PHBs/DSCPs anyway)

OK, good point, will revise accordingly.

>    I guess that there are remnants from the former stacking mechanism

OK, will revise.
 
>    refers to positive responses.

OK, will clarify.
 
> * 6.1
>   QSPEC-Type: I already commented on that one. Is related 
>   also to first comment.

OK, will refer to 'field' rather than 'set of bits'.

>    makes no sense if PLR is a ratio.

Right, pointed out by Robert also.

>    makes no sense for a ratio.

Right, pointed out by Robert also.

>   to the first point. Probably needs discussion...

As discussed earlier, I see no benefit in moving these necessary QSPEC
parameters to some other draft(s) that don't even exist yet or have
possible authors.  Quite the opposite, it will just set NSIS back with
more drafts and more delay.  No one else has commented on this
suggestion.

Thanks,
Jerry