Re: Idea for packet numbers
Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 20 July 2017 11:17 UTC
Return-Path: <magnus.westerlund@ericsson.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 19E5C12EAF0 for <quic@ietfa.amsl.com>; Thu, 20 Jul 2017 04:17:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 hnw5nsK7qD9t for <quic@ietfa.amsl.com>; Thu, 20 Jul 2017 04:17:50 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 03AB7131687 for <quic@ietf.org>; Thu, 20 Jul 2017 04:17:44 -0700 (PDT)
X-AuditID: c1b4fb2d-86fff70000005f66-85-59709157150e
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 81.4D.24422.75190795; Thu, 20 Jul 2017 13:17:43 +0200 (CEST)
Received: from [100.94.61.212] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.21) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 20 Jul 2017 13:17:42 +0200
Subject: Re: Idea for packet numbers
To: Martin Thomson <martin.thomson@gmail.com>
CC: IETF QUIC WG <quic@ietf.org>
References: <c7941a67-6eaa-cd58-d0e2-a764478aa5b0@ericsson.com> <CABkgnnWY7EVNeZUPqkRUmO6=5=3MdWqdHaCLbW8G_iBHUQmDew@mail.gmail.com>
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <b579753b-53cf-2907-f21d-5e7e89a08f93@ericsson.com>
Date: Thu, 20 Jul 2017 13:17:41 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CABkgnnWY7EVNeZUPqkRUmO6=5=3MdWqdHaCLbW8G_iBHUQmDew@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms000204080808040605060906"
X-Originating-IP: [153.88.183.153]
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZGbFdVDd8YkGkwenHwhbXzvxjtOhZwO3A 5LFz1l12jyVLfjIFMEVx2aSk5mSWpRbp2yVwZfR/3sJUsDqs4uzBf8wNjId8uxg5OSQETCT6 NkxjAbGFBI4wSrSdz+hi5AKyNzFKnHt/iR0kISygIjFl7hkmEFtEQFdi0dkHQHEODmYBBYm7 78QgetsYJaZvKwKx2QQsJG7+aGQDsXkF7CU+fbrJCmKzCKhKrF+xCGyXqECMxLWZd1ghagQl Ts58AhbnFAiUePh4GjvIDcwC3YwSyz5MYIdYoC3R0NTBCnG0ksT1eddZJjAKzELSPwtZD0iC WcBMYt7mh8wQtrbEsoWvoWxxiaYvK1khbGuJGb8OskHYihJTuh9C9ZpKvD76kRHCNpJ4t6eR fQEj5ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwDg5uOW37g7G1a8dDzEKcDAq8fCq9RdE CrEmlhVX5h5iVAGa82jD6guMUix5+XmpSiK8ln1Aad6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwO +y5ECAmkJ5akZqemFqQWwWSZODilGhglovsrE7T7tmTqmsdcEzz4V8Ap64QZ59TuKJGP+VaK J7L+F25+/y3uK991W6NPOV/WXl+Yr/hW4OTCpCwBi9+q2kI3DrAXiJ64UzT7doU1x0b57eKJ gbd2HXuzOTZB4mZKSGxEqK/ghJvtFWXZke8n3PCc17vS+unaCK7opG8K8+fOmb/ieoISS3FG oqEWc1FxIgDP/gDamwIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/556aPWajHiJ5L60hlkbxjbZPC9c>
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: Thu, 20 Jul 2017 11:17:55 -0000
Hi Martin, Den 2017-07-20 kl. 12:38, skrev Martin Thomson: > Are you talking about the use of the NEW_CONNECTION_ID message, > because what you propose would be possible, but it would cause an > improvement to linkability. This is in reference to any changes to the public header information. The current draft version do have the packet number as part of the public header. I understand we will continue the discussion on what is public, and I think there has been suggestions all over the place. Thus, I want add this as a possibility assuming that the consensus is that we will have any parts of the packet number in the non-encrypted part of the packet. I personally do think there are reasons for keeping at least the least significant parts of the packet number being non-encrypted. I don't see the linkability need to be significantly impacted. A single QUIC flow will still have the 5-tuple of IPvX+UDP that enables to identify where it comes from and where it goes. I still haven't seen any good motivation why you would actually have multiple QUIC connections on the same 5-tuple. Thus, the single path of the connection will leak very little additional information other than how the flow is being treated by the network. For a 3rd party observing this from the outside, for flows with little losses you still see most packets, in this case I don't see that determining that losses are present upstream affects how you can correlate this with other. In the case of continuing a flow on another path, I would not really have problem with introducing a larger gap to reduce the linkability between the different flows that are used by the connection. Because, from my perspective, it would be preferable that each flow over different path actually are treated as individual sub-flow. Thus, they could have completely independent packet numbers. Such a direction appear to reduce linkability, without preventing exposing the basic flows transport progress. Cheers Magnus > On 20 July 2017 at 11:59, Magnus Westerlund > <magnus.westerlund@ericsson.com> wrote: >> Hi, >> >> There has been some discussion around packet numbers. For passive detection >> of packet loss in measurements and network management, it would be really >> good if the packet numbers where continuous and not only monotonically >> increasing. As this enables one to determine losses upstream of the >> measurement point. At the same time I understand there are benefits with >> being able to introduce gaps into the packet number to test the receiver's >> behaviour. >> >> To enable both of these capabilities I would propose that the N least >> significant bits of the packet number are strictly increased by one. Then >> one can introduce gaps in the bits above the N ones. Yes, that will burn >> through the packet number space faster as the gaps may become larger than >> was the case without this. However, I don't see that this will have >> significant effect unless the sender introduce gaps very frequently so that >> the length of the packet number field needs to be much larger due to the >> outstanding sequence number space is much larger. >> >> The value of N can clearly be discussed but it should be selected so that >> reordering and common burst durations are shorter than the time to wrap the >> strictly increase amount of bits. If the higher bits are available to >> measurement node, some possibility to infer gaps will also be possible. It >> might be that N needs to be scaled with throughput with a minimal value. N=8 >> would mean 256 packets between wraps. I think that is a reasonable minimal >> value. However, that will wrap in 28 ms at 100 mbps of payload (assuming >> 1400 bytes of payload per packet). >> >> So what people think about this idea? >> >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Media Technologies, Ericsson Research >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Torshamnsgatan 23 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> -- Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
- Idea for packet numbers Magnus Westerlund
- Re: Idea for packet numbers Martin Thomson
- Re: Idea for packet numbers Mikkel Fahnøe Jørgensen
- Re: Idea for packet numbers Magnus Westerlund
- Re: Idea for packet numbers Martin Thomson
- Re: Idea for packet numbers Magnus Westerlund
- Re: Idea for packet numbers Martin Thomson
- Re: Idea for packet numbers Spencer Dawkins at IETF
- Re: Idea for packet numbers Dmitri Tikhonov
- RE: Idea for packet numbers Swindells, Thomas (Nokia - GB/Cambridge, UK)
- Re: Idea for packet numbers Ian Swett
- Re: Idea for packet numbers Mikkel Fahnøe Jørgensen
- RE: Idea for packet numbers Swindells, Thomas (Nokia - GB/Cambridge, UK)
- Re: Idea for packet numbers Dmitri Tikhonov
- RE: Idea for packet numbers Kyle Rose
- RE: Idea for packet numbers Swindells, Thomas (Nokia - GB/Cambridge, UK)
- RE: Idea for packet numbers MORTON, ALFRED C (AL)
- Re: Idea for packet numbers Ian Swett
- RE: Idea for packet numbers Swindells, Thomas (Nokia - GB/Cambridge, UK)
- Re: Idea for packet numbers Dmitri Tikhonov
- RE: Idea for packet numbers Swindells, Thomas (Nokia - GB/Cambridge, UK)
- Re: Idea for packet numbers Jana Iyengar
- Re: Idea for packet numbers Dmitri Tikhonov