[e2e] Re: Control traffic: how many % of payload traffic?

[James M. Polk]

Michael

Does it take that much more control traffic for a Video Stream than a Voice
Stream? If you model the restriction based on a ratio that is fixed regardless
of Media type, I think you'll guarantee wasted bandwidth. 

Another example, does an MPEG4 media flow require more control traffic/packets
than an MPEG2 flow? And are the proportional?

The flows I consider to be latency sensitive all the time, yet control is based
much more on a reliable receipt model, for efficient forwarding, but not
real-time, is necessary.

All I advocating is the ratio will (likely) be non-linear as the media flow
increases in bandwidth per flow.

At 12:18 PM 5/25/2001 +0200, Michael Welzl wrote:
>Hi all,
>
>To achieve scalability, it seems reasonable to restrict the amount of
>control traffic which is related to a payload traffic stream by a fraction
>of the payload traffic: this way, the overall control traffic remains a
>fraction of the related payload traffic no matter how many senders there
>are.
>
>For Internet traffic, it may also make sense to restrict control traffic by
>the amount of packets, so not only traffic forwarding but also per-packet
>header processing is taken into account. So a rule should probably be:
>
>control traffic = min (x % of payload traffic, every yth payload packet)
>
>The values x and y must be predefined (if a single sender exceeds a certain
>x or y, the concept won't work).
>
>My question is: how do I come up with appropriate values for x and y?
>The answer is probably a trade off between wasted bandwidth and processing
>cost vs. gain from control traffic; but these things are very hard to
>quantify.
>For instance, how did the AVT working group come up with the value of 5% for
>RTCP traffic?
>
>>From RFC1889:
>   The control traffic should be limited to a small and known fraction
>   of the session bandwidth: small so that the primary function of the
>   transport protocol to carry data is not impaired; known so that the
>   control traffic can be included in the bandwidth specification given
>   to a resource reservation protocol, and so that each participant can
>   independently calculate its share. It is suggested that the fraction
>   of the session bandwidth allocated to RTCP be fixed at 5%. While the
>   value of this and other constants in the interval calculation is not
>   critical, all participants in the session must use the same values so
>   the same interval will be calculated. Therefore, these constants
>   should be fixed for a particular profile.
>
>My interpretation of "all participants in the session must use the same
>values" is that RTCP will scale "within a session". But why 5%? Why not 10?
>or 15? or 1?
>This question may not be as critical for RTCP as it is for control traffic
>which needs extra processing by routers.
>
>Cheers,
>Michael
>
>

*************************************
"People generally demand more respect for their own rights than they are
willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
18581 N. Dallas Parkway
Dallas, Texas 75287
w) 972.813.5208
f)  972.813.5280
www.cisco.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/end2end-interest/attachments/20010525/1a39aa47/attachment.html