<html><div>Michael</div>
<br>
<div>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. </div>
<br>
<div>Another example, does an MPEG4 media flow require more control
traffic/packets than an MPEG2 flow? And are the proportional?</div>
<br>
<div>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.</div>
<br>
<div>All I advocating is the ratio will (likely) be non-linear as the
media flow increases in bandwidth per flow.</div>
<br>
<div>At 12:18 PM 5/25/2001 +0200, Michael Welzl wrote:</div>
<div>>Hi all,</div>
<div>></div>
<div>>To achieve scalability, it seems reasonable to restrict the
amount of</div>
<div>>control traffic which is related to a payload traffic stream by
a fraction</div>
<div>>of the payload traffic: this way, the overall control traffic
remains a</div>
<div>>fraction of the related payload traffic no matter how many
senders there</div>
<div>>are.</div>
<div>></div>
<div>>For Internet traffic, it may also make sense to restrict control
traffic by</div>
<div>>the amount of packets, so not only traffic forwarding but also
per-packet</div>
<div>>header processing is taken into account. So a rule should
probably be:</div>
<div>></div>
<div>>control traffic = min (x % of payload traffic, every yth payload
packet)</div>
<div>></div>
<div>>The values x and y must be predefined (if a single sender
exceeds a certain</div>
<div>>x or y, the concept won't work).</div>
<div>></div>
<div>>My question is: how do I come up with appropriate values for x
and y?</div>
<div>>The answer is probably a trade off between wasted bandwidth and
processing</div>
<div>>cost vs. gain from control traffic; but these things are very
hard to</div>
<div>>quantify.</div>
<div>>For instance, how did the AVT working group come up with the
value of 5% for</div>
<div>>RTCP traffic?</div>
<div>></div>
<div>>>From RFC1889:</div>
<div>> The control traffic should be limited to a small
and known fraction</div>
<div>> of the session bandwidth: small so that the primary
function of the</div>
<div>> transport protocol to carry data is not impaired;
known so that the</div>
<div>> control traffic can be included in the bandwidth
specification given</div>
<div>> to a resource reservation protocol, and so that
each participant can</div>
<div>> independently calculate its share. It is suggested
that the fraction</div>
<div>> of the session bandwidth allocated to RTCP be fixed
at 5%. While the</div>
<div>> value of this and other constants in the interval
calculation is not</div>
<div>> critical, all participants in the session must use
the same values so</div>
<div>> the same interval will be calculated. Therefore,
these constants</div>
<div>> should be fixed for a particular profile.</div>
<div>></div>
<div>>My interpretation of "all participants in the session must
use the same</div>
<div>>values" is that RTCP will scale "within a
session". But why 5%? Why not 10?</div>
<div>>or 15? or 1?</div>
<div>>This question may not be as critical for RTCP as it is for
control traffic</div>
<div>>which needs extra processing by routers.</div>
<div>></div>
<div>>Cheers,</div>
<div>>Michael</div>
<div>></div>
<div>></div>
<br>
<div align="center">
*************************************<br>
"People generally demand more respect for their own rights than they
are willing to allow for others"<br>
<br>
</div>
James M. Polk<br>
Consulting Engineer<br>
Office of the CTO<br>
<br>
Cisco Systems<br>
18581 N. Dallas Parkway<br>
Dallas, Texas 75287<br>
w) 972.813.5208<br>
f) 972.813.5280<br>
<a href="http://www.cisco.com/" eudora="autourl">www.cisco.com</a></html>