[R-C] About the all-SCTP way of doing it

[Michael Welzl]

Folks,

I apologize if I haven't been clear enough. I know all that, and I  
have read that paper too. But: I am not at all advocating the use of  
standard TCP or SCTP *congestion control*. So what I am considering  
here is a changed SCTP, with a different (new) congestion control  
mechanism, to make use of SCTP for its stream concept, ACKs, partial  
reliability and whatnot. Perhaps most importantly, to use its ability  
to have a unified view of the streams - a common piece of code that  
makes it easier to manipulate fairness between streams (e.g. in case  
that only one type of congestion control is used (see my upcoming  
separate email about that)), as that just becomes a scheduling  
function... already existing in SCTP!  and to have a unified view of  
ACKs, making it possible to let ACKs from stream 1 benefit stream 2.

Note: I added one extra comment in line below, in Magnus' email.

Cheers,
Michael


On Apr 4, 2012, at 11:11 AM, Varun Singh wrote:

> To emphasize what Magnus said, there is a paper titled: "The
> delay-friendliness of TCP" which describes the operating region in
> which TCP may be used for VoIP (it uses RTT, loss rate, timeliness as
> metrics).
>
> http://dl.acm.org/citation.cfm?id=1375464
>
> On Wed, Apr 4, 2012 at 11:10, Magnus Westerlund
> <magnus.westerlund at ericsson.com> wrote:
>> Michael,
>>
>> Clearly the SCTP ACK do provide the sender with information. It is
>> clearly possible to use ACK based schemes. However, I think there are
>> other factors that makes SCTP as currently defined unsuitable.
>>
>> My main question to you regarding running RTP over SCTP would be  
>> how you
>> would tackle what I perceive as one of the main issues when running
>> real-time interactive media over congestion control mechanisms like  
>> TCP
>> and TFRC. Namely the clocking of the packets. To maintain timely and
>> minimal delay the media sender will need to be able to clock out the
>> packets for each audio or video frame following the sampling  
>> intervals
>> basically. The issue with TFRC and TCP is that they dictate when the
>> packet is to be sent. Every time the CC algorithm doesn't grant
>> immediately the right to transmission you do introduce end-to-end  
>> jitter
>> already at pre-sending stage.
>>
>> This is connected to the issue that once you have encoded the content
>> into some format and bit-rate it represents significant work to go  
>> back
>> and change that. Thus any control signal to reduce the transmission  
>> rate
>> that arrive later than the time of starting encoding is to late to
>> consider in this frame. You need to send that out and adjust in the  
>> next
>> video or audio frame the amount of data produced.

I very much agree, and would see this as another point in favor of  
very careful receiver-side limiting of ACKs, maybe favoring sender- 
side control too  (I now think that the main argument pro or con  
receiver-side control would really have to be multicast... if we want  
to support MANY receivers (do we? I don't know enough about RTCWeb  
here), receiver-side control might be the better way; but that doesn't  
change my argument about using SCTP).


