Re: [EToSat] Interop runner with satellite links
Joerg Deutschmann <joerg.deutschmann@fau.de> Fri, 18 March 2022 16:09 UTC
Return-Path: <joerg.deutschmann@fau.de>
X-Original-To: etosat@ietfa.amsl.com
Delivered-To: etosat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99DBF3A0CD2; Fri, 18 Mar 2022 09:09:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fau.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmMraRmRIpOF; Fri, 18 Mar 2022 09:09:43 -0700 (PDT)
Received: from mx-rz-1.rrze.uni-erlangen.de (mx-rz-1.rrze.uni-erlangen.de [131.188.11.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72CD43A0925; Fri, 18 Mar 2022 09:09:41 -0700 (PDT)
Received: from mx-rz-smart.rrze.uni-erlangen.de (mx-rz-smart.rrze.uni-erlangen.de [IPv6:2001:638:a000:1025::1e]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by mx-rz-1.rrze.uni-erlangen.de (Postfix) with ESMTPS id 4KKpqh5dW7z8vMk; Fri, 18 Mar 2022 17:09:36 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fau.de; s=fau-2021; t=1647619776; bh=Acgqo+wAEu8SI6QsLCaHgr2OSp/ZwkPEqPECuInU2WA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:To:CC: Subject; b=fIDw7dmNAjkGA/9LExTHceGVTFLo4UPU7+3HEuBY6s3yoJMknxtOiRcs6ZNAwFOmR 9uf+iiWiUl6lhpQT2ikA5xX6mEkkZxJHPZxJSRa+8e4cLJymOLxzZkt/CYSsEA29d2 R+cqkZ09a2Wk3sefC3huZhlkUGJEpZL+zzvLJB6NMBwQz31mlnIbCarljoxeBOXJHW bNrQi6YszhLdNEU3UqPwVEjKk7MdRcyO6ZGZoc4UzqmsEpo4h8QIUWkmro85oRGzVj egh/s/4H9+G1GyThjABhmiKFNKyH8AWFkZlkpzxTtUYcX8swh9VKyF43OPPqdXk+BT GTq5va7LNO8DA==
X-Virus-Scanned: amavisd-new at boeck2.rrze.uni-erlangen.de (RRZE)
X-RRZE-Flag: Not-Spam
X-RRZE-Submit-IP: 131.188.37.210
Received: from faui7s0.informatik.uni-erlangen.de (faui7s0.informatik.uni-erlangen.de [131.188.37.210]) by mailhub.rrze.uni-erlangen.de (Postfix) with ESMTP id 4KKpqd68PMz8sZ3; Fri, 18 Mar 2022 17:09:33 +0100 (CET)
Received: from [192.168.178.35] (dynamic-095-115-121-151.95.115.pool.telefonica.de [95.115.121.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by faui7s0.informatik.uni-erlangen.de (Postfix) with ESMTPSA id A2B1740311D5; Fri, 18 Mar 2022 17:09:33 +0100 (CET)
Message-ID: <26bbb036-90c6-96c7-b6bd-5fc2d39f8b62@fau.de>
Date: Fri, 18 Mar 2022 17:09:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0
Content-Language: en-US
To: "Su, Chi-Jiun" <Chi-Jiun.Su@hughes.com>, Christian Huitema <huitema@huitema.net>
Cc: "quic@ietf.org" <quic@ietf.org>, Sebastian Endres <basti.endres@fau.de>, "etosat@ietf.org" <etosat@ietf.org>
References: <2572762.KRHqeOQrTU@7b74a564-70da-4baa-82f8-b74434554dd0> <2321206.ElGaqSPkdT@7b74a564-70da-4baa-82f8-b74434554dd0> <BL1PR11MB53038951CA6E71DC10A7F6E5CE3A9@BL1PR11MB5303.namprd11.prod.outlook.com> <1f27c94e-e9ca-e93e-f158-b696fc2e82a8@huitema.net> <CAL0D2oR8+5OB_0qpzHX6VwpipkEXaDYWZHvbBDMWTvU_CycTMQ@mail.gmail.com> <a7798345-c7ec-23b6-f489-cc4cbfcda4f6@huitema.net> <BL1PR11MB5303C0CEDD653D3F35E1A85FCE019@BL1PR11MB5303.namprd11.prod.outlook.com>
From: Joerg Deutschmann <joerg.deutschmann@fau.de>
In-Reply-To: <BL1PR11MB5303C0CEDD653D3F35E1A85FCE019@BL1PR11MB5303.namprd11.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/etosat/9VJnp1l-jQ7Frr6WQ0dSmYjnbyI>
Subject: Re: [EToSat] Interop runner with satellite links
X-BeenThere: etosat@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "The EToSat list is a non-WG mailing list used to discuss performance implications of running encrypted transports such as QUIC over satellite." <etosat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/etosat>, <mailto:etosat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/etosat/>
List-Post: <mailto:etosat@ietf.org>
List-Help: <mailto:etosat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/etosat>, <mailto:etosat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Mar 2022 16:09:49 -0000
Yes, that issue is now fixed. https://interop.cs7.tf.fau.de/?run=logs_paper_2022-03-15 We'll update the paper accordingly, thanks for your feedback. We'll also reference Robin Marx's "Same Standards, Different Decisions: A Study of QUIC and HTTP/3 Implementation Diversity" paper, which is obviously relevant in this context, especially regarding the influence of flow control. On 28.02.22 19:49, Su, Chi-Jiun wrote: > This problem in the test may be gone with the new fix. > "Although only a file of 10 MiB is transferred, this leads to > approximately 60 to 80 MiB of data being sent." > > thanks. > cj > > > ------------------------------------------------------------------------ > *From:* EToSat <etosat-bounces@ietf.org> on behalf of Christian Huitema > <huitema@huitema.net> > *Sent:* Sunday, February 27, 2022 12:58 AM > *To:* Nicolas Kuhn <nicolas.kuhn.ietf@gmail.com> > *Cc:* Su, Chi-Jiun <Chi-Jiun.Su=40hughes.com@dmarc.ietf.org>; > quic@ietf.org <quic@ietf.org>; Sebastian Endres <basti.endres@fau.de>; > joerg.deutschmann@fau.de <joerg.deutschmann@fau.de>; etosat@ietf.org > <etosat@ietf.org> > *Subject:* Re: [EToSat] Interop runner with satellite links > > ***EXTERNAL EMAIL*** > > > > > On 2/25/2022 10:24 PM, Nicolas Kuhn wrote: >>> On the interaction between congestion control and coding, you may be >> interested in looking at : >> https://datatracker.ietf.org/doc/html/draft-irtf-nwcrg-coding-and-congestion-12 <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-irtf-nwcrg-coding-and-congestion-12__;!!Emaut56SYw!jNkAqwXdSBCHAMUuYW8PPcglW-20gL3A6g374RkqkAJtdwP1lCyedBGvudZYRl-1xA$> >> >> There have been other interesting contributions on the integration of FEC >> in QUIC : >> -https://datatracker.ietf.org/doc/html/draft-swett-nwcrg-coding-for-quic-04 <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-swett-nwcrg-coding-for-quic-04__;!!Emaut56SYw!jNkAqwXdSBCHAMUuYW8PPcglW-20gL3A6g374RkqkAJtdwP1lCyedBGvudY_7bqPLg$> >> -https://datatracker.ietf.org/doc/draft-roca-nwcrg-rlc-fec-scheme-for-quic/ <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-roca-nwcrg-rlc-fec-scheme-for-quic/__;!!Emaut56SYw!jNkAqwXdSBCHAMUuYW8PPcglW-20gL3A6g374RkqkAJtdwP1lCyedBGvudYazujiig$> >> - >> https://inl.info.ucl.ac.be/publications/quic-fec-bringing-benefits-forward-erasure-correction-quic.html <https://urldefense.com/v3/__https://inl.info.ucl.ac.be/publications/quic-fec-bringing-benefits-forward-erasure-correction-quic.html__;!!Emaut56SYw!jNkAqwXdSBCHAMUuYW8PPcglW-20gL3A6g374RkqkAJtdwP1lCyedBGvudZKbpdRNw$> >> >> I think the proposed approach (sending FEC packets when the file >> transmission is over) had been experimented and will investigate whether >> the results can be shared. > > I will look, thanks. > > In any case, I think that the adverse effects found by Sebastian are now > fixed. There was an issue when the client did not increase the flow > control window quickly enough. If the value of MAX_DATA or > MAX_STREAM_DATA is too small, the sender becomes blocked. In the old > builds, when the sender was blocked by flow control, the code decided > that it could just as well repeat packets preemptively rather than doing > nothing. This is somewhat debatable. It generally does not speed up > transfer, because flow control does not affect loss recovery. The new > code only does preemptive repeat at the end of file transfers: fewer > transmission, probably lower energy consumption, and slightly faster > completion of the file transfer compared to the old code. > > I have uploaded a docket image with the new code in the interop runner. > I don't know whether I need to do something special for the satellite > interop runner. > > -- Christian Huitema >
- [EToSat] Interop runner with satellite links Sebastian Endres
- Re: [EToSat] Interop runner with satellite links Behcet Sarikaya
- Re: [EToSat] Interop runner with satellite links Su, Chi-Jiun
- Re: [EToSat] Interop runner with satellite links Sebastian Endres
- Re: [EToSat] Interop runner with satellite links Su, Chi-Jiun
- Re: [EToSat] Interop runner with satellite links Joerg Deutschmann
- Re: [EToSat] Interop runner with satellite links Christian Huitema
- Re: [EToSat] Interop runner with satellite links Nicolas Kuhn
- Re: [EToSat] Interop runner with satellite links Christian Huitema
- Re: [EToSat] Interop runner with satellite links Su, Chi-Jiun
- Re: [EToSat] Interop runner with satellite links Su, Chi-Jiun
- Re: [EToSat] Interop runner with satellite links Christian Huitema
- Re: [EToSat] Interop runner with satellite links Emmanuel Lochin
- Re: [EToSat] Interop runner with satellite links Su, Chi-Jiun
- Re: [EToSat] Interop runner with satellite links François Michel
- Re: [EToSat] Interop runner with satellite links Christian Huitema
- Re: [EToSat] Interop runner with satellite links Nicolas Kuhn
- Re: [EToSat] Interop runner with satellite links Joerg Deutschmann