[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