RE: Measurement bit(s) or not
Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Sun, 11 February 2018 19:25 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 DC9A2126DEE for <quic@ietfa.amsl.com>; Sun, 11 Feb 2018 11:25:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 EX9OrD3n25jH for <quic@ietfa.amsl.com>; Sun, 11 Feb 2018 11:25:16 -0800 (PST)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 3FAD7126C22 for <quic@ietf.org>; Sun, 11 Feb 2018 11:25:16 -0800 (PST)
Received: by mail-it0-x22b.google.com with SMTP id n206so4155227itg.1 for <quic@ietf.org>; Sun, 11 Feb 2018 11:25:16 -0800 (PST)
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=KIq2tzTEekOiDgBQsknQXrpSce0XyYO6PoWzl/DBbAE=; b=VPZJC6K0EML58ekWKCdlfWU/x06STg5t1D94eWfed+XTSgLKpvFNDwhFUn87M3EtA3 SYqkYVjKk0B+dPURR2JstuOqLcvURZJcuF/D5fLwN85j+H6OAKZsl23LKjCTdm9dYFrM UAycw8rcef5gqkEtZMCNukmv1SgzYvtft17G5G59Y+9qhAU18F2dUlQ4o/Yq4jC5ABMk aWritrtFcMdgB07zfhfjKOS7yQFWt6seub2h5Du8aVQGcxBnmaD9i7Oz1+PwLNrfdxGY 2hcvUH1TVj8Te69Z2PuqxgZxbQcGBLRvn8l3S3sulfeGpGTNECi2ARoR5gx+MxQRqUde tcJA==
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=KIq2tzTEekOiDgBQsknQXrpSce0XyYO6PoWzl/DBbAE=; b=CCI31L4uvvRmjBnVGhug5hS6Qn6fcZHt39gVXMhqaQCSDhTeUJB/B2ucybVqODjrDV G6212WU6ziAJjPtbsHTUJtsMFRkiK//nLOYtysjU5nk+m+4gGb89PqfkOTGrexLAiDHP 364wJE57TUVZOAj7GuaSLDDjx800WCsqzELXt/+tUueMlob3viwLkLOPIS/5yforDNr1 f5Pv6BKQM/vwf0gKqJbW2EK9d9/0zWbGlZNvQ4pkWSGS8jKAf8GI7tg6yWYA1X1CjD4k 8exPYHjYv+x4udTovY9p5VAw6vFdglBbx1lR9+xojVJP+O40gzAxeBzYPayxnhchIqbm l7zw==
X-Gm-Message-State: APf1xPBm/ZA4M0fU9wEckH+qNidsyp4QKYBxPzRvhZoLBU7pekTk9x3m vs8JpW200pRV4daPqdi043VbFfdu5LNHOy+97ydXhw==
X-Google-Smtp-Source: AH8x225n6rMS0aZVEM5xAbApf4POZPdQ63PxXbz05g4S2nEa21AnoFJtZHJFmBgePws/OCGWb+wh5ucBlMSf4PZLyns=
X-Received: by 10.36.10.207 with SMTP id 198mr2721440itw.42.1518377115642; Sun, 11 Feb 2018 11:25:15 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 11 Feb 2018 11:25:14 -0800
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <CAN1APddOWZRF6FxiEcJ4MbOpMwxqHm9=LbMB92pVkdUJNMuMyQ@mail.gmail.com>
References: <1817_1518284090_5A7F2D3A_1817_79_1_5A7F2D3E.4050806@orange.com> <aa7a56d01f0a41fe9ad0fd9e61c54c50@usma1ex-dag1mb5.msg.corp.akamai.com> <CAN1APddOWZRF6FxiEcJ4MbOpMwxqHm9=LbMB92pVkdUJNMuMyQ@mail.gmail.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Sun, 11 Feb 2018 11:25:14 -0800
Message-ID: <CAN1APdcTH=oHdf=wixJZXOCCXcaYKR1ZkJQLDpndRdehuKfvBA@mail.gmail.com>
Subject: RE: Measurement bit(s) or not
To: "Lubashev, Igor" <ilubashe@akamai.com>, "alexandre.ferrieux@orange.com" <alexandre.ferrieux@orange.com>, "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/alternative; boundary="001a1144b8289ceec60564f4b813"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/w4erEKKRDtUP8lbL65h3h52Jzak>
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: Sun, 11 Feb 2018 19:25:19 -0000
Actually, since the half-period is 16*2048 so loss can be detected up to 32K packets, or typically 32MB worth of data. At the same time loss can be detected within the first 16 bytes by trivially comparing the first 8 bits with the next 8 bits. If these are not the same, something is off. But it is perfect because all bits could be zero. To improve on this, each transmitted bit could be spread over two packets, 0, 1 for sending a reset bit, and 1, 0 for sending a set bit. If we then drop repeating the 8 bit pattern, the shortest half-period remains at 16 packets since an 8-bit Gray code requires 16 packets. Now we can detect a single loss or swap already after two packets, although this is probably not interesting since reordering could happen already in multiple send queues. On 11 February 2018 at 20.06.14, Mikkel Fahnøe Jørgensen (mikkelfj@gmail.com) wrote: I already wrote this elsewhere, but the mail topic was a bit off, and I think it might actually be a good alternative to the other approaches balancing the simplicity of the square without the problem of having to wait for the square half period to detect loss. It is a fractal pattern in the form of grey code. For example an 8 bit code that is transmitted one bit a time. Each bit represents a wave length and changes at half the wave length. To simplify synchronisation, the same 8 bit pattern could be transmitted twice before a bit changes. This would support half-periods of 16, 32, …, 2048 packets. In addition, there is a lot of error correcting coding theory around this with noise analysis and maximum likelihood decoders. https://en.wikipedia.org/wiki/Gray_code https://en.wikipedia.org/wiki/Constellation_diagram The encoding is simple as per Wikipedia: /* * This function converts an unsigned binary * number to reflected binary Gray code. * * The operator >> is shift right. The operator ^ is exclusive or. */unsigned int binaryToGray(unsigned int num){ return num ^ (num >> 1);} /* * This function converts a reflected binary * Gray code number to a binary number. * Each Gray code bit is exclusive-ored with all * more significant bits. */unsigned int grayToBinary(unsigned int num){ unsigned int mask = num; while (mask != 0) { mask = mask >> 1; num = num ^ mask; } return num;} /* * A more efficient version, for Gray codes of 32 or fewer bits. */unsigned int grayToBinary32(unsigned int num){ num = num ^ (num >> 16); num = num ^ (num >> 8); num = num ^ (num >> 4); num = num ^ (num >> 2); num = num ^ (num >> 1); return num;} On 10 February 2018 at 22.41.51, Lubashev, Igor (ilubashe@akamai.com) wrote: I am a bit sceptical about the square. With TCP, packet trace shows loss of any packet, except for SYN. The "square wave" whould show no loss at all for short connections (fewer than a "wavelength" of packets). Moreover, the square wave can only detect loss after up to the wave length of subsequent packets has been transmitted. If there is an application pause in transmission, loss may not become evident. Basically, a spin bit or a bit pattern (like a square wave) may help in troubleshooting, but it will be more uncertain and hokey than what people come to expect of tcp. We have be very clear in acknowledging it. -----Original Message----- *From:* alexandre.ferrieux@orange.com [alexandre.ferrieux@orange.com] *Received:* Saturday, 10 Feb 2018, 12:34PM *To:* quic@ietf.org [quic@ietf.org] *Subject:* Measurement bit(s) or not On 07/02/2018 14:34, Brian Trammell (IETF) wrote: > hi Jana, > >> 3. Some sequencing information -- a few bits of the packet number perhaps >> -- should be revealed (for monitoring. Number of bits TBD.) > > This is the crux of the argument. On one side we have the risk of misuse and > ossification (well, not ossification -- these bits are *meant* for the path > -- rather the risk that we'll figure out later that we specified the wrong > thing), on the other side we have the loss of visibility into how QUIC > traffic interacts with the network as compared to TCP, with a side question > of whether or not this visibility is really the transport layer's problem > despite the evolution the practice of diagnostics and troubleshooting using > TCP information. > > If we can come to agreement on this question, everything else falls into > place. I have my arguments here, but as you said, this subthread is not the > place for them. :) The crux indeed. So what about settling it first ? With the troubleshooting hat, I can only stress the need for measurement bits, for the benefit of everybody, since s**t happens, networks are imperfect, and nifty encapsulations-with-seqnum will simply not be where you need them. Now to the exact nature of these measurement bits: Thanks to the detailed exchanges on this thread, it is by now clear that a simple gapless counter, even nonzero-based and XORed, is not acceptable. The 4-bit SSN comes pretty close but is not enough when things go really wrong (and they will - and that's where we need the tool). Then Kazuho's square signal and Mikkel's Pi (or any other consensual self-synchronizing sequence) ramification came up. They are both appealing for their elegance and low complexity on QUIC endpoints. Beyond their quirks acknowledged here, here are a few considerations for troubleshooting: (1) Since reordering is less of a concern to QUIC than to TCP, it becomes a secondary goal. This is nice, because the square doesn't see it, and the self-synchronizing sequence will only tolerate a mild one, and never see its detail like cycle length etc. (2) There's of course a huge difference between them in complexity for the midpoint: square is trivial, Pi is hefty. Given these, a benevolent, troubleshooting-minded passive midpoint will clearly vote for the square. Now the obvious question is: is this acceptable, or deemed too easy for a Murphy, Inc. active middlebox to see upstream losses and benevolently wreak havoc by delaying packets ? _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
- Measurement bit(s) or not alexandre.ferrieux
- Re: Measurement bit(s) or not Gorry (erg)
- RE: Measurement bit(s) or not Lubashev, Igor
- RE: Measurement bit(s) or not Mikkel Fahnøe Jørgensen
- RE: Measurement bit(s) or not Mikkel Fahnøe Jørgensen
- Re: Measurement bit(s) or not Brian Trammell (IETF)
- Re: Measurement bit(s) or not Mikkel Fahnøe Jørgensen
- Re: Measurement bit(s) or not alexandre.ferrieux
- Re: Measurement bit(s) or not Brian Trammell (IETF)
- Re: Measurement bit(s) or not Gorry (erg)