From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1DC783B29E for ; Sat, 10 Jul 2021 12:49:03 -0400 (EDT) Received: by mail-io1-xd30.google.com with SMTP id h190so16586095iof.12 for ; Sat, 10 Jul 2021 09:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=aphCagBJ9e7LvGQ5U5r2bOlyyZiHHo51u+2oZnOHphk=; b=X9WIpwmb2/Sf2W9doALyPaZ05hNqTF1Qjl4ileR8c2im9ubPVXBpQw7LNUANCUIFJR iuXTgkdUYu+qaFaGvqPGJ55joPn2RCabKxUTaEYTZIkWOtXhxFKmHZf4xMFmlOdIDu/9 Wdimmw3K8GcX26Ml+Rfr+NoJ+IzxIKbIwRp1NZ2X60dyvDJbKaQs3vm48nLzHbCz8K8s ljYjLfZ+Jf5LVQZQwPXPv8vlRB2cKxJ8k7XwYVItkhN4w8O32to4eVTPYum+KuQqCA5i nPWHui7Y5WEab6ODH4R3+dg9ZcY4G600jNDDKPPCYteiXBUIHSAXtp2NTegbyOs7CyZy sspg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=aphCagBJ9e7LvGQ5U5r2bOlyyZiHHo51u+2oZnOHphk=; b=W8KCPt0u65Ke0ZPjGWyYIIAXLZ7fU9tEK5gAhpRnU3vElrhUS0g569Um8YONlD6zuR Fa9rl+AzoOTf/aBvV7yysriWHdF6gcxg3bbdKkSEZFtX21rSMoU3ZDzsfttDGr4/tnxD Q9pJgrGCvdL1Bi7RUk/7wsV0EijHKqdZ6LaJADhsOtsUbAnl1yZpDR0v/ClIOZWB5ttd fUdQeqY0r7uWT29zMWHeKJfLepdcG38IOWruYrvC8LDobhJkNk9sNz62AU6Jd9wnEpxq 9ZbxqSK8dvJErzmpgYYpXZBHVFFuBqhneAQTdcvRafnJ0Sa59XwzIiz9GES9emOKtQuU JAwA== X-Gm-Message-State: AOAM532z6Tw0IDk9Dgk+xmosSyzxWoZKanuD9jPp9cVHuFwYREz+vwLX jtZvBMMQbOEM/9a7zWXQ7lbj0HvpPo8/t8DyP02B8/yR2VM= X-Google-Smtp-Source: ABdhPJw7CPyR9tcMc1+36AxdiPcPhibweyLHGabbg3rWYw/xoefhsHhgzY3C8pOhXnCZa+keHvV6so5oPS68/PUbAm0= X-Received: by 2002:a02:cad9:: with SMTP id f25mr13549194jap.97.1625935742426; Sat, 10 Jul 2021 09:49:02 -0700 (PDT) MIME-Version: 1.0 References: <35ECF0D3-B549-4C43-868F-58021E7F2BDD@pi.pe> In-Reply-To: <35ECF0D3-B549-4C43-868F-58021E7F2BDD@pi.pe> From: Dave Taht Date: Sat, 10 Jul 2021 09:48:50 -0700 Message-ID: To: T H Panton Cc: galene@lists.galene.org, Cake List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] using up more ports in ipv6 for better congestion control X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jul 2021 16:49:03 -0000 On Sat, Jul 10, 2021 at 9:36 AM T H Panton wrote: > > > > > On 10 Jul 2021, at 17:15, Dave Taht wrote: > > > > tim panton wrote me just now on linked in: > > > > "It is still possible. Just set bundle-policy to max-compat and you'll > > get one stream for audio and one for video. Turn off rtcp-mux and > > you'll get 4 ports (voice, video, voice-RTCP, video-RTCP) - But your > > ability to connect will drop significantly (according to Google's > > data) and your connection setup time will increase. Even with port > > muxing congestion control is still possible, it just works > > _differently_ - which arguably it should, because realtime video has > > quite different needs from streaming or file transfer. Happy to have a > > chat about this...." > > > > (so... chatting via email is preferred for me) > > > > 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? > > Oh, no, the congestion control is _very_ much alive in webRTC but under g= uise of > bandwidth estimation - The =E2=80=98simplest' is google=E2=80=99s REMB RT= CP message which basically > looks at the arrival time of packets and uses any _lengthening_ in the to= f to deduce the onset of > additional buffering in the path. Transport CC tries to expand this to ap= ply to all the streams muxed over a port > by adding an RTP header extension with an accurate (NTP) clock in it. thank you very much for this update. We can do MUCH better than ntp these days, gps being so common. > > The thing that drives design this is that losing a packet is catastrophic= for realtime video, > one dropped packet makes seconds (aka megabytes) worth of data un-rendera= ble. at least in my fq_codeled world, rfc3168 ecn is alive and well. It's just that marking and responding to ecn in the go library we are using (pion) is deeply buried. also SCE might finally take flight after the next ietf. It's easy to see fq_codel for the wifi chipsets we use overagressively attempt to drop packets for non-paced videoconferencing streams. (I never said fq_codel was perfect) I demoed that to juliusz a while back. Totally fixed if you mark at least the keyframes as ecn-capable. Even more fixable if sch_cake with its diffserv4 support is on the bottleneck path. > At 50 fps the frame interval is shorter than the roundtrip time on the pa= th (for VDSL users anyway - perhaps not fiber) > so a NAK/resend will fix it too late. In terms of the jamaphone across town I care mostly that the audio streams are perfect. Can lose a frame on the video here or there. But I groke we have issues here. Ideally I'd like to be running at 250 fps (4ms) which is like being 4 feet away from someone else in the band. > > So the strategy is to dynamically estimate the capacity of the path and t= ry to surf _just_ under that, ensuring minimal packet loss. I generally find enforcing the observed minimum via cake from a starlink, 5g or wifi link and staying there is best for videoconferencing apps, and it turns out low latency is often best for web and other forms of applications. Only if you are addicted to speedtest results do you need to care about bandwidth. > > I realise this is anathema to TCP folks, it certainly came as a shock to= me=E2=80=A6. to *most* tcp folks. Not all. RTTs are what a I hope an icreasingly high percentage will be caring about. > T. > > > > > My other fantasy is to somehow start using udplite for more things. > > > > The context for this of course is my never ending quest to have an IP > > based video and audio streaming system good enough to have a band > > playing with each other across town. > > > > > > -- > > Latest Podcast: > > https://www.linkedin.com/feed/update/urn:li:activity:679101428493678592= 0/ > > > > Dave T=C3=A4ht CTO, TekLibre, LLC > --=20 Latest Podcast: https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/ Dave T=C3=A4ht CTO, TekLibre, LLC