Re: QSPEC & TMOD

Hi Hannes,

Hannes Tschofenig wrote:
> Section 3.3.1 Traffic Model Parameter says: 
> 
> "
>    o rate (r)
>    o bucket size (b)
>    o peak rate (p)
>    o minimum policed unit (m)
> 
>    All 4 of the sub-parameters MUST be included in the TMOD parameter.
>    The TMOD parameter can be set to describe the traffic source.  If,
>    for example, TMOD is set to specify bandwidth only, then set r = peak
>    rate = p, b = large, m = large.  As another example if TMOD is set
>    for TCP traffic, then set r = average rate, b = large, p = large.
> "
> 
> In reviews we got the comment that the term "large" is a bit fuzzy. Wouldn't
> it be better to  
> * replace the term "large" with a specific value

Probably at least an example of what would be considered as being "large".

> * add a separate bandwidth parameter
> * indicating the parameter now carries a bandwidth value rather than being
> implicit in the encoding of the parameters

Hmm, I disagree here.
The thing is that "bandwidth" alone is much too fuzzy
and that's why Dave Oran insisted to use T-MOD at some
IETF meeting in San Diego.
If you think about bandwidth of "100Mbit/s", that could
be either 100Mbit sent in 0.1s and then being idle
for 0.9s or very smoothly 1250 bytes every 100µs.
A Token Bucket is well-defined and unambiguous about
the shape of your traffic. I remember times when only every
second ATM cell got through, because the ingress policer
dropped them due to "high" burstiness generated by
the sending PC ATM interface. It should be clear which
traffic will pass your policers and also for admission control
you want to know how bursty it is. For instance, I usually
couldn't admit very bursty traffic to enter my EF-based classes,
but it may fit into AF-based classes.

Regards,
 Roland