From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass (mailfrom) smtp.mailfrom=siobud.com (client-ip=165.227.221.230; helo=mail.siobud.com; envelope-from=sean@siobud.com; receiver=) Authentication-Results: mail.toke.dk; dkim=pass (1024-bit key) header.d=siobud.com header.i=@siobud.com header.b=EDzP5Coh Received: from mail.siobud.com (mail.siobud.com [165.227.221.230]) by mail.toke.dk (Postfix) with ESMTPS id 34AA58643DB for ; Fri, 16 Jul 2021 16:25:52 +0200 (CEST) Date: Fri, 16 Jul 2021 10:25:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=siobud.com; s=mail; t=1626445545; bh=0YBYh7BOuhGHIKsWwZcuE4lE6JNkHSScQNahrL5YVe0=; h=From:To:Cc:Subject:References:In-Reply-To; b=EDzP5CohQqEGxj+GMmY31j1bwuJBuxotIkhSBwynoxND66VO9Jks3B1qSIoPBqZL4 1eRKESXOd+t27gF5FWVaB3pDEMoxvENRvi8dyZw67GOUgSAX8MKqerncSRcqoqX4ns 3eqDcGch4M5h3Hm1wJdHyNDpWGu5JldYBjbtnZbQ= From: Sean DuBois To: Juliusz Chroboczek Message-ID: <20210716142544.brppkny2kzprgic5@Seans-MBP.columbus.rr.com> References: <35ECF0D3-B549-4C43-868F-58021E7F2BDD@pi.pe> <87k0lxw10s.wl-jch@irif.fr> <20210715141738.kks3tffttx2x2dde@Seans-MBP.columbus.rr.com> <87a6mnavkw.wl-jch@irif.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87a6mnavkw.wl-jch@irif.fr> Message-ID-Hash: N6BLZ4BCLQKTPTDQO3RC6DQIB2XW7AZ7 X-Message-ID-Hash: N6BLZ4BCLQKTPTDQO3RC6DQIB2XW7AZ7 X-MailFrom: sean@siobud.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: T H Panton , Dave Taht , galene@lists.galene.org X-Mailman-Version: 3.3.4 Precedence: list Subject: [Galene] Re: using up more ports in ipv6 for better congestion control List-Id: =?utf-8?q?Gal=C3=A8ne_videoconferencing_server_discussion_list?= Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Fri, Jul 16, 2021 at 03:36:31AM +0200, Juliusz Chroboczek wrote: > >> Tim, I'd be very grateful if you could explain what advantages TWCC has > >> over REMB. For now, I'm sticking with REMB. > > > 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 understand that TWCC is more chatty, and sends more detailed information > to the sender. What I don't understand is why this information is useful: > REMB performs the exact same computation as TWCC, but it does it on the > receiver side, and only sends the result to the sender, thus avoiding the > chattiness but yielding the exact same result. > > What am I missing? What exactly does TWCC buy you? > > -- Juliusz Receiver Side BWE can't know the size+send time of lost packets. I am not aware of any other reasons though. In the GCC [0] paper it looked like calculations were designed to happen on both ends. Maybe it was more maintainable to have all the logic in one peer? [0] https://www.aitrans.online/static/paper/Gcc-analysis.pdf