[R-C] Strawman: Requirements

Harald Alvestrand harald at alvestrand.no
Tue Oct 18 16:07:46 CEST 2011


I think that in order to get off ground zero here, both in 
implementation, testing and navigating the tortuous path towards 
standards-track adoption, we should throw out some requirements.

And in the spirit of rushing in where angels fear to tread, I'm going to 
throw out some.

MEASUREMENT SETUP

Imagine a system consisting of:

- A sender A attached to a 100 Mbit LAN, network X
- A bandwidth constricted channel between this LAN and another LAN, 
having bandwidth BW
- A recipient B also attached to a 100 Mbit LAN, network Y
- A second sender A' attached to network X, also sending to B
- Other equipment that generates traffic from X to Y over the channel

All measurements are taken by starting the flows, letting the mechanisms 
adapt for 60 seconds, and then measuring bandwidth use over a 10-second 
interval.

This seems like the simplest reasonable system. We might have to specify 
the buffer sizes on the border routers to get reproducible results.

PROTOCOL FUNCTIONS ASSUMED AVAILABLE

The sender and recipient have a connection mediated via ICE, protected 
with SRTP.
The following functions need to be available:

- A "timestamp" option for RTP packets as they leave the sender
- A "bandwidth budget" RTCP message, signalling the total budget for 
packets from A to B


REQUIRED RESULTS

In each measurement scenario below, the video signal must be 
reproducible, with at most 2% measured packet loss. (this is my proxy 
for "bandwidth must have adapted").

If A sends one video stream with max peak bandwidth < BW, and there is 
no other traffic, A will send at the maximum rate for the video stream. 
("we must not trip ourselves up").

If A and A' each send two video streams with MPB > 1/2 BW, the traffic 
measured will be at least 30% of BW for each video stream. ("we must 
play well with ourselves")

If A sends a video stream with MPB > BW, and there is a TCP bulk 
transfer stream from LAN X to LAN Y, the TCP bulk transfer stream must 
get at least 30% of BW. ("be fair to TCP")

If A sends a video stream with MPB > BW, and there is a TCP bulk 
transfer stream from LAN X to LAN Y, the video stream must get at least 
30% of BW. ("don't let yourself be squeezed out")

Mark - this is almost completely off the top of my head. I believe that 
failing any of these things will probably mean that we will have a 
system that is hard to deploy in practice, because quality will just not 
be good enough, or the harm to others will be too great.

There are many ways of getting into trouble that won't be detected in 
the simple setups below, but we may want to leave those aside until 
we've shown that these "deceptively simple" cases can be made to work.

We might think of this as "test driven development" - first define a 
failure case we can measure, then test if we're failing in that 
particular way - if no; proceed; if yes; back to the drawing board.

What do you think?

                          Harald


More information about the Rtp-congestion mailing list