Re: QSPEC TMOD and packet header overhead

Hi Bernd,
   
  The example and text look good, thanks!
   
  I agree that it would be worthwhile to include this as an appendix/example in the QSPEC (after all, you and Roland did all the work :-).
   
  Thanks again,
  Regards,
  Jerry


Bernd Schloer <[email protected]> wrote:
  Hi Jerry,

based on Roland's work I have written a numerical example how
the TMOD parameter could be used. Is this of interest for the QSPEC
draft to include?

Best regards,
Bernd

An example VoIP application that uses RTP [RFC 1889] and the
G.711 Codec [ITU-T Rec. G.711] the TMOD-1 parameter could be
set as follows:

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 bytes (40 bytes if IPv6 is used). The UDP
header has a size of 8 bytes and RTP uses a 12 byte header. The
G.711 Codec specifies a bandwidth of 64 kbit/s (8000 bytes/s).
Assuming RTP transmits voice datagrams every 20ms, the payload
for one datagram is 8000 bytes/s * 0.02 s = 160 bytes.

IPv4+UDP+RTP+payload: m=20+8+12+160 bytes = 200 bytes
IPv6+UDP+RTP+payload: m=40+8+12+160 bytes = 220 bytes

The Rate r specifies the amount of bytes per second. 50 datagrams
are sent per second.

IPv4: r = 50 1/s * m = 10,000 bytes/s
IPv6: r = 50 1/s * m = 11,000 bytes/s

The bucket size b specifies the maximum burst. In this example a
burst of 10 packets is used.

IPv4: b = 10 * m = 2000 bytes
IPv6: b = 10 * m = 2200 bytes

A number of extra headers (e.g. for encapsulation) may be included
into the datagram. A non exhaustive list is given below. For
additional headers m, r and b have to be set accordingly.

Protocol Header Size
--------------------------+-----------
GRE [RFC 1701] | 8 bytes
GREIP4 [RFC 1702] | 4-8 bytes
IP4INIP4 [RFC 2003] | 20 bytes
MINENC [RFC 2004] | 8-12 bytes
IP6GEN [RFC 2473] | 40 bytes
IP6INIP4 [RFC 4213] | 20 bytes
IPSec [RFC 4301,RFC 4303] | variable
--------------------------+-----------

Gerald Ash wrote:
> Hi Roland,
> 
> See comments below.
> 
>>> However, as stated at the beginning of Section 5.2 (QSPEC Parameter
>>> Coding):
>>>
>>> "The references in the following sections point to the normative
>>> procedures for processing the QSPEC parameters and
>>> sub-parameters."
>>> 
>>> In the case of TMOD-1 and TMOD-2, the normative references are RFC
>>> 2210 and RFC 2215. In particular, Section 3.1 in RFC 2210 and
> >> Section 3.6 in RFC 2215 give the necessary guidance on setting the
> >> token bucket parameters.
> 
>> Yes, they do, but actually there is no TMOD in RFC 2210. So even if the
>> match is somewhat obvious, it would be probably better to be more exact
>> and point to the SENDER_TSPEC definition in RFC 2210 or the
>> TOKEN_BUCKET_TSPEC definition in RFC 2215.
> 
> Yes I agree that the match between TMOD and TSPEC is pretty obvious. However it can be made even more explicit with specific references to TSPEC (Section 3.1 in RFC 2210 and Section 3.6 in RFC 2215), as you suggest.
> 
>>> IMO the QSPEC document isn't the place to give detailed examples of
>>> how to set these QSPEC parameters, or any other QSPEC parameters,
> >> beyond what is contained in the normative references.
> 
>> IMHO, an example in the appendix would be nice.
> 
> Well, the token bucket algorithm has been around for a long time (even before RSVP of course) so there are ample examples and implementations of its use. IMO it would not be appropriate (and perhaps a bit odd) for the QSPEC to include a tutorial on token bucket.
> 
> While RFCs 2210 and 2215 are the applicable normative description of the TSPEC/TMOD parameters, there are no numerical examples there of its use. So perhaps we could include a reference or 2 to some examples of token bucket implementation. Maybe that would help? A couple of references I'm aware of with numerical examples of token bucket implementation include
> 
> http://www.amazon.com/Computer-Networks-Approach-Kaufmann-Networking/dp/0123705487/
> 
> http://www.amazon.com/Traffic-Engineering-Optimization-Integrated-Networks/dp/0123706254/
> 
> Perhaps you could suggest an appropriate reference as well?
> 
> OTOH, I couldn't find any RFCs with numerical examples of TSPEC/TMOD implementation (do you know of any?), so that might be a justification to include one or two examples in QSPEC (such as the ones you constructed). 
> 
> Does anyone else have a comment on this?
> 
>> Shouldn't we copy the missing text from RFC 2210 or RFC 2215 since the
>> current description is incomplete without those RFCs?
> 
> I'm not sure what 'missing text' you suggest to copy. Once again, the intent of the statement at the beginning of QSPEC Section 5.2 ("The references in the following sections point to the normative procedures for processing the QSPEC parameters and sub-parameters.") is intended to avoid copying normative text into the QSPEC document for each QSPEC parameter. More generally, that is also the purpose of a normative reference in any RFC.
> 
> Do you want to suggest specific text to bring into QSPEC?
> 
> Regards,
> Jerry
       
---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile.  Try it now.

_______________________________________________
nsis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nsis