Subject: RE: [NSIS] QSPEC Comment: QSPEC QoS Object Header

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 3 Jul 2006 09:27:55 +0100

hi all,

just a comment on length fields and M-bits:

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: 03 July 2006 09:20
> To: Ash, Gerald R (Jerry), ALABS
> Cc: "Attila Báder (IJ/ETH)"; NSIS; Kappler Cornelia
> Subject: Re: [NSIS] QSPEC Comment: QSPEC QoS Object Header
> 
> 
> Hi Jerry,
> 
> please find my response below:
> 
> Ash, Gerald R (Jerry), ALABS wrote:
> > Hi Hannes,
> > 
> > See below.
> > 
> > 
> >> -----Original Message----- From: Hannes Tschofenig
> >> [mailto:[email-masked]] Sent: Sunday, July 02, 2006 4:47
> >> AM To: NSIS Subject: [NSIS] QSPEC Comment: QSPEC QoS Object Header
> >> 
> >> Hi QSPEC authors,
> >> 
> >> I tried to figure out whether the QSPEC template draft could be
> >> used for the AAA work. The QSPEC QoS object header raised a few
> >> questions:
> >> 
> >> * Why do you need a length field if all the objects just have a
> >> fixed length?
> > 
> > 
> > The length of various QSPEC parameters is not fixed.  E.g., compare
> > Section 7.2.5 <Token Bucket> (length=5) to Section 7.2.3 <Bandwidth>
> > (length=1).
> 
> 
> No, I meant that the Parameter ID would immediately tell you 
> the length 
> of the respective attribute.
> 
> For every object the length of the object cannot be variable.

what if the parameter ID is a new one unknown at the receiver of the
message (e.g. for an optional object)? you may still want to parse
the rest of the message, and you need to know what to skip over.

> 
> > 
> >> * Why do you need an 'M' bit? Whether a parameter is mandatory or
> >> not can easily derived from the Parameter ID.
> > 
> > 
> > We were advised that the M flag should be specified for easier QSPEC
> > processing.
> 
> I don't see the big advantage. Instead of looking at the flag 
> and then 
> processing the Parameter ID I would have to look at the 
> Parameter ID and 
> then see immediately whether it is a mandatory attribute or not.

same comment on unknown IDs; and see below.

> 
> 
>    In addition, new QSPEC versions specifying new mandatory
> > parameters and/or unrecognized optional parameters could 
> also mandate
> > that this flag be used.
> 
> The current text in the draft does not provide a solid story 
> about the 
> QSPEC version updates. It says
> "
> Additional mandatory parameters may be defined in the future.
>     However, since this requires an update of all QNEs, this should be
>     considered carefully.
> "
> 
> If this is the requirement then it can never happen that a QNE sees a 
> mandatory parameter that it does not understand.

i think this is a pointer that a tradeoff needs to be made. if
you decide to use a new mandatory parameter, then be aware that
error messages may come back that it is not understood. it
should still be possible to define new mandatory parameters, but
it just has to be done with care and caution.

robert h.

