Re: [NSIS] Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The Resource Management in Diffserv QOS Model) to Experimental RFC

["Georgios Karagiannis" <[e-mail]>]

Hi Jerry

Thanks for the comments!

Please see in line!

On 3/19/2010, "Gerald Ash" <[e-mail]> wrote:

>Looks good, and adds clarity to how RMD-QOSM functions.  Two comments:
> 
>1. RE
>"   Thus in our example we calculate b as:
>
>      b = p * MPS * "period of time".
>
>   For this VoIP example, we can assume that this period of time is 1,5
>   seconds, see below:
>
>      b = 10000 octets/s * 220 octets * 1,5 seconds = 3300000 octets"
> 
>IMO the above expression should not be multiplied by MPS, but rather should be
> 
>"   Thus in our example we calculate b as:
>
>      b = p * "period of time".
>
>   For this VoIP example, we can assume that this period of time is 1.5
>   seconds, see below:
>
>      b = 10000 octets/s * 1.5 seconds = 15000 octets"

Georgios: Okay, we will include this change!

> 
>Or, alternatively, b = ~ 68 MPS-size packets.
> 
>Also, perhaps the "1.5" notation should be used rather than the "1,5" notation?
> 
>2. It would further clarify if you put in the bit-level example of the RMD-QSPEC, as called for by QOSM requirements given in the QSPEC draft.  E.g., such a bit-level QSPEC example is given in Section 4.5 ("Bit-Level QSPEC Example") of the Y.1541-QOSM draft (http://tools.ietf.org/html/draft-ietf-nsis-y1541-qosm-10#section-4.5).  This would clarify, for example, the QSPEC Procedure being used and other bit-level details.

Georgios: but this is already specified in Section 4.1. We could include
a sentence in the appendix: "The bit level format of the RMD-QSPEC is
specified in Section 4.1."

Best regards,
Georgios
r
> 
>Thanks,
>Jerry
>
>--- On Thu, 3/18/10, Georgios Karagiannis <[e-mail]> wrote:
>
>
>From: Georgios Karagiannis <[e-mail]>
>Subject: Re: [NSIS] Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The Resource Management in Diffserv QOS Model) to Experimental RFC
>To: "Gerald Ash" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
>Date: Thursday, March 18, 2010, 4:39 AM
>
>
>Hi all
>
>Based on the suggestion of Jerry we have written an example on matching
>the initiator QSPEC to a local RMD-QSPEC, see below!
>
>We would like to include this section in Appendix A.6 of the new version
>of the RMD-QOSM draft.
>
>
>-------------------------
>
>A.6.  Example on matching the initiator QSPEC to the local RMD-QSPEC
>
>   Section 3.4 of [QSP-T] describes an example of how the QSPEC can be
>used
>   within QOS-NSLP. Figure A.4 illustrates a situation where a QNI and a
>   QNR are using an end to end QOSM, denoted in this context as Z-e2e. It
>   is considered that the QNI access network side is a wireless access
>   network built on a generation "X" technology with QoS support as
>defined
>   by generation "X", while QNR access network is a wired/fixed access
>   network with its own defined QoS support. Furthermore, it is considered
>   that the shown QNE edges are located at the boundary of a RMD domain
>and
>   that the shown QNE Interior nodes are located inside the RMD domain.
>The
>   QNE edges are able to run both the Z-e2e QOSM and the RMD-QOSM, while
>   the QNE interior nodes can only run the RMD-QOSM. The QNI that is
>   considered to e.g., be a wireless laptop, while the QNR a PC.
>
>
>
>     |------|   |------|                           |------|   |------|
>     |Z-e2e |<->|Z-e2e |<------------------------->|Z-e2e |<->|Z-e2e |
>     | QOSM |   | QOSM |                           | QOSM |   | QOSM |
>     |      |   |------|   |-------|   |-------|   |------|   |      |
>     | NSLP |   | NSLP |<->| NSLP  |<->| NSLP  |<->| NSLP |   | NSLP |
>     |Z-e2e |   |  RMD |   |  RMD  |   |  RMD  |   | RMD  |   | Z-e2e|
>     | QOSM |   | QOSM |   | QOSM  |   | QOSM  |   | QOSM |   | QOSM |
>     |------|   |------|   |-------|   |-------|   |------|   |------|
>     -----------------------------------------------------------------
>     |------|   |------|   |-------|   |-------|   |------|   |------|
>     | NTLP |<->| NTLP |<->| NTLP  |<->| NTLP  |<->| NTLP |<->| NTLP |
>     |------|   |------|   |-------|   |-------|   |------|   |------|
>       QNI         QNE        QNE         QNE         QNE       QNR
>     (End)  (Ingress Edge) (Interior)  (Interior) (Egress Edge)  (End)
>
>       Figure A.4. Example of Initiator & Local Domain QOSM Operation
>
>
>
>   The QNI sets QoS Desired and QoS Available QSPEC objects in the
>   initiator QSPEC, and initializes QoS Available to QoS Desired. In this
>   example, the <Minimum QoS> object is not populated. The QNI populates
>   QSPEC parameters to ensure correct treatment of its traffic in domains
>   down the path. Additionally, to ensure correct treatment further down
>   the path, the QNI includes <PHB Class> in <QoS Desired>.  The QNI
>   therefore includes in the QSPEC
>
>     QoS Desired = <TMOD> <PHB Class>
>     QoS Available = <TMOD> <Path Latency>
>
>   In this example it is assumed that the <TMOD> parameter is used to
>   encode the traffic parameters of a VoIP application that uses RTP and
>   the G.711 Codec, see Appendix B in [QSP-T].
>   The below text is copied from [QSP-T].
>
>   "In the simplest case the Minimum Policed Unit m is the sum of the
>   IP-, UDP- and RTP- headers + payload. The IP header in the IPv4 case
>   has a size of 20 octets (40 octets if IPv6 is used). The UDP header
>   has a size of 8 octets and RTP uses a 12 octet header. The G.711
>   Codec specifies a bandwidth of 64 kbit/s (8000 octets/s). Assuming
>   RTP transmits voice datagrams every 20ms, the payload for one
>   datagram is 8000 octets/s * 0.02 s = 160 octets.
>
>   IPv4+UDP+RTP+payload: m=20+8+12+160 octets = 200 octets
>   IPv6+UDP+RTP+payload: m=40+8+12+160 octets = 220 octets
>
>   The Rate r specifies the amount of octets per second. 50 datagrams
>   Are sent per second.
>
>   IPv4: r = 50 1/s * m = 10,000 octets/s
>   IPv6: r = 50 1/s * m = 11,000 octets/s
>
>   The bucket size b specifies the maximum burst. In this example a
>   burst of 10 packets is used.
>
>   IPv4: b = 10 * m = 2000 octets
>   IPv6: b = 10 * m = 2200 octets ", from [QSP-T].
>
>   In our example we will assume that IPV4 is used and therefore, the
>   <TMOD-1> values will be set as follows:
>
>   m = 200 octets
>   r = 10000 octets/s
>   b = 2000 octets
>
>   The Peak Data Rate-1 (p) and MPS are not specified above, but in our
>   example we will assume:
>
>   p = r = 10000 octets/s
>   MPS = 220 octets.
>
>   The <PHB Class> is set in such a way that the Expedited Forwarding
>   (EF) PHB is used.
>   Since <Path Latency> and <QoS Class> are not vital parameters from
>   the QNI's perspective, it does not raise their M flags.
>
>   Each QNE, which supports the Z-e2e QOSM on the path, reads and
>   interprets those parameters in the initiator QSPEC.
>
>   When an end-to-end RESERVE message is received at a QNE Ingress node
>   at the RMD domain border then the QNE ingress can 'hide' the
>initiator
>   end-to-end RESERVE message so that only the QNE edges process the
>   initiator (end-to-end) RESERVE message, which then bypasses
>   intermediate nodes between the edges of the domain, and issues its own
>   local RESERVE message (see Section 6).  For this new local RESERVE
>   message, the QNE Ingress node generates the local RMD-QSpec. The
>   RMD-QSpec corresponding to the RMD-QOSM is generated based on
>   the original initiator QSPEC according to the procedures described in
>   Section 4.5 of [QoS-NSLP] and in Section 6 of this draft.  The RMD QNE
>   ingress maps the <TMOD-1> parameters contained in the original
>initiator
>   QSPEC into the equivalent <TMOD-1> parameter representing only the peak
>   bandwidth in the local RMD-QSpec.
>
>   In this example the initial <TMOD-1> parameters are mapped into the
>   RMD-QSpec <TMOD-1> parameters as follows.
>
>   As specified the RMD-QOSM bandwidth equivalent <TMOD-1> parameter of
>   RMD-QSpec should have:
>
>      r = p of initial e2e <TMOD-1> parameter
>      m = large;
>      b = large;
>
>   For the RMD-QSpec <TMOD-1> parameter the following values are
>   calculated:
>
>      r = p of initial e2e <TMOD-1> parameter = 10000 octets/s
>      m is set in this example to large as follows:
>      m = MPS of initial e2e <TMOD-1> parameter = 220 octets
>
>   The maximum value of b = 250 Gbytes, but in our example this value is
>   quite large. The b parameter specifies the extent to which the data
>rate
>   can exceed the sustainable level for short periods of time.
>   In order to get a large b, in this example we consider that for a
>   period of certain period of time the data rate can exceed the
>   sustainable level, which in our example is the peak rate (p).
>
>   Thus in our example we calculate b as:
>
>      b = p * MPS * "period of time".
>
>   For this VoIP example, we can assume that this period of time is 1,5
>   seconds, see below:
>
>      b = 10000 octets/s * 220 octets * 1,5 seconds = 3300000 octets
>
>   Thus the local RMD-QSpec <TMOD-1> values are:
>
>      r = 10000 octets/s
>      p = 10000 octets/s
>      m = 220 octets
>      b = 3300000 octets
>      MPS = 220 octets
>
>   The local RMD QSPEC for example also needs <PHB Class>, which in this
>   example is representing the EF PHB class.
>
>   The RMD QNE egress node updates QoS Available on behalf of the entire
>   RMD domain if it can.  If it cannot (since the M flag is not set for
>   <Path Latency>) it raises the parameter-specific, 'not-supported'
>flag,
>   warning the QNR that the final latency value in QoS Available is
>   imprecise.
>
>   In the "Y" access domain, the initiator QSPEC is processed by the QNR
>   in the similar was as it was processed in the "X" wireless access
>   domain, by the QNI. If the reservation was successful, eventually the
>   RESERVE request arrives at the QNR (otherwise the QNE at which the
>   reservation failed would have aborted the RESERVE and sent an error
>   RESPONSE back to the QNI).  If the RII was included in the QoS NSLP
>   message, the QNR generates a positive RESPONSE with QSPEC objects QoS
>   Reserved and QoS Available.  The parameters appearing in QoS Reserved
>   are the same as in QoS Desired, with values copied from QoS Available.
>   Hence, the QNR includes the following QSPEC objects in the RESPONSE:
>
>    QoS Reserved = <TMOD> <PHB Class>
>    QoS Available = <TMOD> <Path Latency>
>
>-------------
>
>Best regards,
>
>Georgios
>
>On 3/2/2010, "Georgios Karagiannis" <[e-mail]> wrote:
>
>>Hi Jerry
>>
>>We will include in the Appendix a similar example as the one given in
>>Section 3.4 of the QSPEC draft.
>>
>>Best regards,
>>Georgios
>>
>>On 3/2/2010, "Gerald Ash" <[e-mail]> wrote:
>>
>>>One more comment:
>>> 
>>>Section 3.1 of the QSPEC draft http://tools.ietf.org/html/draft-ietf-nsis-qspec-24#section-3.1 lists requirements for QOSM specifications including "QNE processing rules describing how QSPEC information is treated and interpreted"and "at least one bit-level QSPEC example".
>>> 
>>>While the RMD draft has examples in Appendix A of individual processing functions, there is no overall, end-to-end example given of QSPEC composition and processing from QNI to QNR and back again.  IMO this would greatly help an overall understanding of RMD functionality.
>>> 
>>>Such QSPEC processing examples are given in Sections 4.4 ("Processing Example") and 4.5 ("Bit-Level QSPEC Example") of the Y.1541-QOSM draft (http://tools.ietf.org/html/draft-ietf-nsis-y1541-qosm-10#section-4.4)
>>>and
>>>Section 3.4 ("Example of QSPEC Processing") of the QSPEC draft (http://toolsietf.org/html/draft-ietf-nsis-qspec-24#section-3.4).
>>> 
>>>Thanks,
>>>Jerry
>>>
>>>--- On Mon, 3/1/10, Gerald Ash <[e-mail]> wrote:
>>>
>>>
>>>From: Gerald Ash <[e-mail]>
>>>Subject: Re: [NSIS] Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The Resource Management in Diffserv QOS Model) to Experimental RFC
>>>To: [e-mail], [e-mail]
>>>Cc: "Jerry Ash" <[e-mail]>
>>>Date: Monday, March 1, 2010, 2:20 PM
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>Minor editorial comments:
>>> 
>>>1. page 35:
>>>"  the "Peak Data Rate-1 (p)" value of the <Bandwdith> parameter.
>>>   When the QNE edges use aggregated intra-domain QoS-NSLP operational
>>>   states, then the "Peak Data Rate-1 (p)" value of the <Bandwdith>"
>>>substitute <TMOD-1> for <Bandwdith> 
>>> 
>>>2. page 101:
>>>"  directions by using the procedure described in Section 4.6.2.3 and
>>>   including in the  <Bandwith> parameter within the "RMD-QOSM QOS
>>>   Description" field carried by the "forward" intra-domain RESERVE the"
>>>substitute <TMOD-1> for <Bandwith>
>>> 
>>>Thanks,
>>>Jerry
>>>
>>>
>>>--- On Mon, 3/1/10, The IESG <[e-mail]> wrote:
>>>
>>>
>>>From: The IESG <[e-mail]>
>>>Subject: [NSIS] Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The Resource Management in Diffserv QOS Model) to Experimental RFC
>>>To: "IETF-Announce" <[e-mail]>
>>>Cc: [e-mail]
>>>Date: Monday, March 1, 2010, 9:38 AM
>>>
>>>
>>>The IESG has received a request from the Next Steps in Signaling WG 
>>>(nsis) to consider the following document:
>>>
>>>- 'RMD-QOSM - The Resource Management in Diffserv QOS Model '
>>>   <draft-ietf-nsis-rmd-16.txt> as an Experimental RFC
>>>
>>>The IESG plans to make a decision in the next few weeks, and solicits
>>>final comments on this action.  Please send substantive comments to the
>>>[e-mail] mailing lists by 2010-03-22. Exceptionally, 
>>>comments may be sent to [e-mail] instead. In either case, please 
>>>retain the beginning of the Subject line to allow automated sorting.
>>>
>>>The file can be obtained via
>>>http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-16.txt
>>>
>>>
>>>IESG discussion can be tracked via
>>>https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12558&rfc_flag=0
>>>
>>>_______________________________________________
>>>nsis mailing list
>>>[e-mail]
>>>https://www.ietf.org/mailman/listinfo/nsis
>>>
>>>
>>>
>>>
>>>      )
>>_______________________________________________
>>nsis mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/nsis
>
>
>
>      )