Re: QSPEC TMOD and packet header overhead

Roland Bless <[email protected]>
Newsgroups gmane.ietf.nsis
Organization Institute of Telematics, University of Karlsruhe
Message-ID <[email protected]>
Hi Jerry,

Gerald Ash wrote:
> I think your examples are fine (although overhead for PPP header and
> 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.

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

> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.