IETF Logo Mail Archive

Re: Robert Wilton's Discuss on draft-ietf-quic-transport-33: (with DISCUSS and COMMENT)

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Thu, 07 January 2021 17:06 UTC

Return-Path: <mikkelfj@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE0B3A1027; Thu, 7 Jan 2021 09:06:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 r1bQGBFwFNwH; Thu, 7 Jan 2021 09:06:31 -0800 (PST)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 D4D883A0FC3; Thu, 7 Jan 2021 09:06:30 -0800 (PST)
Received: by mail-lf1-x12b.google.com with SMTP id a12so16241607lfl.6; Thu, 07 Jan 2021 09:06:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=schGxvsKalxHlB9eJ7tOPStBN1fzFXD30/xSTBduk/c=; b=ivfc58urp+Qz/qtc3mvUnWy2aeq7Ho3S2dQRWEITunr623W/3COEOFIS2UqPG0ZUgv FeRmice8fM6e7BboYxiVvIlTP+ozGsMT0UqoZfGh5VcRL8QN9Sb1VAUvnH8elAss0NqF +6TpQrrvv99N7mZjT/MwxepJOgEUE0pTwHERzwIsAD2gx7SSLQ5MMHdUtioFtmFaE3QG t9dxHFwpTdGhQC9l2/AMbqBLQ+vdpF9y0v4hBYYH2lI7vWxu6znRLD9bPbPTv3W9sjM8 Y5IIgIhmDwyG4oB/gCiqmyLq3KZZBpPq+757jWSbxE3fkIjZfnKjIbxhXhd9iY5MsjOD uaLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=schGxvsKalxHlB9eJ7tOPStBN1fzFXD30/xSTBduk/c=; b=RV0uXZVvzdtJ5B/J/vw0wu964t0QbNPZA1QEdrbLXs6DVDoSTe27U6kI8AB7Gn6GAT lHdOAEgHsE3TLDUZ051Wn9WYobUBVcmMBOpDhmnF9FBaIT+d5II56u+Ix2maZZNFCvOF m1EqYVI+zN1EDt9BXE+D7gRnxRmLkqsYYZ44Zk/FjiqGpNi/3XJzYPll9NNS5kMD6lx2 EYmha5231Zj8hA3zPUSVSvzYoEe0wH4xob8HyqHtbl45+pDzjCYZsFRBV/eADk3TKMZi sCINpHvVGZg7+sofYts5D2OclI0NGneuVCMmGpjKBvLLmGBSZVgAKlmv6xNrVXAWfpu0 hnaA==
X-Gm-Message-State: AOAM533O0bg+Ia5/4SeQMH3MyCQxOEhTIJYIPu7Eai4FVACtX+LwvVsy TtGTt8xsYkzxKY2UyTe1P81udM02APMIkloC
X-Google-Smtp-Source: ABdhPJzQOFBuGvVx0JFgutX/2auRWXShH1cUOV+gc1VI+wWsBQ2vuJfxfazFBna93njIlgwIMTjBsg==
X-Received: by 2002:a05:6512:31c5:: with SMTP id j5mr4165422lfe.474.1610039189222; Thu, 07 Jan 2021 09:06:29 -0800 (PST)
Received: from [192.168.8.100] (109.58.155.143.mobile.3.dk. [109.58.155.143]) by smtp.gmail.com with ESMTPSA id i19sm1289105lfj.212.2021.01.07.09.06.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jan 2021 09:06:28 -0800 (PST)
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
Message-Id: <A7ED4F42-BF57-4372-890B-C10D78E88E9C@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C6159068-6618-4FC9-875E-2943879FE633"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Subject: Re: Robert Wilton's Discuss on draft-ietf-quic-transport-33: (with DISCUSS and COMMENT)
Date: Thu, 07 Jan 2021 18:06:26 +0100
In-Reply-To: <75936877-0a6f-47ee-ab8e-6735e74c4882@www.fastmail.com>
Cc: "Rob Wilton (rwilton)" <rwilton@cisco.com>, The IESG <iesg@ietf.org>, Lars Eggert <lars@eggert.org>, quic@ietf.org, draft-ietf-quic-transport@ietf.org, WG Chairs <quic-chairs@ietf.org>
To: Martin Thomson <mt@lowentropy.net>
References: <160995499362.18437.16175887825588198380@ietfa.amsl.com> <75936877-0a6f-47ee-ab8e-6735e74c4882@www.fastmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/KZyL8PH0zJzWCqHm02NirtHiwRc>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jan 2021 17:06:33 -0000

Spinning only works if both endpoints participate. One endpoint must reflect the  bit and the other must flip it every round trip.

> On 7 Jan 2021, at 06.03, Martin Thomson <mt@lowentropy.net> wrote:
> 
>> 1) I find it hard to understand why a server is allowed to independently decide
>> whether or not to support the spin bit on a connection?  Shouldn't the client
>> (or administrator of the client system) that opened the connection be able to
>> choose whether they want the RTT to be monitorable via the spin bit?  What is
>> the reasoning for allowing the server (or server administrator) to be able to
>> independently be able to decide what is best for the client?
> 
> The consensus of the working group is that active spinning must be made independently by either endpoint and that having an endpoint dictate the actions of its peer for this feature was not desirable.  Hence the design as documented.

v2.23.0 | Report a Bug | By Email