Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt)

[Magnus Westerlund <[e-mail]>]

Hi,

As an Individual I do have a few comments and question on this document
and its algorithm.

1. Section 3: As delay based congestion control has been tried a number
of times and meet with less than stellar success I wonder if you have
any understanding of how this relates to the issues previously encountered:

- Stability (especially on short RTTs)
- How it competes with TCP flows, which was a real issues for TCP Vegas
but may be less of an issue here.

2. Section 3, I don't see any discussion of the startup issue. Is my
assumption correct, that you will simply start at some rate and then
adapt from that?

3. Section 3, I guess this mechanism would get significant issues with
any sender side transmission filtering. Burst transmitting I-frames over
a network, especially for high resolution video can easily result in
packet loss in switch fabrics if there is any cross traffic in the
switch fabric. Thus having a bit of send filtering for frame
transmission is a good idea. Are I understanding it correctly that this
could result in over-use indication if I has such mechanism which
filters a packet to a slower transmission rate than what a single or
small burst can achieve over the same path?

4. Section 4.

"This algorithm is run every time a receive report arrives at the
   sender, which will happen [[how often do we expect? and why?]].  If
   no receive report is recieved within [[what timeout?]], the algorithm
   will take action as if all packets in the interval have been lost.
   [[does that make sense?]]"

The transmission of receiver reports is highly dependent on RTP profile,
the RTCP bandwidth, trr-int parameter and any feedback events.

If I start with assuming AVPF which seems reasonable in most browser to
browser case with our current proposals for RTP support. Then if there
are no feedback events the transmission of receiver reports will occur
as often as the bandwidth allows, but no more often than the value of
trr-int parameter.

Here is might be worth mentioning that I do expect trr-int to be set to
avoid RTCP reporting to often due to the relatively high RTCP bandwidth
values that will be set due to the multiplexing of audio and video in a
single RTP session. Thus avoiding that RTCP rates are as high or larger
than the audio streams they report in steady state.

When feedback events occur the stack will have the choice of sending a
RTCP RR, that is a choice provided due to the reduced size RTCP
specification included. But if the loss cumulative count diff is
non-zero it might be worth mandating that the RR/SR is included in any
such feedback RTCP packet.

For that reason causing a feedback event when there is losses and
schedule them using the early algorithm may be a good choice to ensure
timely reporting of any loss.

If one uses AVP then the RTCP timing rules will give you when you
transmit RTCP feeedback and thus the parameterization becomes central
here. A clear issue is if people uses the minimal interval of 5 seconds
or the 360/Session_BW(in kbps). I would note that 5 seconds is very long
in adaptation situations.

I think the timeout should be based on the RTT and possible reporting
rate. But there clearly need to be some upper limit, either explicitly
or mandating RTCP bandwidth rates.

5. Section 4:
"We motivate the packet loss thresholds by noting that if we have
   small amount of packet losses due to over-use, that amount will soon
   increase if we don't adjust our bit rate.  Therefore we will soon
   enough reach above the 10 % threshold and adjust As(i).  However if
   the packet loss rate does not increase, the losses are probably not
   related to self-induced channel over-use and therefore we should not
   react on them."

I am personally worried that a packet loss threshold of 10% is so high
that it might push a lot of other traffic out of the way. Thus being
quite aggressive towards other flows.

TCP has this relation between the average packet loss rate and the
highest sustainable rate which can be interpreted as TCP gets more
sensitive to loss the higher the average data rate becomes. Thus in
certain situation the sender side algorithm part will be extremely
aggressive in pushing TCP out of the way. The receiver part may
compensate for this pretty well in a number of situations.

But, I do wonder why for example the A(i) isn't bounded to be between
TFRC's rate and some multiple of TFRC rate, not unbounded by other than
the receiver side algorithm.

I do understand this document is to start a discussion. But I think we
need to be sensitive to that it is difficult to get even something that
is self-fair over the wide range of conditions the Internet has to provide.

Thus I would appreciate what issues with for example TFRC that you
attempt to fix with the various new components you add.


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------