Subject: Re: [NSIS] RE: I-D ACTION:draft-ietf-nsis-qspec-07.txt

From: Xiaoming Fu <[email-masked]>
Date: Fri, 04 Nov 2005 12:07:57 +0100

Hi Jerry,

While updating the Controlled-Load Services QOSM CLS we figured out 
another open issue:

  * What object(s) should a Query message contain? *

More specificially (copied from 
http://www.ietf.org/internet-drafts/draft-kappler-nsis-qosmodel-controlledload-03.txt):
    3.  Issue concerning the "RSVP-Style Reservation".  In RSVP, the PATH
    message sends a Sender_TSPEC (primarily token bucket reflecting the
    sender traffic's characteristics) in addition to ADSpec.  The token
    bucket in the RESERVE message is an update of the token bucket in the
    PATH message considering the available bandwidth.  In QoS NSLP, there
    are three alternative means for composing and interpreting the QSPEC
    in a QUERY message:
    o  Use a single QoS Available object (which in turn carries available
       bandwidth in QUERY, allow each QNE be able to modify and forward
       it, and let the QNR originate a QoS Desired (Token Bucket) object
       based on this QoS Available object.  The current draft utilizes
       this approach, however it is not clear whether this will be done.
    o  Use a token bucket (QNE-readonly) plus available bandwidth (QNE
       readable and writable) in QUERY, and let the QNR compose the QoS
       Desired based on the available bandwidth information gathered
       along the path and the token bucket originally specified by the
       QNI.  This is more similar to RSVP/IntServ but requires further
       study.
    o  Use a single Token Bucket parameter as QoS Available object in
       QUERY, let QNEs interpret certain fields in the Token Bucket
       (e.g., average/peak rate) as bandwidth, and the QNR compose a new
       Token Bucket as QoS Desired.  This seems to simplify the object
       but may need different interpretations of a Token Bucket.

We would be glad to hear views on this.
Cheers,
Xiaoming
Ash, Gerald R (Jerry), ALABS wrote:
> Hi All,
> 
> Please review and comment on the updated 'QoS-NSLP QSPEC Template' I-D
> at http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-07.txt.
> 
> The updates include the following (including -06 updates):
> 
> 1. defined "error flag" for error handling, Section 4.5.1
> 2. defined "not-supported flag" and "tunneled parameter flag", Section
> 4.5.2
> 3. updated bit error rate (BER) parameter to packet loss ratio (PLR)
> parameter, Section 5.2.2 & 7.2.10
> 4. added packet error ratio (PER) parameter, Section 5.2.2 & 7.2.11
> 5. added text (from David Black) on DiffServ QSPEC example, Section 6.2
> 6. coding checked by independent expert and updated to include RE flags
> in QSPEC objects and MENT flags in QSPEC parameters, Section 7
> 7. expanded IANA Considerations, Section 9
> 
> Remaining open issues include:
> 
> 1. placement of packet_classifier in QSPEC or QoS-NSLP?
> 
> Please review and comment.
> 
> Thanks,
> Regards,
> Jerry

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

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Fri, 4 Nov 2005 06:31:43 -0600

Hi Xiaoming,

Thanks for your comments, my initial suggestion is below.  We can
discuss further in Vancouver.

Thanks,
Regards,
Jerry 

> -----Original Message-----
> From: Xiaoming Fu [mailto:[email-masked]] 
> Sent: Friday, November 04, 2005 6:08 AM
> To: Ash, Gerald R (Jerry), ALABS
> Cc: [email-masked]
> Subject: Re: [NSIS] RE: I-D ACTION:draft-ietf-nsis-qspec-07.txt
> 
> Hi Jerry,
> 
> More specifically (copied from 
>
http://www.ietf.org/internet-drafts/draft-kappler-nsis-qosmodel-controll
edload-03.txt):
>     3.  Issue concerning the "RSVP-Style Reservation".  In 
> RSVP, the PATH message sends a Sender_TSPEC (primarily token
> bucket reflecting the sender traffic's characteristics) in
> addition to ADSpec.  The token bucket in the RESERVE message is
> an update of the token bucket in the PATH message considering the
> available bandwidth.  In QoS NSLP, there are three alternative
> means for composing and interpreting the QSPEC in a QUERY
> message:
>     o  Use a single QoS Available object (which in turn carries
>        available bandwidth in QUERY, allow each QNE be able to modify 
>        and forward it, and let the QNR originate a QoS Desired (Token 
>        Bucket) object  based on this QoS Available object.  The
>        current draft utilizes this approach, however it is not clear
>        whether this will be done.
>        readable and writable) in QUERY, and let the QNR compose the
>        QoS Desired based on the available bandwidth information
>        gathered along the path and the token bucket originally
>        specified by the QNI.  This is more similar to RSVP/IntServ but
>        requires further study.
>        (e.g., average/peak rate) as bandwidth, and the QNR compose a
>        new Token Bucket as QoS Desired.  This seems to simplify the
>        object but may need different interpretations of a Token
>        Bucket.
> 

For simplicity, I'd suggest the third approach.  Token Bucket parameter
[r] would normally translate directly to average bandwidth.  If both [r]
and [p] are used, then a mapping using both average/peak statistics
would map to 'bandwidth'.

It would be good to hear other views on this.