Galène videoconferencing server discussion list archives
 help / color / mirror / Atom feed
From: Juliusz Chroboczek <>
To: T H Panton <>
Cc: Dave Taht <>,
Subject: [Galene] Re: using up more ports in ipv6 for better congestion control
Date: Sun, 11 Jul 2021 13:19:47 +0200
Message-ID: <> (raw)
In-Reply-To: <>

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

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

  parent reply	other threads:[~2021-07-11 11:19 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-10 15:15 [Galene] " Dave Taht
2021-07-10 15:19 ` [Galene] " Dave Taht
2021-07-10 16:36 ` T H Panton
2021-07-10 16:48   ` Dave Taht
2021-07-11 11:19   ` Juliusz Chroboczek [this message]
2021-07-15 14:17     ` Sean DuBois
2021-07-16  1:36       ` Juliusz Chroboczek
2021-07-16 14:25         ` Sean DuBois
2021-07-15 16:26     ` T H Panton
2021-07-16  1:37       ` Juliusz Chroboczek
2021-07-16 14:46         ` T H Panton
2021-07-16 17:48           ` Juliusz Chroboczek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Galène videoconferencing server discussion list archives

This inbox may be cloned and mirrored by anyone:

	git clone --mirror

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 galene galene/ \
	public-inbox-index galene

Example config snippet for mirrors.

AGPL code for this site: git clone