From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 260A13B2A4 for ; Mon, 18 Sep 2023 15:48:10 -0400 (EDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 38IJm9DE010846; Mon, 18 Sep 2023 21:48:09 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id B46FE70F4F; Mon, 18 Sep 2023 21:48:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=irif.fr; h= content-type:content-type:mime-version:user-agent:references :in-reply-to:subject:subject:from:from:message-id:date:date :received:received; s=dkim-irif; t=1695066487; x=1695930488; bh= NMX32OykBjpHYQYcdl9EWs6YM5aBTtxTslM5OkSmYS0=; b=L8X71UipaxTKjNdI GLGu7xFvuyFCq70+TrGUIGpt1eeoFvA6X6FFUH2Q8sB2EcycqaeiFmnO7Zf8vNhW gGxHAw9whRjUJADGr5SPI9CQZcyOrkvFtJlVRWoHLs7HyiAxFuh7i6n/ey9dy37v tr4pZ07hn1fvsCjeb3XXDe3/791TsynHV2WCDrkGiXyc6lVy7+tyd1lHgYFmf6sL Xjwt2xfOC8xCgSmt9mOHLRzyjVoXLlcjqLS3RjKWCPRKRy3NpJHcsijTm6PNozfl NfBJ174mxMnAycjNGmHm2bZ4mgWcnaE7opVljWa6ttDS4X4QzQMZVp4tsJjL2HGO 7Zosag== X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 5pqU1JOrB53k; Mon, 18 Sep 2023 21:48:07 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 921967103C; Mon, 18 Sep 2023 21:48:06 +0200 (CEST) Date: Mon, 18 Sep 2023 21:48:06 +0200 Message-ID: <87bkdzqn49.wl-jch@irif.fr> From: Juliusz Chroboczek To: Michael Richardson Cc: Dave Taht via Starlink In-Reply-To: <8658.1695062436@localhost> References: <87msxjqwhj.wl-jch@irif.fr> <8658.1695062436@localhost> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/29.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Mon, 18 Sep 2023 21:48:09 +0200 (CEST) X-Miltered: at korolev with ID 6508A979.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 6508A979.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 6508A979.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Subject: Re: [Starlink] impressed with my starlink today X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2023 19:48:10 -0000 > If I understand correctly, galene would support p2p media streams? No, Galene only does client-server media. Before I wrote Galene, I experimented with peer-to-peer WebRTC, and it worked beautifully in small groups, but collapsed somewhere around 4 to 5 participants. The problem is not the amount of data (Galene uses at most 700kbit per flow in the default configuration), but the fact that current WebRTC implementations require you to encode the video separately for each peer. > It seems to me that if you have multiple outgoing streams, that if there are > problems with any of them, a sender-driven system allows for better use of > what is typically a smaller uplink. In the sender-driven approach, the receiver gives very detailed feedback to the sender (lost packets, packet arrival timestamps), who runs the congestion control algorithm. In the receiver-driven approach, the receiver runs the congestion control algorithm, and sends a single integer to the sender, the maximum allowed rate. There's nothing that prevents the sender from reducing the rate below what the receiver requested even in the receiver-driven algorithm. Does one of the approaches give more flexibility to the sender? I'm frankly not convinced, but perhaps I'll change my mind once I've implemented it. -- Juliusz