Re: Spin bit - semantics - rtt and loss

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Fri, 23 March 2018 07:50 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 C390C129C56 for <quic@ietfa.amsl.com>; Fri, 23 Mar 2018 00:50:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.697
X-Spam-Level:
X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 RNW4tQH6VtQ0 for <quic@ietfa.amsl.com>; Fri, 23 Mar 2018 00:50:32 -0700 (PDT)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 E8D981289B0 for <quic@ietf.org>; Fri, 23 Mar 2018 00:50:31 -0700 (PDT)
Received: by mail-it0-x22e.google.com with SMTP id z143-v6so4426310itc.0 for <quic@ietf.org>; Fri, 23 Mar 2018 00:50:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=TCu/huYwDdFdNwlVL/OiThR//6MHKaV5Hc+/DxMOFto=; b=FNg0IeD3Thy3peMWZtXHbaEY5p094EFuKjIfOeSSq+YBQZqzDshm6fVh+zE7Z27kp9 4OOVsWYnZTcjmEkMV+JsHSl+6WKO+u4ktNLxymvvSvBkeHLcLki0vfykl/6DQi3gavEG XdmI3JeGtN+PAH45cW+exgf2y9Za+UcPllu0CT7YkKfTa4CMqRO6frrkOQCKGD5XTbBp 9xF/5MSc7WP5NhAeVgtX2jMi4LWkARwQP3d52Oresnzl+z1eYj1dyVcnCr6yJwNWbMO6 I88I6badWxc6IfWvRrhXzig6lhodSG2r6iErAzjigf4oCL0jf9I3pyar1kmTeL0lLslg O2JQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=TCu/huYwDdFdNwlVL/OiThR//6MHKaV5Hc+/DxMOFto=; b=l8LRIU5msSVHMed1XacMYTop6Y47QUUiehoUdimsfnPzRr6CIMC68UxJzTojoN5zoU IdKBzihbfh1k+cB6wo6ql/JsYGluwSKgHoHKM8gZlR0RjAk0CTzv6347bwdsAEcMb3+1 MlDmAHgM5Rl0RR0vKGDmdenr0ZwdUCq46GR4vx3Z7uQmr/Fp8MkwhLvpwFSLqDTrt214 ufTHNQOelBAyU0Ef0ZXCfb3dq9qxeGDUFngvko5BX6wX3GfRPR5yrg/9QJVGb99dGDzg DffiKa3D0jie+Fq49jfMFDUpjKODHaG6D8PjQv3QqhCwhJRUaHAeOysnwZ6Y7qJHojmc Idmw==
X-Gm-Message-State: AElRT7EZGDiX8PW/kG6Ddpilh1TFmDZjDEv0xpxysXAkdaIOI1YHq6Yy Gn54XfT1DWoUMATaGI3301imdrHJ1SRnjrz+MuVkkA==
X-Google-Smtp-Source: AG47ELveKxnE3DA16P1i8m32vOk2e+jo/NExGOA8t8UqsFGJGPb5ACoS2yN7uApwOSjUeVLujVJrf6IK7syN5bY8B4w=
X-Received: by 2002:a24:9dce:: with SMTP id f197-v6mr12158962itd.39.1521791431274; Fri, 23 Mar 2018 00:50:31 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 23 Mar 2018 00:50:30 -0700
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <CAN1APdfQG0FOgUGJzqZAbEsefA51jv9mGUj=KQY6OyhvC_M=bg@mail.gmail.com>
References: <9168a7b6700d49d6b7454f8c91eebce2@ustx2ex-dag1mb5.msg.corp.akamai.com> <CAN1APdfQG0FOgUGJzqZAbEsefA51jv9mGUj=KQY6OyhvC_M=bg@mail.gmail.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Fri, 23 Mar 2018 00:50:30 -0700
Message-ID: <CAN1APdeg1YyGU=KYcQi4fBRpkjUPCeMuR5EZUjJueLUFhspvBw@mail.gmail.com>
Subject: Re: Spin bit - semantics - rtt and loss
To: "Lubashev, Igor" <ilubashe=40akamai.com@dmarc.ietf.org>, "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000aef40405680fadaf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/3-baTikVIqp280cBb-XwQX1gzhw>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 23 Mar 2018 07:50:34 -0000

It should be noted that a Gray counter would not count linearly, but have
one bit changing for every power of 2 larger amount of data sent (details
may vary).

The spin bit could also be encoded by some phase of the pattern, for
example sending the same 8 bit count twice, but with one of the counts
inverted when spin is set. But that makes things more difficult to
implement and looses some precision when very few packets are sent.

Kind Regards,
Mikkel Fahnøe Jørgensen


On 23 March 2018 at 08.42.28, Mikkel Fahnøe Jørgensen (mikkelfj@gmail.com)
wrote:

Just to summarize the square wave discussion:

It is possible to send many other patterns one bit at a time that deal with
both short and long range loss.
At some point I suggested emitting a 8 bit Gray code counter which is
emitted one bit at a time. Optionally repeated twice before changing in
order to better sync the signal. This repeats every 8 packets or every 16
packets.

It was designed for loss detection - not spin or RTT because that isn’t
encoded into signal. But it can be used to sync the instance of a separate
spin bit. This would use two bits.

Kind Regards,
Mikkel Fahnøe Jørgensen


On 23 March 2018 at 01.13.01, Lubashev, Igor (
ilubashe=40akamai.com@dmarc.ietf.org) wrote:

Since we decided to put some work into spin bit, albeit in a separate
document from V1, here are some thoughts.

It is nice that spin bit can be used to estimate rtt. I am sure that it is
useful to many well-meaning people. It is not very useful to me, though.

When I debug network problems, they are much more likely to be about lost
packets. And I like to be able to know packet loss frequency and pattern
very accurately. (I am assuming an encrypted packet number, or the problem
would be trivial.)

I would prefer, if we have a spin bit, for it to spin not every rtt but
every, say, 10 packets that an endpoint sends. Client sends 10 packets with
0 and then 10 packets with 1, repeat. Sever does the same.

So maybe two spin bits -- one for rtt and one for loss? I would assume that
loss bit would assist in rtt estimation in case of loss.

Thoughts?

- Igor