IETF Logo Mail Archive

Re: [tcpm] draft-ietf-tcpm-hystartplusplus and QUIC

Lars Eggert <lars@eggert.org> Tue, 20 September 2022 06:03 UTC

Return-Path: <lars@eggert.org>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21F9C1522A9 for <tcpm@ietfa.amsl.com>; Mon, 19 Sep 2022 23:03:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEumVtswWEBQ for <tcpm@ietfa.amsl.com>; Mon, 19 Sep 2022 23:03:25 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B0EC14F743 for <tcpm@ietf.org>; Mon, 19 Sep 2022 23:03:25 -0700 (PDT)
Received: from smtpclient.apple (mobile-access-b04809-98.dhcp.inet.fi [176.72.9.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id BAB801DD29D; Tue, 20 Sep 2022 09:03:16 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1663653796; bh=XanTZfwyJoL1Qms0BeBNdXJID++J6wIPX4wjFwLAvq0=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=H+GbFeYBt1FmGNa9HvcAFm4IhAKEzcTzIGMQRuOmBmsIOnk8h26mLsLzixfcO+S05 uOdGE7XBTostU1c4FK9O83jbGx7jmNpSfCBIg11M8zZow/8mif0X1b1uWK6sgi/YJw akQV6Bj8c8QOfv/R0R13ptFaaLuj9iHedr8zRV+I=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
From: Lars Eggert <lars@eggert.org>
Mime-Version: 1.0 (1.0)
Date: Tue, 20 Sep 2022 09:03:15 +0300
Message-Id: <8317ED87-0689-42FD-AB0C-E5DD646B7C48@eggert.org>
References: <D364F578-5172-48A2-A8CD-BDC24CF2F983@lurchi.franken.de>
Cc: Christian Huitema <huitema@huitema.net>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>
In-Reply-To: <D364F578-5172-48A2-A8CD-BDC24CF2F983@lurchi.franken.de>
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
X-MailScanner-ID: BAB801DD29D.A8F6B
X-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/iCo6pO8kGd3TIkOBh5nka4wubzA>
Subject: Re: [tcpm] draft-ietf-tcpm-hystartplusplus and QUIC
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Sep 2022 06:03:29 -0000

On Sep 20, 2022, at 01:08, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
> 
> However, most
> of the specs use a language specific to one transport protocol but you can easily
> translate them to the other. So there is some transfer to be made by the reader.

I think that asking the reader to make that transfer is extra work and a potential source of ambiguities and errors. In the past, one could assume that everyone was deeply familiar with TCP, since that was by far the dominant protocol, but that situation is changing.

Lars

-- 
Sent from a mobile device; please excuse typos.

v2.23.0 | Report a Bug | By Email