From: Sean DuBois <sean@siobud.com> To: Juliusz Chroboczek <jch@irif.fr> Cc: T H Panton <tim@pi.pe>, Dave Taht <dave.taht@gmail.com>, galene@lists.galene.org Subject: [Galene] Re: using up more ports in ipv6 for better congestion control Date: Thu, 15 Jul 2021 10:17:38 -0400 [thread overview] Message-ID: <20210715141738.kks3tffttx2x2dde@Seans-MBP.columbus.rr.com> (raw) In-Reply-To: <87k0lxw10s.wl-jch@irif.fr> On Sun, Jul 11, 2021 at 01:19:47PM +0200, Juliusz Chroboczek wrote: > 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. > TWCC gives you the interarrival time of packets. You also get this with abs-send-time and do REMB. I would be interested to know the math of data costs of abs-send-time vs TWCC (reference time + deltas) With TWCC the sender knows the metadata of lost packets. If you lose a packet with REMB you don't know the send time or the size of the packet. That seems like it could be useful information? > > 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. Getting things into Chromium has been hard for me. If ECN gets acceptance that would be amazing. My mindset is that TWCC is most effort/least reward. Pion just got a Network Conditioner so I am hoping to put a basic TWCC driven congestion controller in pion/transport. A few papers were published on Google Congestion Control. The code [0] is nicely split up though (Delay, Loss based BWE all have their own classes) > > -- Juliusz [0] https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/modules/congestion_controller/goog_cc/
next prev parent reply other threads:[~2021-07-15 14:17 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 2021-07-15 14:17 ` Sean DuBois [this message] 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://lists.galene.org/postorius/lists/galene.lists.galene.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210715141738.kks3tffttx2x2dde@Seans-MBP.columbus.rr.com \ --to=sean@siobud.com \ --cc=dave.taht@gmail.com \ --cc=galene@lists.galene.org \ --cc=jch@irif.fr \ --cc=tim@pi.pe \ --subject='[Galene] Re: using up more ports in ipv6 for better congestion control' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox