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

[Michael Welzl]

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