[R-C] Strawman: Requirements

[Varun Singh]

Hi,

comments inline.

On Wed, Oct 19, 2011 at 21:13, Randell Jesup <randell-ietf at jesup.org> wrote:
> On 10/19/2011 7:02 AM, Harald Alvestrand wrote:
>>>>>
>>>>> What about delay? should it be variable or fixed one-way delay
>>>>> (end-to-end delay)?
>>>>>
>>> Any comments on end-to-end delay: fixed 50ms? 100ms? variable 20-70ms?
>>> i.e a few ms on 100 Mbit links and 10s of ms on the bottleneck link (BW).
>
>> I'd think that tests at 5 ms and 100 ms delay on the "narrow" link
>> should give us reasonable scenarios - one simulates adjacent houses, the
>> other one simulates the other side of a continent.
>
> I think we need to simulate at least a subset of these, and I'd love for all
> of them:
>
> LAN+WiFi - wifi is the constriction, no other significant delay
>

Since the Wifi does link level retransmissions, it can only add delay
due to retransmissions.

> "local" broadband access - asymmetric access link, short additional delay
> (5-20ms)
>
> "long-distance" - asymmetric access link, longer delay (25-75ms)
>
> "intercontinental" - asymmetric access link, much longer delay (75-150ms).
>
> "satellite" - asymmetric access link, 300-600ms delay(?)
>

This can be parameterized. But are these just a function of delay,
shouldn't they be a tuple of (BW, RTT, Loss Rate)?

> Comments?  The WiFi case is important.  I'm also interested in wireless
> broadband cases (3G/4G).
>
I have one reference to RLC traces for 3G. There are also packet loss
traces available for 0.5%, 1.0% and 1.5% packet loss.  In our setup
the RLC is set to unacknowledged mode, so packets lost on the air
interface are not retransmitted.

3GPP R1-081955, “LTE Link Level Throughput Data for SA4 Evaluation
Framework.” 3rd
Generation Parnership Proejct (3GPP), Proposal R1-081955, May 2008.
[Online]. Available:
http://www.3gpp.net/ftp/tsg ran/WG1 RL1/TSGR1 53/Docs/R1-081955.zip

>>> The reason I asked, was because the direction of the message is noted
>>> as "from A to B" and TMMBR should flow "from B to A" and I wasn't sure
>>> if it was TMMBR or was the sender telling the receiver what it was
>>> using as the current bit rate. However, REMB clarifies it.
>>
>> Yup.
>> Branching into design for a moment: With sender-side bandwidth
>> estimation, I am worried about packet rates; since RTCP packets don't
>> piggyback on return traffic like TCP ACK does, having a sender-side
>> computation based on RTCP (such as the basic TCPFR) requires that you
>> send RTCP packets very frequently - could be up to one RTCP for every
>> RTP packet in short-RTT scenarios.
>
> Right, a definite worry of mine with sending "raw" data back; you can
> however send "partially cooked" data back when certain events occur and
> suppress "nothing interesting, move along" reports.
>
>> Computing bandwidth at the receiver and sending the computed rate to the
>> sender allows you to react quickly to changes AND keep a low RTCP
>> frequency when you don't have a congestion problem. This of course
>> requires that you have a sender-side algorithm that reacts appropriately
>> when congestion becomes so bad that most of the RTCP packets get
>> lost..... always tradeoffs!
>
> Yes.
>
>>> is this a moving average of 10s or 10s intervals? because I am not
>>> sure why 10s instead of per second?
>
>> I was thinking in terms of measuring the number of bytes delivered from
>> second #60 to second #70 in the (simulation / test), and calling that
>> "the measured value".
>> If we get significantly different numbers in second #70 to #80, that's
>> worthy of investigation.
>>
>> My reason for picking 10s is that I've done tests where it turned out
>> that I was measuring effectively 4 events in the interval, and with a
>> requirement that > 80% succeeded, a single packet loss was enough to
>> break the test; if we measure over single seconds for a pass/fail
>> criterion, I think a test will be a bit too sensitive to random
>> combinations of events (double packet losses, for instance) for the kind
>> of timescales we're talking about - there are only ~50 packets in the
>> typical second for voice, and might be even fewer for scaled-down video
>> (congestion-caused reduced-rate video may go down to 5 fps in some
>> products). But it's another pragmatic number.
>
> Yes, we can iterate on the test design as needed; we just need to remember
> these aren't carved in stone, they're tools to get at the useful aspects of
> behavior.
>
>
> --
> Randell Jesup
> randell-ietf at jesup.org
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
>



-- 
http://www.netlab.tkk.fi/~varun/