> 
> 
> > 
> > 
> >> * Why do you need the 'T' flag? I don't think that the concept is 
> >> actually useful.
> >> 
> >> In Section 4.5.3 you write:
> >> 
> >> 4.5.3 QSPEC Tunneled Parameter T-Flag
> >> 
> >> Each QSPEC parameter has an associated 'tunneled-parameter T-flag'.
> >>  When a RESERVE message is tunneled through a domain, QNEs inside
> >> the domain cannot update read-write parameters.
> >> 
> >> [hannes] QNEs MUST NOT update the parameters. That's the idea of
> >> tunneling.
> >> 
> >> The egress QNE in a domain has two choices: either a) it is
> >> configured to have the knowledge to update the parameters
> >> correctly,
> >> 
> >> [hannes] What type of update are you looking for? The reservation
> >> within the tunneled region is a separate and independent 
> >> reservation.
> > 
> > 
> > Not sure what you mean by "separate and independent reservation".
> 
> See Section 4.6 of
> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-11.txt
> and
> http://www.ietf.org/internet-drafts/draft-ietf-nsis-tunnel-00.txt
> 
> Figure 12 in ection 4.6 of
> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-11.txt
> is particularly nice since it shows that the 
> RESERVE'/RESPONSE' within 
> the domain are independent of the E2E RESERVE/RESPONSE.
> 
> > We're talking about an end-to-end reservation where one domain may
> > tunnel the Initiator QSPEC through the domain.  With respect to the
> > 'update', it refers to the egress QNE in the domain updating a
> > mandatory or optional QSPEC parameter in the Initiator QSPEC.  E.g.,
> > if the <bandwidth> parameter (a mandatory QSPEC parameter) is
> > specified in the <QoS Available> object in the Initiator QSPEC, and
> > the Initiator QSPEC is tunneled through a domain, the egress QNE in
> > the domain may be configured to update this parameter.
> 
> Why would it want to update the parameter?
> 
>    If it cannot
> > update this parameter, then it needs to set the T-Flag to so
> > indicate.
> 
> If he wants to update the parameter why would there be a 
> problem with it?
> 
> > 
> > 
> >> or b) it cannot update the parameters.  In the latter case it MUST
> >> set the tunneled-parameter T-flag to tell the QNI (or QNR) that the
> >>  information contained in the read-write parameter is most likely 
> >> incorrect (or a lower bound).
> >> 
> >> [hannes] Which parameters are incorrect?
> > 
> > 
> > If in the above example, the egress QNE in the domain is unable to
> > update <bandwidth> in the <QoS Available> object, it must then set
> > the T-flag for the <bandwidth> parameter.
> > 
> > 
> >> The T-flag is interpreted by the QNI, ingress QNE (start of tunnel
> >> in a domain), egress QNE (end of tunnel in a domain), or QNR.
> >> 
> >> [hannes] There are now three 'T' bits flying around in related
> >> documents:
> >> 
> >> * T-bit set (RESERVE tear): QoS NSLP * T-bit in the NSIS Tunnel ID 
> >> * T-bit in the QSPEC draft
> >> 
> >> Neither the QoS NSLP nor the NSIS Tunnel ID does, to my knowledge,
> >> not use the T-bit of the QSPEC document.
> > 
> > 
> > The T-bit in the QSPEC draft is strictly for use by the RMF in QoS
> > processing, so I think its use is restricted to 
> implementation of the
> > NSLP/QSPEC/RMF procedures.  However, you raise a good point about 3
> > different definitions for 'T-bit', and we need to be sure 
> there is no
> > confusion resulting from this.
> > 
> 
> Why does the RMF need this info?
> 
> > 
> >> * Why do you need to put error specific flag in every object 
> >> (namely 'E and N flag)? Errors should be the exception rather than
> >> the norm. I would do something different, namely to put an error
> >> object with a list of the Parameter IDs in it.
> > 
> > 
> > The use of E-Flag is definitely the exception rather than the norm.
> > IMO the approach defined in Section 4.5.1 is a reasonable approach,
> > that is, to flag an error according to a specific QSPEC 
> parameter, if
> > possible.  However, as stated in Section 4.5.1, in some error
> > situations it may not be possible to set the E-Flag for a QSPEC
> > parameter, although it may be possible to still set the E-Flag for
> > the QSPEC object.  The INFO_SPEC in this case does carry the QSPEC
> > with the erroneous parameters flagged within it.  The 
> alternative you
> > suggest I think is similar to this approach (this approach agreed to
> > after a very lengthy discussion on error codes).
> > 
> 
> So, what you are going todo?
> 
> > 
> >> Regarding the parameter encoding:
> >> 
> >> You might want to change the description with regard to the 
> >> Parameter ID field. Change from:
> >> 
> >> " 7.2.1 <NON QOSM Hop> Parameter
> >> 
> >> 0                   1                   2                   3 0 1 2
> >> 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >> |1|E|0|T|           0           |r|r|r|r|          1            | 
> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
> >> NON QOSM Hop  |                 Reserved                      | 
> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ "
> >> 
> >> 
> >> to:
> >> 
> >> " 7.2.1 <NON QOSM Hop> Parameter
> >> 
> >> 0                   1                   2                   3 0 1 2
> >> 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >> |1|E|0|T|00000000000000000000000|r|r|r|r|          1            | 
> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
> >> NON QOSM Hop  |                 Reserved                      | 
> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ "
> >> 
> >> 
> >> or: " 7.2.1 <NON QOSM Hop> Parameter
> >> 
> >> 0                   1                   2                   3 0 1 2
> >> 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >> |1|E|0|T|     Parameter ID      |r|r|r|r|      Length           | 
> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
> >> NON QOSM Hop  |                 Reserved                      | 
> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> 
> >> Parameter ID: 0
> >> 
> >> Length: 1
> >> 
> >> "
> >> 
> >> The Parameter ID is 12 bits long. Is it also encoded in network
> >> byte order? The same is true for the Length field.
> >> 
> >> The draft only says that "Network byte order ('big-endian') for all
> >> 16- and 32-bit integers, as well as 32-bit floating point numbers,
> >> are as specified in [RFC1832, IEEE754, NETWORK-BYTE-ORDER]. "
> > 
> > 
> > I'm not sure I get the point you're making here.
> 
> 
> The point is: What is the encoding of the parameters.
> The text and the figure does not provide enough details to 
> figure it out.
> 
> 
>    For the <NON QOSM
> > HOP> case, however, perhaps this flag should be coded as a QSPEC
> > object flag and not a 32-bit parameter, as suggested in the previous
> > message.
> 
> 
> Ciao
> Hannes
> 
> 
> > 
> > Thanks, Jerry
> > 
> > 
> >> Ciao Hannes
> > 
> > 
> > 
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 03 Jul 2006 10:44:22 +0200

Hi Robert,

> the rest of the message, and you need to know what to skip over.

You are definitely right. Bogus idea.

I guess what I would like to see is a simple TLV structure so that I 
could also use it for RADIUS and Diameter.

I was also curious about the 32 bit alignment. For some reason this was 
done in the QoS NSLP (maybe in GIST as well) but why is this helpful here?

> it just has to be done with care and caution.

I think that the addition of new mandatory parameters requires a second 
thought and a bit more text.

Ciao
Hannes