>>
>> You get a similar issue with how to deal with video streams that  
>> can be
>> extremely bursty due to both application needs of I-frames and simply
>> content properties (large movements or zoom etc). To stay within  
>> delay
>> budget and not introduce significant playout jitter you can't really
>> smooth the burst longer than approximately one video frame interval,
>> something on the range of  16.67 (60 fps) - 100 (10 fps) ms. A video
>> stream that is being transmitted over TCP or for that matter SCTP  
>> that
>> has this behavior will in most situation blow a tight end-to-end  
>> delay
>> budget. And when I say end to end I mean from video capture until  
>> video
>> display. Using TCP or SCTP works fine for less time critical task,
>> streaming clearly works fine, but there using a buffer of at least 2
>> seconds allows for more than sufficient smoothing of the variations  
>> both
>> in the CC algorithm and in the encoded content.
>>
>> From my perspective the toughest issues with congestion control for  
>> RTP
>> are the following:
>>
>> 1) Tight and very low end-to-end delay requirements making  
>> introduction
>> of additional delay by the congestion control very questionable. For
>> really excellent quality the delay e2e must be below 200 ms, ok  
>> quality
>> is achievable over e2e delays up to 400-500 ms. Beyond that you  
>> aren't
>> really considering it being interactive.
>>
>> 2) Extremely bursty media sources, like video that can have more  
>> than a
>> factor 10 in frame by frame variations in amount of data to  
>> transmit if
>> you are to maintain the same video quality between frames.
>>
>> 3) An extremely nasty flow startup issue. For video the first frame  
>> is
>> the most heavy. At the same time it is critical to get through. And  
>> in
>> most cases you have no information about what introducing that  
>> amount of
>> data into the network will do. In addition due to intra-prediction if
>> one looses part of this image you will have significant quality
>> reduction in many video frames following the first one.
>>
>> Just trying to make clear what the problem is.
>>
>> Cheers
>>
>> Magnus
>>
>>
>> On 2012-04-04 00:12, Michael Welzl wrote:
>>>
>>> On Apr 3, 2012, at 10:16 AM, Stefan Holmer wrote:
>>>
>>>> Hi Michael,
>>>>
>>>> Some comments inline.
>>>>
>>>> /Stefan
>>>>
>>>> On Sun, Apr 1, 2012 at 11:17 AM, Michael Welzl <michawe at ifi.uio.no>
>>>> wrote:
>>>> Hi all,
>>>>
>>>> I've been giving this some more thought, and now think that it is a
>>>> mistake to try to build a RTP-UDP-based congestion control  
>>>> mechanism
>>>> with logic at the receiver, to plan when to send feedback and
>>>> minimize it accordingly. The reason is that you want to sample the
>>>> path often enough anyway, and that you may have SCTP operating on
>>>> the data stream in parallel too. So that can give you a situation
>>>> where you get a lot of ACKs all the time in SCTP, which will be
>>>> ignored by the UDP-based algorithm, which is meanwhile struggling  
>>>> to
>>>> reduce its own feedback. All this feedback is really only about the
>>>> congestion status on the path anyway, i.e. SCTP ACKs give you all
>>>> the information you need.
>>>>
>>>> I see the channel sampling frequency as one of the upsides with
>>>> receive-side estimation, since you get a sample of the channel with
>>>> every incoming packet without the need of the extra overhead of ACK
>>>> packets. In addition, algorithms at the receive-side aren't limited
>>>> to what we choose to feed back to the sender in the same way as a
>>>> send-side algorithm. For instance at the receive-side we know
>>>> exactly how late each packet is, if it is lost, if there's ECN,  
>>>> etc.
>>>> We can make use of all of that, and all we have to feed back is our
>>>> estimate of the available bandwidth.
>>>
>>> Okay, I understand that view; however, the sender is where the  
>>> action
>>> happens, and so it's the sender that should have that (ideally,  
>>> all of
>>> that) information. The less you feed back to the sender, the more
>>> prone you are to effects from dropped feedback messages  
>>> (congestion on
>>> the back-path, or e.g. wireless noise). Besides, doing that stuff on
>>> the receiver side lets you ignore the fact that you may have just  
>>> the
>>> right amount of ACKs with just the right type of information about
>>> your path in SCTP too, and possibly send back MORE feedback than  
>>> you'd
>>> need to. So if that would be receiver-side logic within SCTP, taking
>>> care of controlling the amount of feedback to send, what would be  
>>> the
>>> best way to do it? Not via some RTCP limiting rule (which doesn't
>>> really apply to underlying transports anyway, I think, i.e. you can
>>> send RTP over TCP and then it only applies to RTCP messages but not
>>> TCP ACKs, right?), but via a mechanism that is designed to send as
>>> little feedback as possible by sending just as much as is needed.  
>>> For
>>> TCP, RFC 5690 described that. For some new congestion control
>>> mechanism, we'd want to have a similar scheme I suppose. If at all
>>> needed...
>>>
>>>
>>>> So my proposal would be:
>>>>
>>>> - use SCTP for everything
>>>> - add per-stream congestion control to it, all on the sender side
>>>> - use some other RTCWeb based signalling to negotiate the  
>>>> congestion
>>>> control mechanism, in the style of DCCP
>>>> - let all streams benefit from SCTP's ACKs; if we anyhow need to
>>>> reduce the amount of feedback, we could use an appropriate means
>>>> that's related to transport, and not the RTCP rule which has  
>>>> nothing
>>>> to do with congestion control: ACK-CC, RFC 5690 would give a good
>>>> basis for that.  (on a side note, when you run RTP over SCTP, you
>>>> don't break any RTP rules regarding the amount of feedback I  
>>>> think...)
>>>>
>>>> This way, with all the congestion control logic happening on the
>>>> sender side, it would be much easier to manage the joint congestion
>>>> control behavior across streams - to control fairness among them,  
>>>> as
>>>> desired by this group. Note that this can yield MUCH more benefits
>>>> than meets the eye: e.g., if an ongoing transfer is already in
>>>> Congestion Avoidance, a newly starting transfer across the same
>>>> bottleneck (which you'll have to - correctly or not - assume for
>>>> RTCWeb anyway) can skip Slow Start. In a prototypical example
>>>> documented in:
>>>>
>>>> Not sure why it is easier to control the fairness among streams  
>>>> just
>>>> because all the estimation happens at the send-side? In the  
>>>> receive-
>>>> side approach a number for the total amount of available bandwidth
>>>> between client A and client B with will be sent from from B to A.  
>>>> It
>>>> is then up to client A to distribute that bandwidth among its
>>>> streams. A newly starting transfer across the same bottleneck  
>>>> should
>>>> share the same bandwidth, so as in your example it should be
>>>> possible to skip slow start. Or maybe I'm missing your point?
>>>
>>> In that exact algorithm that you have specified, what you say is
>>> probably correct, and it probably wouldn't matter. But then we'd  
>>> have
>>> to be careful with making any changes to that algorithm... to make
>>> sure that no policies whatsoever are incorporated in the receiver- 
>>> side
>>> logic, or else the sender would have to signal the priorities to the
>>> receiver... that's just a bit messy.
>>>
>>> ... *in a unicast setting*. Multicast may be a valid point in  
>>> favor of
>>> your design... do you plan for multicasting?
>>>
>>> Cheers,
>>> Michael
>>>
>>> _______________________________________________
>>> Rtp-congestion mailing list
>>> Rtp-congestion at alvestrand.no
>>> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
>>>
>>
>>
>> --
>>
>> Magnus Westerlund
>>
>> ----------------------------------------------------------------------
>> Multimedia Technologies, Ericsson Research EAB/TVM
>> ----------------------------------------------------------------------
>> Ericsson AB                | Phone  +46 10 7148287
>> Färögatan 6                | Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund at ericsson.com
>> ----------------------------------------------------------------------
>>
>> _______________________________________________
>> Rtp-congestion mailing list
>> Rtp-congestion at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
>
>
>
> -- 
> http://www.netlab.tkk.fi/~varun/