Hi Jerry
Thanks for the comments!
Please see in line!
On 3/19/2010, "Gerald Ash" <gash5107@xxxxxxxxx> 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 <karagian@xxxxxxxxxxxxx> wrote:
>
>
>From: Georgios Karagiannis <karagian@xxxxxxxxxxxxx>
>Subject: Re: [NSIS] Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The Resource Management in Diffserv QOS Model) to Experimental RFC
>To: "Gerald Ash" <gash5107@xxxxxxxxx>, "ietf@xxxxxxxx" <ietf@xxxxxxxx>, "nsis@xxxxxxxx" <nsis@xxxxxxxx>
>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" <karagian@xxxxxxxxxxxxx> 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" <gash5107@xxxxxxxxx> 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 <gash5107@xxxxxxxxx> wrote:
>>>
>>>
>>>From: Gerald Ash <gash5107@xxxxxxxxx>
>>>Subject: Re: [NSIS] Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The Resource Management in Diffserv QOS Model) to Experimental RFC
>>>To: ietf@xxxxxxxx, nsis@xxxxxxxx
>>>Cc: "Jerry Ash" <gash5107@xxxxxxxxx>
>>>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 <iesg-secretary@xxxxxxxx> wrote:
>>>
>>>
>>>From: The IESG <iesg-secretary@xxxxxxxx>
>>>Subject: [NSIS] Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The Resource Management in Diffserv QOS Model) to Experimental RFC
>>>To: "IETF-Announce" <ietf-announce@xxxxxxxx>
>>>Cc: nsis@xxxxxxxx
>>>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
>>>ietf@xxxxxxxx mailing lists by 2010-03-22. Exceptionally,
>>>comments may be sent to iesg@xxxxxxxx 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
>>>nsis@xxxxxxxx
>>>https://www.ietf.org/mailman/listinfo/nsis
>>>
>>>
>>>
>>>
>>> )
>>_______________________________________________
>>nsis mailing list
>>nsis@xxxxxxxx
>>https://www.ietf.org/mailman/listinfo/nsis
>
>
>
> )
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf