Hi Jerry
Based on your latest comments I have changed the new appendix section
A.6, see below:
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 * "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
Thus the local RMD-QSpec <TMOD-1> values are:
r = 10000 octets/s
p = 10000 octets/s
m = 220 octets
b = 15000 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 bit level format of the RMD-QSPEC can be derived from Section 4.1.
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/20/2010, "Georgios Karagiannis" <karag...@cs.utwente.nl> wrote:
>Hi Jerry
>
>Thanks for the comments!
>
>Please see in line!
>
>On 3/19/2010, "Gerald Ash" <gash5...@yahoo.com> 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 15
>> 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 <karag...@cs.utwente.nl> wrote:
>>
>>
>>From: Georgios Karagiannis <karag...@cs.utwente.nl>
>>Subject: Re: [NSIS] Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The Resource
>>Management in Diffserv QOS Model) to Experimental RFC
>>To: "Gerald Ash" <gash5...@yahoo.com>, "ietf@ietf.org" <ietf@ietf.org>,
>>"n...@ietf.org" <n...@ietf.org>
>>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" <karag...@cs.utwente.nl> 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" <gash5...@yahoo.com> 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 <gash5...@yahoo.com> wrote:
>>>>
>>>>
>>>>From: Gerald Ash <gash5...@yahoo.com>
>>>>Subject: Re: [NSIS] Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The Resource
>>>>Management in Diffserv QOS Model) to Experimental RFC
>>>>To: ietf@ietf.org, n...@ietf.org
>>>>Cc: "Jerry Ash" <gash5...@yahoo.com>
>>>>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-secret...@ietf.org> wrote:
>>>>
>>>>
>>>>From: The IESG <iesg-secret...@ietf.org>
>>>>Subject: [NSIS] Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The Resource
>>>>Management in Diffserv QOS Model) to Experimental RFC
>>>>To: "IETF-Announce" <ietf-annou...@ietf.org>
>>>>Cc: n...@ietf.org
>>>>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@ietf.org mailing lists by 2010-03-22. Exceptionally,
>>>>comments may be sent to i...@ietf.org 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
>>>>n...@ietf.org
>>>>https://www.ietf.org/mailman/listinfo/nsis
>>>>
>>>>
>>>>
>>>>
>>>> )
>>>_______________________________________________
>>>nsis mailing list
>>>n...@ietf.org
>>>https://www.ietf.org/mailman/listinfo/nsis
>>
>>
>>
>> )
>_______________________________________________
>nsis mailing list
>n...@ietf.org
>https://www.ietf.org/mailman/listinfo/nsis
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
