Subject: [NSIS] QSPEC TMOD and packet header overhead

From: Roland Bless <[email-masked]>
Date: Wed, 09 Apr 2008 10:29:12 +0200

Hi,

probably a dumb question, but Max Laier and I could not find any
guidance on this in the qspec draft:
I guess that the TMOD-1 r parameter in draft-ietf-nsis-qspec-20
specifies the number of bytes/s for IP packets, including any
IP headers. Now consider a mobile node that adds extra overhead
to its data packets due to the mobility headers etc. This could be
significant for VoIP packets. So in this case the applications has
to increase r depending on the packet rate and m must be increased,
too?

As another example: if the application communicates via IPv4
it has to specify for a normal PCM codec VoIP traffic:
r=50*(20+8+12+160)=10,000 bytes/s
  [packet every 20ms,IP+UDP+RTP+payload], m=200 bytes,
  b= 2000 bytes, p=very high (allowing a burst of 10 packets)
and when communication via IPv6
r=50*(40+8+12+160)=11,000 bytes/s, m=220 bytes,
b= 2200 bytes

Is this correct? Would it make sense to provide a little
guidance on this and an example in the QSPEC?

Regards,
 Roland
_______________________________________________
nsis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nsis

---

From: Gerald Ash <[email-masked]>
Date: Fri, 11 Apr 2008 13:43:21 -0700 (PDT)

Hi Roland,
   
  I think your examples are fine (although overhead for PPP header and perhaps MPLS labels might also be included).  
   
  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.
   
  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.
   
  Jerry

Roland Bless <[email-masked]> wrote:
  Hi,

Regards,
Roland

 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: Max Laier <[email-masked]>
Date: Sat, 12 Apr 2008 04:32:39 +0200

On Friday 11 April 2008 22:43:21 Gerald Ash wrote:
> Hi Roland,
>
>   I think your examples are fine (although overhead for PPP header and
> perhaps MPLS labels might also be included).
>
>   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.
>
>   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.

I found a paragraph in the tunnel draft at the end of 6.3.1:

|   If the end-to-end session SHOULD be bound to a tunnel session yet to
|   be created, Tentry assigns the tunnel flow ID, and constructs a
|   tunnel RESERVE' or QUERY' message, depending on whether the tunnel
|   signaling is sender initiated or receiver initiated.  The QSPEC in
|   this tunnel message MAY be different from the original QSPEC, taking
|   into consideration the tunnel overhead of the encapsulation of data
|   packets.  Tentry then associates the tunnel session with the end-to-
|   end session in the NSLP state and sends the tunnel message toward
|   Texit to start reserving resources over the tunnel.  At the same
|   time, Tentry appends a tunnel BOUND_SESSION_ID object to the end-to-
|   end RESERVE message and sends it through the tunnel interface.

Maybe we should expand that with a bit more detail and in the mobility 
draft as well?  I'm really having trouble as to how a middle box can 
calculate the new bandwidth from a per-packet overhead.

-- 
/"\  Best regards,                      | [email-masked]
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
_______________________________________________
nsis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nsis

---

From: Roland Bless <[email-masked]>
Date: Wed, 16 Apr 2008 17:32:03 +0200

Hi Jerry,

> perhaps MPLS labels might also be included). 

No I disagree here. This doesn't make sense as link level overhead
may change while the packets traverses the net (e.g. PPP header is
stripped of at the next hop) and the application is usually unaware
of any link level technology being used. The RMF is probably aware of
any link layer overhead and resources. RFC 2210 also says about [m]:
   This
   packet size includes the application data and all protocol headers at
   or above the IP level (IP, TCP, UDP, RTP, etc.). The size given does
   not include any link-level headers, because these headers will change
   as the packet crosses different portions of the internetwork.

> 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.

> 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.
Shouldn't we copy the missing text from RFC 2210 or RFC 2215 since the
current description is incomplete without those RFCs?

Regards,
 Roland

---

From: Gerald Ash <[email-masked]>
Date: Fri, 18 Apr 2008 12:58:24 -0700 (PDT)

Hi Roland,
   
  See comments below.
   
>> 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.
 
> 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.

> 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?
  
> 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.

---

From: Bernd Schloer <[email-masked]>
Date: Tue, 22 Apr 2008 18:17:34 +0200

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:
> ------------------------------------------------------------------------
>

---

From: Gerald Ash <[email-masked]>
Date: Tue, 22 Apr 2008 10:36:32 -0700 (PDT)

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-masked]> wrote:
  Hi Jerry,

Best regards,
Bernd

Protocol Header Size