[Galene] Re: using up more ports in ipv6 for better congestion control

[Juliusz Chroboczek <jch@irif.fr>]

Tim is right about everything, as usual.

Tim said:

>> "It is still possible. Just set bundle-policy to max-compat and you'll
>> get one stream for audio and one for video.

This mode of operation is not currently supported by Pion.

Tim also said:

> Oh, no, the congestion control is _very_ much alive in webRTC but under
> guise of bandwidth estimation - The ‘simplest' is google’s REMB RTCP
> message which basically looks at the arrival time of packets and uses
> any _lengthening_ in the tof to deduce the onset of additional buffering
> in the path.

Yes.  Galène implements both REMB and loss-based congestion control in the
sender->SFU direction, and just loss-based in the SFU->receiver direction.
Implementing REMB is on my to-do list, but I've got more important things
to do.

Dave said:

>> I am also under the impression that the congestion control
>> notifications in rtcp are essentially obsolete in the rfc, mandating a
>> 500ms interval instead of something sane, like a frame?

You're speaking about the loss-based congestion controller, which is used
in combination with the delay-based controller that Tim is referring to.
The 500ms interval is the default, but nothing prevents the receiver from
sending more frequent feedback, for example just after a loss episode.
(Galène doesn't currently do that.)

Tim said:

> Transport CC tries to expand this to apply to all the streams muxed over
> a port by adding an RTP header extension with an accurate (NTP) clock in
> it.

I still don't understand why Transport-wide CC (TWCC) is better than REMB.
In my view, it's just moving the REMB congestion controller from the
receiver to the sender, which requires huge amounts of timely per-packet
feedback.

Tim, I'd be very grateful if you could explain what advantages TWCC has
over REMB.  For now, I'm sticking with REMB.

> I realise this is anathema to TCP folks, it certainly came as a shock to me

It depends on your background, I guess.  It was fairly natural for me, but
then I've been brought up on the litterature on ECN on the one hand and
TCP-Vegas on the other, both of which aim to perform congestion control
without any packet drops.

Ceterum autem censeo that Dave is right, and that we should be working on
ECN support in WebRTC.

-- Juliusz