Re: QSPEC TMOD and packet header overhead

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

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.

>   Jerry
>
>
> Roland Bless <[email protected]> wrote:
>   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 protected]
> https://www.ietf.org/mailman/listinfo/nsis
>
>
>  __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com



-- 
/"\  Best regards,                      | [email protected]
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News