One comment inline [HL].<div><br></div><div>/Henrik</div><div><br><br><div class="gmail_quote">On Wed, Oct 19, 2011 at 12:09 PM, Varun Singh <span dir="ltr"><<a href="mailto:vsingh.ietf@gmail.com">vsingh.ietf@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi,<br>
<br>
Comments inline.<br>
<div class="im"><br>
On Wed, Oct 19, 2011 at 01:06, Randell Jesup <<a href="mailto:randell-ietf@jesup.org">randell-ietf@jesup.org</a>> wrote:<br>
> On 10/18/2011 10:07 AM, Harald Alvestrand wrote:<br>
</div><div><div class="h5">>> MEASUREMENT SETUP<br>
>><br>
>> Imagine a system consisting of:<br>
>><br>
>> - A sender A attached to a 100 Mbit LAN, network X<br>
>> - A bandwidth constricted channel between this LAN and another LAN,<br>
>> having bandwidth BW<br>
><br>
> It may not matter here, but normally bandwidths are asymmetric; if we care<br>
> about both directions (I think we don't in this scenario), we should specify<br>
> directionality.  If we don't care, we should specify which direct we do care<br>
> about.<br>
><br>
>> - A recipient B also attached to a 100 Mbit LAN, network Y<br>
>> - A second sender A' attached to network X, also sending to B<br>
>> - Other equipment that generates traffic from X to Y over the channel<br>
><br>
> Also note that RTT between A and B is important.<br>
><br>
> If you want to simulate a more real-world situation (and I'm not 100%<br>
> certain it's needed here), you need a third network Z to simulate traffic<br>
> from A' to network nodes that aren't on network Y.  I.e. each side may<br>
> compete with traffic that uses the access link, but doesn't go across the<br>
> far-end access link.  (And, in fact, this is the primary interfering traffic<br>
> if an access link is the bottleneck.)  In the case above, other than RTT and<br>
> loss issues with feedback, it doesn't matter so long as you're only looking<br>
> at one side.<br>
><br>
> The reason it may matter is that the bottleneck link is usually at the<br>
> upstream (at least for 1-on-1 communication), and subsequent traversals<br>
> including the BW-constrained far-end downstream can affect the<br>
> buffer-fullness-sensing.<br>
><br>
> So, you need something more like:<br>
><br>
>  - A sender A attached to a 100 Mbit LAN, network X<br>
>  - A bandwidth constricted channel between this LAN and another LAN<br>
>  (network Z), having bandwidth BW<br>
>  - A recipient B also attached to a 100 Mbit LAN, network Y, which<br>
>   is attached to network Z with bandwidth BW2<br>
>  - A second sender A' attached to network X, also sending to B<br>
>  - Other equipment that generates traffic between X to Z over<br>
>   the channel<br>
>  - Other equipment that generates traffic between Y to Z over<br>
>   the channel<br>
><br>
>> All measurements are taken by starting the flows, letting the mechanisms<br>
>> adapt for 60 seconds, and then measuring bandwidth use over a 10-second<br>
>> interval.<br>
><br>
> Continuous flows are not a good model.  The "other equipment" will be a mix<br>
> of continuous flows (bittorrent, youtube (kinda)), etc and heavily bursty<br>
> flows (browsing).  We need to show it reacts well to a new TCP flow, to a<br>
> flow going away, and to a burst of flows like a browser makes.<br>
><br>
<br>
</div></div>The problem I note with bursty traffic is how do you measure fairness<br>
for these short bursty flows? short is probably (1-5s)<br>
is fairness completion time of these short flows (they shouldn't take<br>
more than 5 x times more time to complete, 5x is just a number I<br>
chose)? or fair sharing of bottleneck BW (BW/N flows)?<br>
<div class="im"><br>
> Also that it coexists with other rtcweb flows!  (which I note you include<br>
> below)<br>
><br>
>> This seems like the simplest reasonable system. We might have to specify<br>
>> the buffer sizes on the border routers to get reproducible results.<br>
><br>
</div>This is an important value. Especially, in light of the buffer bloat discussion.<br>
<div class="im"><br>
> And the buffer-handling protocols (RED, tail-drop, etc).  I assume tail-drop<br>
> is by far the most common and what we'd model?<br>
><br>
<br>
</div>In NS2 simulations with cross-traffic we've got better results by<br>
using RED routers instead of droptail ones (for TFRC, TMMBR, NADU).<br>
However, as mentioned before AQM is not that common.<br>
<div class="im"><br>
>> PROTOCOL FUNCTIONS ASSUMED AVAILABLE<br>
>><br>
>> The sender and recipient have a connection mediated via ICE, protected<br>
>> with SRTP.<br>
>> The following functions need to be available:<br>
>><br>
>> - A "timestamp" option for RTP packets as they leave the sender<br>
><br>
> Are you referring to setting the RTP timestamp with the<br>
> "close-to-on-the-wire" time?  I have issues with this...  If it's a header<br>
> extension (as mentioned elsewhere) that's better, but a significant amount<br>
> of bandwidth for some lower-bandwidth (audio-only) cases.<br>
><br>
> The RTP-tfrc draft message looks like 12 bytes per RTP packet.  If we're<br>
> running say Opus at ~11Kpbs @ 20ms, which including overhead on UDP uses<br>
> ~27Kbps (not taking into account SRTP), this would add 4800bps to the<br>
> stream, or around 18%.  Note that unlike TFRC, you need them on every<br>
> packet, not just one per RTT.<br>
><br>
<br>
</div>One optimization is to drop the 3-byte RTT field. Just using the "send<br>
timestamp (t_i)" field should be enough. Moreover, if there are other<br>
RTP header extensions then 0xBEDE (4-byte) RTP header extension is<br>
common to all of them. In which case the send timestamp adds just 5<br>
bytes {ID, LEN, 4-byte TS}.<br>
<br>
<a href="http://tools.ietf.org/html/rfc5450" target="_blank">http://tools.ietf.org/html/rfc5450</a> provides a mechanism to use<br>
relative transmission timestamps to relative RTP timestamps and uses a<br>
3-bytes instead of 4 bytes for the timestamp. I am sure if we really<br>
require such a timestamp there can be some optimizations done to save<br>
a byte or two.<br></blockquote><div><br></div><div>[HL] I think we should not make these extra timestamps mandatory. A candidate algorithm should pass the criteria using only basic RTP timestamps. However, a clever algorithm would perform better if supplied with additional timestamp information.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> Note that for a 128Kbps audio+video(30fps) call, the overhead would be<br>
> ~7680bps, or 6%, which isn't bad.  At higher rates it goes down<br>
> proportionally.  It's higher than I'd like.... but not problematically high.<br>
>  We should evaluate how much it helps in practice versus sample-time<br>
> timestamps.<br>
><br>
<br>
</div>I agree that we should evaluate if the precision is beneficial or not.<br>
<div class="im"><br>
>> - A "bandwidth budget" RTCP message, signalling the total budget for<br>
>> packets from A to B<br>
><br>
> Ok.<br>
><br>
>> REQUIRED RESULTS<br>
>><br>
>> In each measurement scenario below, the video signal must be<br>
>> reproducible, with at most 2% measured packet loss. (this is my proxy<br>
>> for "bandwidth must have adapted").<br>
>><br>
>> If A sends one video stream with max peak bandwidth < BW, and there is<br>
>> no other traffic, A will send at the maximum rate for the video stream.<br>
>> ("we must not trip ourselves up").<br>
><br>
> Note: we need to send video and audio streams, but that might not be needed<br>
> here.  But it's important in a way, in that both are adaptable but with very<br>
> different scales.  We need both streams with very different bandwidths to<br>
> adapt "reasonably" to stay in the boundary. Note that in real apps we may<br>
> give the app a way to select the relative bandwidths and override our<br>
> automatic mechanisms (i.e. rebalance within our overall limit).<br>
><br>
<br>
</div>There was some discussion at the beginning if the rate control should<br>
be per flow, or combined? was there a consensus on that already or is<br>
it something we still need to verify via simulations?<br>
<div class="im"><br>
>> If A and A' each send two video streams with MPB > 1/2 BW, the traffic<br>
>> measured will be at least 30% of BW for each video stream. ("we must<br>
>> play well with ourselves")<br>
><br>
> What's the measurement period and point, since these are likely to drift<br>
> some and may take a short time to settle down?<br>
><br>
>> If A sends a video stream with MPB > BW, and there is a TCP bulk<br>
>> transfer stream from LAN X to LAN Y, the TCP bulk transfer stream must<br>
>> get at least 30% of BW. ("be fair to TCP")<br>
>><br>
>> If A sends a video stream with MPB > BW, and there is a TCP bulk<br>
>> transfer stream from LAN X to LAN Y, the video stream must get at least<br>
>> 30% of BW. ("don't let yourself be squeezed out")<br>
><br>
> Given enough time (minutes), we *will* lose bandwidth-wise to a continuous<br>
> TCP stream (as we know).<br>
><br>
<br>
</div>If there are 1 or 2 TCP streams (doing bulk transfer), a single RTP<br>
stream can be made competitive, however as the number of streams<br>
increase RTP loses out. In Google's draft, they ignore losses upto 2%.<br>
In my own experiments, we were a bit more tolerant to inter-packet<br>
delay.<br>
<div class="im"><br>
>> Mark - this is almost completely off the top of my head. I believe that<br>
>> failing any of these things will probably mean that we will have a<br>
>> system that is hard to deploy in practice, because quality will just not<br>
>> be good enough, or the harm to others will be too great.<br>
>><br>
>> There are many ways of getting into trouble that won't be detected in<br>
>> the simple setups below, but we may want to leave those aside until<br>
>> we've shown that these "deceptively simple" cases can be made to work.<br>
>><br>
>> We might think of this as "test driven development" - first define a<br>
>> failure case we can measure, then test if we're failing in that<br>
>> particular way - if no; proceed; if yes; back to the drawing board.<br>
><br>
> Or analyze why it failed and update the test or criteria.<br>
><br>
<br>
</div>I agree with this methodology.<br>
<div class="im"><br>
> We also need to cover our internal data streams, and multiple streams from<br>
> the same client (as opposed to two separate clients as above).<br>
<br>
<br>
<br>
</div>Varun<br>
<span class="HOEnZb"><font color="#888888">--<br>
<a href="http://www.netlab.tkk.fi/~varun/" target="_blank">http://www.netlab.tkk.fi/~varun/</a><br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Rtp-congestion mailing list<br>
<a href="mailto:Rtp-congestion@alvestrand.no">Rtp-congestion@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/rtp-congestion" target="_blank">http://www.alvestrand.no/mailman/listinfo/rtp-congestion</a><br>
</div></div></blockquote></div><br></div>