From nobody Wed Oct 16 12:28:43 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB141200FA for ; Wed, 16 Oct 2019 12:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 dU0UstqiKH3G for ; Wed, 16 Oct 2019 12:28:39 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 123FC120020 for ; Wed, 16 Oct 2019 12:28:39 -0700 (PDT) Received: from [192.168.217.110] (p548DCE50.dip0.t-ipconnect.de [84.141.206.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46tj5K4lt8zyPH; Wed, 16 Oct 2019 21:28:37 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 592946913.71355-438100d5a9f208dd60658282cb7ed36a Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 16 Oct 2019 21:28:37 +0200 Message-Id: <85A3D130-43C8-4D89-B45B-75632331C5DF@tzi.org> To: loops@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [LOOPS] Timestamps and delay measurements X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 19:28:41 -0000 In the process of preparing the next version of the gen-info draft, = there are a few items where it probably would be good to get wider = input. One of these is the use of timestamps. Gen-info says that =E2=80=9Cblock 1=E2=80=9D reverse information = (requested using the =E2=80=9CACK desirable=E2=80=9D flag) has a wall = clock time of reception of the forward packet that was triggering it. = This is a good way to measure one way latency if we believe the clocks = on ingress and egress are synchronized; the quality of that = synchronization limits the quality of the measurements. The mechanism = is still reasonable as a way to measure one way latency variance if we = believe the clocks are maybe not synchronized, but do advance along the = same time scale. Question 1: In your applications, would you expect to have reasonably synchronized = clocks between ingress and egress? Reasonable clocks at all? Do you = have data points, e.g., for random VMs in the cloud? The prototype protocol described in appendix A uses a different form of = timestamps: timestamps on a local timescale of the ingress (not further = specified by the protocol) can be inserted by the ingress and are echoed = back in ACKs. (No information about time at egress is used.) This can = be used to cheaply obtain samples of round-trip time, including delays = in sending back the ACK. The timestamp is not strictly necessary if = there is another correlation mechanism, as the timestamp can be stored = at the ingress and retrieved if an ACK comes back. This has two = drawbacks: (1) The timestamp needs to be stored with the cached packet, = which may or may not be easy in a specific implementation, and (2) the = correlation afforded by a packet sequence number has ACK ambiguity if = the PSN is re-used in a retransmission (see the other message). Question 2: In your implementations, is it onerous to store a transmission timestamp = with a cached (for retransmission) packet on the ingress? The assumption of gen-info is that it is good to have samples of one-way = delay in order to assess congestion, and that some measurement of = round-trip delay is needed as an overall timing of retransmission and = for ejecting cached packets. Anything else you would expect LOOPS to = measure in the way of timing? Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Oct 16 13:07:13 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7DF120116 for ; Wed, 16 Oct 2019 13:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 gj2WGkL14_13 for ; Wed, 16 Oct 2019 13:07:10 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05E89120122 for ; Wed, 16 Oct 2019 13:07:10 -0700 (PDT) Received: from [192.168.217.110] (p548DCE50.dip0.t-ipconnect.de [84.141.206.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46tjxm4lYRzySD; Wed, 16 Oct 2019 22:07:08 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 592949221.51107-89012bd7c030ae66ef90153e226e49d2 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 16 Oct 2019 22:07:08 +0200 Message-Id: <289BCF98-9F51-4E22-B8E2-50E17C1E8644@tzi.org> To: loops@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [LOOPS] Packet sequence numbers X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 20:07:12 -0000 In the process of preparing the next version of the gen-info draft, = there are a few items where it probably would be good to get wider = input. One of these is the use of packet sequence numbers. Gen-info says that the packet sequence number (PSN) counts the LOOPS = packets transmitted by the LOOPS ingress, i.e., that retransmissions = receive a new PSN. This removes ACK ambiguity: the situation where original transmission = and retransmissions carry the same sequence number and an ACK therefore = cannot be unambiguously assigned to one of the transmission never = occurs. Disadvantages may include: * Without additional information, the original sequence of the packets = is no longer visible at the egress. This means that not enough = information is available to perform resequencing at the egress. = (Resequencing is not a feature of LOOPS, but could be easily added by an = implementation if overall latency is not an issue and enough information = is available at the egress.) * FEC will not be able to derive a lot of information from the packet = sequence number, so will need some additional information, too. * Monitoring tools that are looking at the PSN will simply see the holes = created by the losses on the LOOPS segment and not the successful repair = actions. (But the same is true for FEC, so maybe these monitoring tools = are too simple.) Advantages may include: * No ACK ambiguity. * The need for back-filling ACK bitmaps is limited to the time scale of = reordering (if any at all). * Somewhat simplified implementation: NACKs for sequence numbers that = already have been retransmitted don=E2=80=99t need a hold-off =E2=80=94 = the cached packets are simply swept to their new numbers at the ingress = and repetitions of old NACKs can be ignored. On the other hand, some = retransmission counter will need to be on each packet to avoid = 1-persistence. One question that comes up about implementation is how likely a = =E2=80=9Csingle retransmission=E2=80=9D optimization will be: An = implementation that only ever retransmits a packet once can simply = delete the cache entry after retransmission instead of sweeping it to = the new number. Single retransmission actually fits many usage = scenarios well, as it essentially squares the non-delivery reliability = for random losses, which may be all that is needed. Opinions? Should LOOPS be more like QUIC or like protocols that have = been around for a few decades? Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Oct 17 05:28:11 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F2E1200C5 for ; Thu, 17 Oct 2019 05:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 O27-1Wn14SjL for ; Thu, 17 Oct 2019 05:28:07 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 8051612006A for ; Thu, 17 Oct 2019 05:28:07 -0700 (PDT) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 16360AAB4892AAB697AE for ; Thu, 17 Oct 2019 13:28:05 +0100 (IST) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 17 Oct 2019 13:28:04 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.211]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0439.000; Thu, 17 Oct 2019 20:27:57 +0800 From: Liyizhou To: Carsten Bormann , "loops@ietf.org" Thread-Topic: [LOOPS] Packet sequence numbers Thread-Index: AQHVhF1XOuWZckiyl0+8yqdtNhDgJqdesGpw Date: Thu, 17 Oct 2019 12:27:57 +0000 Message-ID: References: <289BCF98-9F51-4E22-B8E2-50E17C1E8644@tzi.org> In-Reply-To: <289BCF98-9F51-4E22-B8E2-50E17C1E8644@tzi.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.186.90] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [LOOPS] Packet sequence numbers X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2019 12:28:10 -0000 SGkgQ2Fyc3RlbiwNCg0KRm9yIHBhY2tldCBzZXF1ZW5jZSBudW1iZXIgKFBTTikgaW4gYSByZXRy YW5zbWl0IHBhY2tldCwgdXNpbmcgdGhlIG9sZCBQU04gbG9va3MgbW9yZSByZWFzb25hYmxlIHRv IG1lLg0KDQpXaGVuIExPT1BTIHVzZXMgcHNuIHRvIGxpbmsgYW4gb2xkIChsb3N0KSBwYWNrZXQg dG8gYSByZXRyYW5zbWl0IG9uZSwgaXQgaGVscHMgYSBsb3Qgd2hlbiBkZXZlbG9waW5nIGFuZCBk ZWJ1Z2dpbmcgY29kZS4gVmVyeSBzdHJhaWdodGZvcndhcmQgdG8ga25vdyBpZiB0aGUgcmV0cmFu c21pc3Npb24gZm9yIGEgc3BlY2lmaWMgcGFja2V0IHdvcmtzIGluIGEgd2F5IGFzIGRlc2lnbmVk LiBBbmQgYWxzbyBtYWtlcyB0cm91Ymxlc2hvb3RpbmcgZWFzaWVyIHdoZW4gaXQgZ29lcyB0byBj b21tZXJjaWFsIHZlcnNpb24gaW4gbXkgb3Bpbmlvbi4NCk90aGVyd2lzZSwgd2UgaGF2ZSB0byBn dWVzcywgZS5nLiBwYWNrZXQgMTAgaXMgYSByZXRyYW5zbWl0IGZvciBwYWNrZXQgMiwgYW5kIHBh Y2tldCAxMSBpcyBhIHJldHJhbnNtaXQgZm9yIHBhY2tldCA0LCB0YWtlcyBtb3JlIGVmZm9ydCBm b3IgZGV2ZWxvcGVyL3Rvb2xzLg0KDQpRVUlDIHVzZXMgYSBuZXcgcGFja2V0IG51bWJlciBmb3Ig YSByZXRyYW5zbWl0IHBhY2tldC4gQXQgdGhlIHNhbWUgdGltZSwgc3RyZWFtIGlkIGFuZCBvZmZz ZXQgZmllbGQgY2FuIGhlbHAgdG8gZWFzaWx5IGlkZW50aWZ5IHdoYXQgaGF2ZSBiZWVuIHJldHJh bnNtaXR0ZWQuIEhvd2V2ZXIgTE9PUFMgZG9lcyBub3QgbG9vayBpbnRvIHRoZSBkYXRhLiBTbyBp dCB3b3VsZCBiZSBwcmVmZXJhYmxlIHRvICBtYWtlIExPT1BTIGhlYWRlciBpbmZvcm1hdGlvbiBt b3JlIHNlbGYtZGVzY3JpcHRpdmUgb24gd2hpY2ggcGFja2V0IGl0IGlzIHJldHJhbnNtaXR0aW5n LiANCg0KQ2VydGFpbmx5IHVzaW5nIG9sZCBQU04gY2F1c2VzIEFDSyBhbWJpZ3VpdHkuIEl0IGZ1 cnRoZXIgY2F1c2VzIGluYWNjdXJhdGUgUlRUIGNhbGN1bGF0aW9uIChtYWpvcikgYW5kIGluYWJp bGl0eSB0byB0ZWxsIHNwdXJpb3VzIHJldHJhbnNtaXNzaW9uIChtaW5vcikuIEkgZG8gbm90IHRo aW5rIGl0IGlzIGEgYmlnIGlzc3VlIGluIExPT1BTLiBUaW1lc3RhbXAgY2FuIGJlIGNhcnJpZWQg YW5kIGVjaG9lZCBiYWNrIGluIGxvb3BzLiBJdCBzb2x2ZXMgdGhlIG1ham9yIHByb2JsZW0gb2Yg UlRUIGNhbGN1bGF0aW9uLiAgQXQgdGhlIHNhbWUgdGltZSwgdW5saW5rIFRDUCwgTE9PUFMgaW5n cmVzcyBoYXMgbm8gd2luZG93IHRvIG1haW50YWluLiBTbyB1bmRvIHdpbmRvdyByZWR1Y3Rpb24g YWZ0ZXIgc3B1cmlvdXMgcmV0cmFuc21pc3Npb24gaXMgbm90IGV2ZW4gIG5lZWRlZC4gIA0KDQpG b3Igc2luZ2xlIHJldHJhbnNtaXNzaW9uIG1vZGUsIEkgdGhpbmsgaXQgaXMgYSBnb29kIGlkZWEu IEluIG91ciBleHBlcmltZW50cywgIFdBTiBhY3Jvc3MgY291bnRyaWVzLCBtb3N0IGxvc3QgcGFj a2V0IGNhbiBiZSByZWNvdmVyZWQgYnkgcmV0cmFuc21pdHRpbmcgb25seSBvbmNlLiBCdXQgSSBz dXNwZWN0IGlmIHRoZXJlIGlzIGFueSB3aXJlbGVzcyBsaW5rLCBzaW5nbGUgcmV0cmFuc21pc3Np b24gd291bGQgbm90IGJlIGVub3VnaC4gU28gcHJvYmFibHkgd2UgbmVlZCB0byBwcm92aWRlIGJv dGggc2luZ2xlIHJldHJhbnNtaXNzaW9uIG1vZGUgYW5kIGNvbmZpZ3VyYWJsZSBtb2RlIChpbiB0 aW1lIG9yIGluICBudW1iZXIgb2YgcmV0cmFuc21pdCB0aW1lcykuDQoNClJlZ2FyZHMsDQpZaXpo b3UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExPT1BTIFttYWlsdG86bG9v cHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENhcnN0ZW4gQm9ybWFubg0KU2VudDog VGh1cnNkYXksIE9jdG9iZXIgMTcsIDIwMTkgNDowNyBBTQ0KVG86IGxvb3BzQGlldGYub3JnDQpT dWJqZWN0OiBbTE9PUFNdIFBhY2tldCBzZXF1ZW5jZSBudW1iZXJzDQoNCkluIHRoZSBwcm9jZXNz IG9mIHByZXBhcmluZyB0aGUgbmV4dCB2ZXJzaW9uIG9mIHRoZSBnZW4taW5mbyBkcmFmdCwgdGhl cmUgYXJlIGEgZmV3IGl0ZW1zIHdoZXJlIGl0IHByb2JhYmx5IHdvdWxkIGJlIGdvb2QgdG8gZ2V0 IHdpZGVyIGlucHV0Lg0KDQpPbmUgb2YgdGhlc2UgaXMgdGhlIHVzZSBvZiBwYWNrZXQgc2VxdWVu Y2UgbnVtYmVycy4NCg0KR2VuLWluZm8gc2F5cyB0aGF0IHRoZSBwYWNrZXQgc2VxdWVuY2UgbnVt YmVyIChQU04pIGNvdW50cyB0aGUgTE9PUFMgcGFja2V0cyB0cmFuc21pdHRlZCBieSB0aGUgTE9P UFMgaW5ncmVzcywgaS5lLiwgdGhhdCByZXRyYW5zbWlzc2lvbnMgcmVjZWl2ZSBhIG5ldyBQU04u DQoNClRoaXMgcmVtb3ZlcyBBQ0sgYW1iaWd1aXR5OiB0aGUgc2l0dWF0aW9uIHdoZXJlIG9yaWdp bmFsIHRyYW5zbWlzc2lvbiBhbmQgcmV0cmFuc21pc3Npb25zIGNhcnJ5IHRoZSBzYW1lIHNlcXVl bmNlIG51bWJlciBhbmQgYW4gQUNLIHRoZXJlZm9yZSBjYW5ub3QgYmUgdW5hbWJpZ3VvdXNseSBh c3NpZ25lZCB0byBvbmUgb2YgdGhlIHRyYW5zbWlzc2lvbiBuZXZlciBvY2N1cnMuDQoNCkRpc2Fk dmFudGFnZXMgbWF5IGluY2x1ZGU6DQoNCiogV2l0aG91dCBhZGRpdGlvbmFsIGluZm9ybWF0aW9u LCB0aGUgb3JpZ2luYWwgc2VxdWVuY2Ugb2YgdGhlIHBhY2tldHMgaXMgbm8gbG9uZ2VyIHZpc2li bGUgYXQgdGhlIGVncmVzcy4gIFRoaXMgbWVhbnMgdGhhdCBub3QgZW5vdWdoIGluZm9ybWF0aW9u IGlzIGF2YWlsYWJsZSB0byBwZXJmb3JtIHJlc2VxdWVuY2luZyBhdCB0aGUgZWdyZXNzLiAgKFJl c2VxdWVuY2luZyBpcyBub3QgYSBmZWF0dXJlIG9mIExPT1BTLCBidXQgY291bGQgYmUgZWFzaWx5 IGFkZGVkIGJ5IGFuIGltcGxlbWVudGF0aW9uIGlmIG92ZXJhbGwgbGF0ZW5jeSBpcyBub3QgYW4g aXNzdWUgYW5kIGVub3VnaCBpbmZvcm1hdGlvbiBpcyBhdmFpbGFibGUgYXQgdGhlIGVncmVzcy4p DQoNCiogRkVDIHdpbGwgbm90IGJlIGFibGUgdG8gZGVyaXZlIGEgbG90IG9mIGluZm9ybWF0aW9u IGZyb20gdGhlIHBhY2tldCBzZXF1ZW5jZSBudW1iZXIsIHNvIHdpbGwgbmVlZCBzb21lIGFkZGl0 aW9uYWwgaW5mb3JtYXRpb24sIHRvby4NCg0KKiBNb25pdG9yaW5nIHRvb2xzIHRoYXQgYXJlIGxv b2tpbmcgYXQgdGhlIFBTTiB3aWxsIHNpbXBseSBzZWUgdGhlIGhvbGVzIGNyZWF0ZWQgYnkgdGhl IGxvc3NlcyBvbiB0aGUgTE9PUFMgc2VnbWVudCBhbmQgbm90IHRoZSBzdWNjZXNzZnVsIHJlcGFp ciBhY3Rpb25zLiAgKEJ1dCB0aGUgc2FtZSBpcyB0cnVlIGZvciBGRUMsIHNvIG1heWJlIHRoZXNl IG1vbml0b3JpbmcgdG9vbHMgYXJlIHRvbyBzaW1wbGUuKQ0KDQpBZHZhbnRhZ2VzIG1heSBpbmNs dWRlOg0KDQoqIE5vIEFDSyBhbWJpZ3VpdHkuDQoNCiogVGhlIG5lZWQgZm9yIGJhY2stZmlsbGlu ZyBBQ0sgYml0bWFwcyBpcyBsaW1pdGVkIHRvIHRoZSB0aW1lIHNjYWxlIG9mIHJlb3JkZXJpbmcg KGlmIGFueSBhdCBhbGwpLg0KDQoqIFNvbWV3aGF0IHNpbXBsaWZpZWQgaW1wbGVtZW50YXRpb246 IE5BQ0tzIGZvciBzZXF1ZW5jZSBudW1iZXJzIHRoYXQgYWxyZWFkeSBoYXZlIGJlZW4gcmV0cmFu c21pdHRlZCBkb27igJl0IG5lZWQgYSBob2xkLW9mZiDigJQgdGhlIGNhY2hlZCBwYWNrZXRzIGFy ZSBzaW1wbHkgc3dlcHQgdG8gdGhlaXIgbmV3IG51bWJlcnMgYXQgdGhlIGluZ3Jlc3MgYW5kIHJl cGV0aXRpb25zIG9mIG9sZCBOQUNLcyBjYW4gYmUgaWdub3JlZC4gIE9uIHRoZSBvdGhlciBoYW5k LCBzb21lIHJldHJhbnNtaXNzaW9uIGNvdW50ZXIgd2lsbCBuZWVkIHRvIGJlIG9uIGVhY2ggcGFj a2V0IHRvIGF2b2lkIDEtcGVyc2lzdGVuY2UuDQoNCk9uZSBxdWVzdGlvbiB0aGF0IGNvbWVzIHVw IGFib3V0IGltcGxlbWVudGF0aW9uIGlzIGhvdyBsaWtlbHkgYSDigJxzaW5nbGUgcmV0cmFuc21p c3Npb27igJ0gb3B0aW1pemF0aW9uIHdpbGwgYmU6IEFuIGltcGxlbWVudGF0aW9uIHRoYXQgb25s eSBldmVyIHJldHJhbnNtaXRzIGEgcGFja2V0IG9uY2UgY2FuIHNpbXBseSBkZWxldGUgdGhlIGNh Y2hlIGVudHJ5IGFmdGVyIHJldHJhbnNtaXNzaW9uIGluc3RlYWQgb2Ygc3dlZXBpbmcgaXQgdG8g dGhlIG5ldyBudW1iZXIuICBTaW5nbGUgcmV0cmFuc21pc3Npb24gYWN0dWFsbHkgZml0cyBtYW55 IHVzYWdlIHNjZW5hcmlvcyB3ZWxsLCBhcyBpdCBlc3NlbnRpYWxseSBzcXVhcmVzIHRoZSBub24t ZGVsaXZlcnkgcmVsaWFiaWxpdHkgZm9yIHJhbmRvbSBsb3NzZXMsIHdoaWNoIG1heSBiZSBhbGwg dGhhdCBpcyBuZWVkZWQuDQoNCk9waW5pb25zPyAgU2hvdWxkIExPT1BTIGJlIG1vcmUgbGlrZSBR VUlDIG9yIGxpa2UgcHJvdG9jb2xzIHRoYXQgaGF2ZSBiZWVuIGFyb3VuZCBmb3IgYSBmZXcgZGVj YWRlcz8NCg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQoNCi0tIA0KTE9PUFMgbWFpbGluZyBsaXN0DQpM T09QU0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sb29w cw0K From nobody Fri Oct 18 02:59:25 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1FA1120886 for ; Fri, 18 Oct 2019 02:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 r_TnGNlfmpRr for ; Fri, 18 Oct 2019 02:59:20 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 4A65B1200E0 for ; Fri, 18 Oct 2019 02:59:19 -0700 (PDT) Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1iLP2L-000ESS-Fe; Fri, 18 Oct 2019 11:59:09 +0200 Received: from ti0182q160-2022.bb.online.no ([212.251.170.252] helo=[10.0.0.10]) by mail-mx12.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.92.3) (envelope-from ) id 1iLP2K-0007vg-Oo; Fri, 18 Oct 2019 11:59:09 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Michael Welzl In-Reply-To: Date: Fri, 18 Oct 2019 11:59:05 +0200 Cc: Carsten Bormann , "loops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3B1DB1C6-9E23-47C2-B7FA-A41079BF1490@ifi.uio.no> References: <289BCF98-9F51-4E22-B8E2-50E17C1E8644@tzi.org> To: Liyizhou X-Mailer: Apple Mail (2.3445.104.11) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 212.251.170.252 is neither permitted nor denied by domain of ifi.uio.no) client-ip=212.251.170.252; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.10]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 11BE7A6FF8A1EA3F347D43BE56BB4708D7E3934C Archived-At: Subject: Re: [LOOPS] Packet sequence numbers X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 09:59:23 -0000 Hi, > On Oct 17, 2019, at 2:27 PM, Liyizhou wrote: >=20 > Hi Carsten, >=20 > For packet sequence number (PSN) in a retransmit packet, using the old = PSN looks more reasonable to me. >=20 > When LOOPS uses psn to link an old (lost) packet to a retransmit one, = it helps a lot when developing and debugging code. Very straightforward = to know if the retransmission for a specific packet works in a way as = designed. And also makes troubleshooting easier when it goes to = commercial version in my opinion. > Otherwise, we have to guess, e.g. packet 10 is a retransmit for packet = 2, and packet 11 is a retransmit for packet 4, takes more effort for = developer/tools. >=20 > QUIC uses a new packet number for a retransmit packet. At the same = time, stream id and offset field can help to easily identify what have = been retransmitted. However LOOPS does not look into the data. So it = would be preferable to make LOOPS header information more = self-descriptive on which packet it is retransmitting.=20 >=20 > Certainly using old PSN causes ACK ambiguity. It further causes = inaccurate RTT calculation (major) and inability to tell spurious = retransmission (minor). I do not think it is a big issue in LOOPS. = Timestamp can be carried and echoed back in loops. It solves the major = problem of RTT calculation. At the same time, unlink TCP, LOOPS ingress = has no window to maintain. So undo window reduction after spurious = retransmission is not even needed. =20 Even though I originally suggested the QUIC method of continuously = increasing sequence numbers, I think this assessment of the trade-offs = is very good, and now I tend to agree that, for LOOPS, repeating = sequence numbers would be better. > For single retransmission mode, I think it is a good idea. In our = experiments, WAN across countries, most lost packet can be recovered by = retransmitting only once. But I suspect if there is any wireless link, = single retransmission would not be enough. So probably we need to = provide both single retransmission mode and configurable mode (in time = or in number of retransmit times). +1 on the need for more-than-once, for wireless links. Cheers, Michael From nobody Sun Oct 20 23:48:56 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F47120077 for ; Sun, 20 Oct 2019 23:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 hw7h0KDvhSaO for ; Sun, 20 Oct 2019 23:48:51 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 B1C77120052 for ; Sun, 20 Oct 2019 23:48:51 -0700 (PDT) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 70F808D13FE1CD2D4F6B for ; Mon, 21 Oct 2019 07:48:49 +0100 (IST) Received: from dggeme707-chm.china.huawei.com (10.1.199.103) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 21 Oct 2019 07:48:48 +0100 Received: from dggeme758-chm.china.huawei.com (10.3.19.104) by dggeme707-chm.china.huawei.com (10.1.199.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 21 Oct 2019 14:48:46 +0800 Received: from dggeme758-chm.china.huawei.com ([10.6.80.69]) by dggeme758-chm.china.huawei.com ([10.6.80.69]) with mapi id 15.01.1713.004; Mon, 21 Oct 2019 14:48:46 +0800 From: "Zhouxingwang (Joe)" To: Carsten Bormann , "loops@ietf.org" Thread-Topic: [LOOPS] Timestamps and delay measurements Thread-Index: AQHVhFgaGwW/9H9a+E6l28ETvKQS9adkXrCQ Date: Mon, 21 Oct 2019 06:48:46 +0000 Message-ID: References: <85A3D130-43C8-4D89-B45B-75632331C5DF@tzi.org> In-Reply-To: <85A3D130-43C8-4D89-B45B-75632331C5DF@tzi.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.27.230] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [LOOPS] Timestamps and delay measurements X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2019 06:48:54 -0000 SGkgQ2Fyc3RlbiwgDQoNCkFib3V0IHRoZSByYW5kb20gVk1zLCBzb21lIHB1YmxpYyBjbG91ZCBw cm92aWRlciBkb2VzIG5vdCBwcm92aWRlIHRoZSBzeW5jaHJvbml6ZWQgdGltZSBmb3IgdGhlaXIg Vk1zIGJ5IGRlZmF1bHQsIGFuZCB0aGUgdGltZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIFZNcyBj aGFuZ2VzIGEgbGl0dGxlIChmb3VuZCBhIDM3NTBtcyB2YXJpYXRpb24gZm9yIGxpa2UgNDAgaG91 cnMgcm91Z2hseSkuDQpBbmQgZm9yIHRoZSBjYWNoZWQgdGltZXN0YW1wLCBpdCB3aWxsIGJlIGEg cHJvYmxlbSBpZiBMT09QUyBpcyBpbXBsZW1lbnRlZCBpbiBoaWdoIHNwZWVkIGFuZCBtZW1vcnkg bGltaXRlZCBkZXZpY2UsIGxpa2UgcGh5c2ljYWwgc3dpdGNoIG9yIHJvdXRlci4NCg0KVGhhbmtz DQpKb2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExPT1BTIFttYWlsdG86 bG9vcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENhcnN0ZW4gQm9ybWFubg0KU2Vu dDogVGh1cnNkYXksIE9jdG9iZXIgMTcsIDIwMTkgMzoyOSBBTQ0KVG86IGxvb3BzQGlldGYub3Jn DQpTdWJqZWN0OiBbTE9PUFNdIFRpbWVzdGFtcHMgYW5kIGRlbGF5IG1lYXN1cmVtZW50cw0KDQpJ biB0aGUgcHJvY2VzcyBvZiBwcmVwYXJpbmcgdGhlIG5leHQgdmVyc2lvbiBvZiB0aGUgZ2VuLWlu Zm8gZHJhZnQsIHRoZXJlIGFyZSBhIGZldyBpdGVtcyB3aGVyZSBpdCBwcm9iYWJseSB3b3VsZCBi ZSBnb29kIHRvIGdldCB3aWRlciBpbnB1dC4NCg0KT25lIG9mIHRoZXNlIGlzIHRoZSB1c2Ugb2Yg dGltZXN0YW1wcy4NCg0KR2VuLWluZm8gc2F5cyB0aGF0IOKAnGJsb2NrIDHigJ0gcmV2ZXJzZSBp bmZvcm1hdGlvbiAocmVxdWVzdGVkIHVzaW5nIHRoZSDigJxBQ0sgZGVzaXJhYmxl4oCdIGZsYWcp IGhhcyBhIHdhbGwgY2xvY2sgdGltZSBvZiByZWNlcHRpb24gb2YgdGhlIGZvcndhcmQgcGFja2V0 IHRoYXQgd2FzIHRyaWdnZXJpbmcgaXQuICBUaGlzIGlzIGEgZ29vZCB3YXkgdG8gbWVhc3VyZSBv bmUgd2F5IGxhdGVuY3kgaWYgd2UgYmVsaWV2ZSB0aGUgY2xvY2tzIG9uIGluZ3Jlc3MgYW5kIGVn cmVzcyBhcmUgc3luY2hyb25pemVkOyB0aGUgcXVhbGl0eSBvZiB0aGF0IHN5bmNocm9uaXphdGlv biBsaW1pdHMgdGhlIHF1YWxpdHkgb2YgdGhlIG1lYXN1cmVtZW50cy4gIFRoZSBtZWNoYW5pc20g aXMgc3RpbGwgcmVhc29uYWJsZSBhcyBhIHdheSB0byBtZWFzdXJlIG9uZSB3YXkgbGF0ZW5jeSB2 YXJpYW5jZSBpZiB3ZSBiZWxpZXZlIHRoZSBjbG9ja3MgYXJlIG1heWJlIG5vdCBzeW5jaHJvbml6 ZWQsIGJ1dCBkbyBhZHZhbmNlIGFsb25nIHRoZSBzYW1lIHRpbWUgc2NhbGUuDQoNClF1ZXN0aW9u IDE6DQpJbiB5b3VyIGFwcGxpY2F0aW9ucywgd291bGQgeW91IGV4cGVjdCB0byBoYXZlIHJlYXNv bmFibHkgc3luY2hyb25pemVkIGNsb2NrcyBiZXR3ZWVuIGluZ3Jlc3MgYW5kIGVncmVzcz8gIFJl YXNvbmFibGUgY2xvY2tzIGF0IGFsbD8gIERvIHlvdSBoYXZlIGRhdGEgcG9pbnRzLCBlLmcuLCBm b3IgcmFuZG9tIFZNcyBpbiB0aGUgY2xvdWQ/DQoNClRoZSBwcm90b3R5cGUgcHJvdG9jb2wgZGVz Y3JpYmVkIGluIGFwcGVuZGl4IEEgdXNlcyBhIGRpZmZlcmVudCBmb3JtIG9mIHRpbWVzdGFtcHM6 IHRpbWVzdGFtcHMgb24gYSBsb2NhbCB0aW1lc2NhbGUgb2YgdGhlIGluZ3Jlc3MgKG5vdCBmdXJ0 aGVyIHNwZWNpZmllZCBieSB0aGUgcHJvdG9jb2wpIGNhbiBiZSBpbnNlcnRlZCBieSB0aGUgaW5n cmVzcyBhbmQgYXJlIGVjaG9lZCBiYWNrIGluIEFDS3MuICAoTm8gaW5mb3JtYXRpb24gYWJvdXQg dGltZSBhdCBlZ3Jlc3MgaXMgdXNlZC4pICBUaGlzIGNhbiBiZSB1c2VkIHRvIGNoZWFwbHkgb2J0 YWluIHNhbXBsZXMgb2Ygcm91bmQtdHJpcCB0aW1lLCBpbmNsdWRpbmcgZGVsYXlzIGluIHNlbmRp bmcgYmFjayB0aGUgQUNLLiAgVGhlIHRpbWVzdGFtcCBpcyBub3Qgc3RyaWN0bHkgbmVjZXNzYXJ5 IGlmIHRoZXJlIGlzIGFub3RoZXIgY29ycmVsYXRpb24gbWVjaGFuaXNtLCBhcyB0aGUgdGltZXN0 YW1wIGNhbiBiZSBzdG9yZWQgYXQgdGhlIGluZ3Jlc3MgYW5kIHJldHJpZXZlZCBpZiBhbiBBQ0sg Y29tZXMgYmFjay4gIFRoaXMgaGFzIHR3byBkcmF3YmFja3M6ICAoMSkgVGhlIHRpbWVzdGFtcCBu ZWVkcyB0byBiZSBzdG9yZWQgd2l0aCB0aGUgY2FjaGVkIHBhY2tldCwgd2hpY2ggbWF5IG9yIG1h eSBub3QgYmUgZWFzeSBpbiBhIHNwZWNpZmljIGltcGxlbWVudGF0aW9uLCBhbmQgKDIpIHRoZSBj b3JyZWxhdGlvbiBhZmZvcmRlZCBieSBhIHBhY2tldCBzZXF1ZW5jZSBudW1iZXIgaGFzIEFDSyBh bWJpZ3VpdHkgaWYgdGhlIFBTTiBpcyByZS11c2VkIGluIGEgcmV0cmFuc21pc3Npb24gKHNlZSB0 aGUgb3RoZXIgbWVzc2FnZSkuDQoNClF1ZXN0aW9uIDI6DQpJbiB5b3VyIGltcGxlbWVudGF0aW9u cywgaXMgaXQgb25lcm91cyB0byBzdG9yZSBhIHRyYW5zbWlzc2lvbiB0aW1lc3RhbXAgd2l0aCBh IGNhY2hlZCAoZm9yIHJldHJhbnNtaXNzaW9uKSBwYWNrZXQgb24gdGhlIGluZ3Jlc3M/DQoNClRo ZSBhc3N1bXB0aW9uIG9mIGdlbi1pbmZvIGlzIHRoYXQgaXQgaXMgZ29vZCB0byBoYXZlIHNhbXBs ZXMgb2Ygb25lLXdheSBkZWxheSBpbiBvcmRlciB0byBhc3Nlc3MgY29uZ2VzdGlvbiwgYW5kIHRo YXQgc29tZSBtZWFzdXJlbWVudCBvZiByb3VuZC10cmlwIGRlbGF5IGlzIG5lZWRlZCBhcyBhbiBv dmVyYWxsIHRpbWluZyBvZiByZXRyYW5zbWlzc2lvbiBhbmQgZm9yIGVqZWN0aW5nIGNhY2hlZCBw YWNrZXRzLiAgQW55dGhpbmcgZWxzZSB5b3Ugd291bGQgZXhwZWN0IExPT1BTIHRvIG1lYXN1cmUg aW4gdGhlIHdheSBvZiB0aW1pbmc/DQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0KLS0gDQpMT09QUyBt YWlsaW5nIGxpc3QNCkxPT1BTQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2xvb3BzDQo= From nobody Mon Oct 21 13:45:11 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD7712098E for ; Mon, 21 Oct 2019 13:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 72Pup0Dke3Zn for ; Mon, 21 Oct 2019 13:45:05 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29EE512090B for ; Mon, 21 Oct 2019 13:45:05 -0700 (PDT) Received: from [192.168.217.110] (p5089AE1C.dip0.t-ipconnect.de [80.137.174.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46xpYC2lpyz10FW; Mon, 21 Oct 2019 22:45:03 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <3B1DB1C6-9E23-47C2-B7FA-A41079BF1490@ifi.uio.no> Date: Mon, 21 Oct 2019 22:45:02 +0200 X-Mao-Original-Outgoing-Id: 593383500.971416-f04eb888890b944ebb682ccb7f47b98f Content-Transfer-Encoding: quoted-printable Message-Id: <72B131DC-5255-4310-A148-15BC7A5698D1@tzi.org> References: <289BCF98-9F51-4E22-B8E2-50E17C1E8644@tzi.org> <3B1DB1C6-9E23-47C2-B7FA-A41079BF1490@ifi.uio.no> To: "loops@ietf.org" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [LOOPS] Packet sequence numbers X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2019 20:45:08 -0000 > Even though I originally suggested the QUIC method of continuously = increasing sequence numbers, I think this assessment of the trade-offs = is very good, and now I tend to agree that, for LOOPS, repeating = sequence numbers would be better. I think that this conclusion is a good basis for continuing the work. I made the necessary changes (I think) in = https://github.com/loops-wg/gen-info/commit/2dd7634 I also added some text about mitigating ACK ambiguity, which is = facilitated if the ingress never sets =E2=80=9CACK desired=E2=80=9D on a = retransmission. There is currently no detailed text on how to decide to retransmit. The = current spec is mute (a.k.a. =E2=80=9Cflexible=E2=80=9D) on the = implementation strategy. For hole-based retransmission triggering, = re-using the PSD needs to include a hold-off for packets that have = recently been retransmitted so another copy of block 2 information that = just confirms the existing hole doesn=E2=80=99t trigger another = retransmission. For a time-based retransmission scheme (as in RACK), = retransmission would simply move forward the packet into the then = appropriate slot. > +1 on the need for more-than-once, for wireless links. Right. I think that single retransmission is a nice implementation = strategy for some applications, so we should continue to pay attention = that we don=E2=80=99t inadvertently make it harder to do than it is now. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Oct 21 14:50:15 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A681209AF for ; Mon, 21 Oct 2019 14:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 NeMpNUVSB9lu for ; Mon, 21 Oct 2019 14:50:10 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E96A12001A for ; Mon, 21 Oct 2019 14:50:10 -0700 (PDT) Received: from client-0142.vpn.uni-bremen.de (client-0142.vpn.uni-bremen.de [134.102.107.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46xr0J3dlkzyVy; Mon, 21 Oct 2019 23:50:08 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Mon, 21 Oct 2019 23:50:07 +0200 Cc: "loops@ietf.org" X-Mao-Original-Outgoing-Id: 593387405.926187-e4eddc81c8cbfa5304f1725084db6baf Content-Transfer-Encoding: quoted-printable Message-Id: <09377EEF-700C-4A91-B1EB-8008A713BE23@tzi.org> References: <85A3D130-43C8-4D89-B45B-75632331C5DF@tzi.org> To: "Zhouxingwang (Joe)" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [LOOPS] Timestamps and delay measurements X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2019 21:50:13 -0000 On Oct 21, 2019, at 08:48, Zhouxingwang (Joe) = wrote: >=20 > About the random VMs, some public cloud provider does not provide the = synchronized time for their VMs by default, and the time difference = between the VMs changes a little (found a 3750ms variation for like 40 = hours roughly). That is a lot! I=E2=80=99m assuming that we want to measure one-way = delay at a precision of about a 10th of the actual delay; so the target = precision would often be in the single-digit ms range. While a drift of = 100 ms/h can probably still be adjusted by an adaptive algorithm, = absolute measurements are not meaningful in such a situation (and we = don=E2=80=99t know whether the 3750 ms total you saw doesn=E2=80=99t = include wilder oscillations or even jumps). So the one-way measurement afforded by the return of an absolute = reception time may only be useful if both ingress and egress have = qualified clocks. We could make it optional, controlled by setup = information. Relying on two-way RTT measurements for congestion = detection is less accurate, but doesn=E2=80=99t incur uncertainties from = bad clocks. > And for the cached timestamp, it will be a problem if LOOPS is = implemented in high speed and memory limited device, like physical = switch or router. Let me try to get some quantitative feel about the cost of measurements. First question is what bit rates are we going to try to achieve. Doing LOOPS at 100 Gbit/s is interesting because of the buffer space = needed to retransmit. It seems to me that a 100 Mbit/s LOOPS tunnel is already at the high end = of what many people want to do with LOOPS today, but I=E2=80=99m willing = to be surprised. Second, what packet rates we are looking at. A rule of thumb for a while has been that the average packet size on the = Internet is about 300 bytes; I=E2=80=99m sure that figure has been = growing (in theory it should be 1000 bytes with an MTU of 1500 bytes and = two full-size TCP data packets for one 40-byte ACK, which actually works = out for elephant flows [3]; a university had ~870 bytes in 2015 [4]). = CAIDA measured ~420 bytes in 2000 [1]. Cisco rated performance figures = based on 445 or 595 bytes in 2003 [2]. Is there something like an = accepted rule of thumb? I=E2=80=99ll assume a rounded 10000/3 bits for = the below. For a 100 Mbit/s LOOPS tunnel, we get 30000 packets per second. At a = one-way delay of 10 ms (2000 km of fiber one way), this means some 300 = packets may be in flight at any one time. Doing a measurement three = times per one-way delay is probably already quite good, so we would only = sample 1/100 of the packets, or 300/s. Note that all packets already = have to be stored in their entirety so the ingress can retransmit; a = 4-byte timestamp is ~ 1/100 of the packet size so in terms of memory the = storage need for ingress timestamps becomes 1/10000 of the buffer space. = Of course, there may be different kinds of memory in use. In any case, there is little problem in allowing optional small data in = the forward information that is to be echoed back in a block 1 = acknowledgement; we wouldn=E2=80=99t even have to specifically dedicate = these bits as a timestamp (we wouldn=E2=80=99t want to dictate the = specific format for an echoed timestamp anyway); there may also be some = use of echoed bits as a mitigation against blind attacks. Gr=C3=BC=C3=9Fe, Carsten [1]: http://www.caida.org/research/traffic-analysis/AIX/plen_hist/ [2]: = https://www.sciencedirect.com/topics/computer-science/average-packet-size [3]: https://hal.inria.fr/hal-01497035/document [4]: https://arxiv.org/pdf/1809.03486.pdf From nobody Mon Oct 21 23:18:19 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4261120B03 for ; Mon, 21 Oct 2019 23:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 BnNvwzlJkNxj for ; Mon, 21 Oct 2019 23:18:15 -0700 (PDT) Received: from mailout-taastrup.gigahost.dk (mailout-taastrup.gigahost.dk [46.183.139.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2769120B04 for ; Mon, 21 Oct 2019 23:18:15 -0700 (PDT) Received: from mailout.gigahost.dk (mailout.gigahost.dk [89.186.169.112]) by mailout-taastrup.gigahost.dk (Postfix) with ESMTP id 8FBA01891FA2 for ; Tue, 22 Oct 2019 06:18:05 +0000 (UTC) Received: from smtp.gigahost.dk (smtp.gigahost.dk [89.186.169.109]) by mailout.gigahost.dk (Postfix) with ESMTP id C8CFA78320E for ; Tue, 22 Oct 2019 06:18:11 +0000 (UTC) Received: by smtp.gigahost.dk (Postfix, from userid 1000) id 55DB92721A80; Tue, 22 Oct 2019 06:18:05 +0000 (UTC) X-Screener-Id: f8b5956341cafa01bc0fc2c7b7d4a245e1dff3de Received: from [192.168.87.113] (unknown [85.218.152.21]) by smtp.gigahost.dk (Postfix) with ESMTPSA id 191472721A0E for ; Tue, 22 Oct 2019 06:18:05 +0000 (UTC) To: loops@ietf.org References: <289BCF98-9F51-4E22-B8E2-50E17C1E8644@tzi.org> <3B1DB1C6-9E23-47C2-B7FA-A41079BF1490@ifi.uio.no> <72B131DC-5255-4310-A148-15BC7A5698D1@tzi.org> From: "Morten V. Pedersen" Message-ID: Date: Tue, 22 Oct 2019 08:18:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <72B131DC-5255-4310-A148-15BC7A5698D1@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [LOOPS] Packet sequence numbers X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2019 06:18:18 -0000 Hi all, I'm not an expert on QUIC or such, but what was the motivation for continuously increasing sequence numbers there. I imagine they had some good reasons to go down that path. From a FEC and re-transmission standpoint continuously increasing sequence numbers yields simpler implementations from my point of view. It is relatively easy for the FEC implementation to estimate the packet loss, and for a pure re-transmission scheme detection of "holes" is trivial without worrying about what data the packet carried i.e. if it was payload data or a re-transmission in itself. It can just report back and say I did not get packet X whatever it was. All the best, Morten On 10/21/19 10:45 PM, Carsten Bormann wrote: >> Even though I originally suggested the QUIC method of continuously increasing sequence numbers, I think this assessment of the trade-offs is very good, and now I tend to agree that, for LOOPS, repeating sequence numbers would be better. > I think that this conclusion is a good basis for continuing the work. > I made the necessary changes (I think) in https://github.com/loops-wg/gen-info/commit/2dd7634 > > I also added some text about mitigating ACK ambiguity, which is facilitated if the ingress never sets “ACK desired” on a retransmission. > > There is currently no detailed text on how to decide to retransmit. The current spec is mute (a.k.a. “flexible”) on the implementation strategy. For hole-based retransmission triggering, re-using the PSD needs to include a hold-off for packets that have recently been retransmitted so another copy of block 2 information that just confirms the existing hole doesn’t trigger another retransmission. For a time-based retransmission scheme (as in RACK), retransmission would simply move forward the packet into the then appropriate slot. > >> +1 on the need for more-than-once, for wireless links. > Right. I think that single retransmission is a nice implementation strategy for some applications, so we should continue to pay attention that we don’t inadvertently make it harder to do than it is now. > > Grüße, Carsten > From nobody Tue Oct 22 00:07:24 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED87F12002F for ; Tue, 22 Oct 2019 00:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 vcz0OfMG0pTv for ; Tue, 22 Oct 2019 00:07:20 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 5E707120B0D for ; Tue, 22 Oct 2019 00:07:20 -0700 (PDT) Received: from mail-mx10.uio.no ([129.240.10.27]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1iMoGD-000CCK-V8; Tue, 22 Oct 2019 09:07:17 +0200 Received: from ti0182q160-2022.bb.online.no ([212.251.170.252] helo=[10.0.0.10]) by mail-mx10.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.92.3) (envelope-from ) id 1iMoGD-0003Bo-7y; Tue, 22 Oct 2019 09:07:17 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Michael Welzl In-Reply-To: Date: Tue, 22 Oct 2019 09:07:16 +0200 Cc: loops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <289BCF98-9F51-4E22-B8E2-50E17C1E8644@tzi.org> <3B1DB1C6-9E23-47C2-B7FA-A41079BF1490@ifi.uio.no> <72B131DC-5255-4310-A148-15BC7A5698D1@tzi.org> To: "Morten V. Pedersen" X-Mailer: Apple Mail (2.3445.104.11) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx10.uio.no: 212.251.170.252 is neither permitted nor denied by domain of ifi.uio.no) client-ip=212.251.170.252; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.10]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: F6628A8B1845359CDAA52255F5D771F7F2CA6C05 Archived-At: Subject: Re: [LOOPS] Packet sequence numbers X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2019 07:07:23 -0000 Hi all, It is my understanding (but I might be wrong!) that the motivation was = just to avoid retransmission ambiguity when there=E2=80=99s no need to = have it - continuously growing sequence numbers make things simpler, and = given the length of the field in QUIC, they would support very long = transfers, so the disadvantage is minuscule. And, indeed, it generally = makes things simpler. One of the disadvantages mentioned here was related to monitoring tools = - that doesn=E2=80=99t apply to QUIC either because its sequence numbers = are encrypted. Cheers, Michael > On Oct 22, 2019, at 8:18 AM, Morten V. Pedersen = wrote: >=20 > Hi all, > I'm not an expert on QUIC or such, but what was the motivation for = continuously increasing sequence numbers there. I imagine they had some = good reasons to go down that path. >=20 > =46rom a FEC and re-transmission standpoint continuously increasing = sequence numbers yields simpler implementations from my point of view. >=20 > It is relatively easy for the FEC implementation to estimate the = packet loss, and for a pure re-transmission scheme detection of "holes" = is trivial without worrying about what data the packet carried i.e. if = it was payload data or a re-transmission in itself. It can just report = back and say I did not get packet X whatever it was. >=20 > All the best, > Morten >=20 >=20 > On 10/21/19 10:45 PM, Carsten Bormann wrote: >>> Even though I originally suggested the QUIC method of continuously = increasing sequence numbers, I think this assessment of the trade-offs = is very good, and now I tend to agree that, for LOOPS, repeating = sequence numbers would be better. >> I think that this conclusion is a good basis for continuing the work. >> I made the necessary changes (I think) in = https://github.com/loops-wg/gen-info/commit/2dd7634 >>=20 >> I also added some text about mitigating ACK ambiguity, which is = facilitated if the ingress never sets =E2=80=9CACK desired=E2=80=9D on a = retransmission. >>=20 >> There is currently no detailed text on how to decide to retransmit. = The current spec is mute (a.k.a. =E2=80=9Cflexible=E2=80=9D) on the = implementation strategy. For hole-based retransmission triggering, = re-using the PSD needs to include a hold-off for packets that have = recently been retransmitted so another copy of block 2 information that = just confirms the existing hole doesn=E2=80=99t trigger another = retransmission. For a time-based retransmission scheme (as in RACK), = retransmission would simply move forward the packet into the then = appropriate slot. >>=20 >>> +1 on the need for more-than-once, for wireless links. >> Right. I think that single retransmission is a nice implementation = strategy for some applications, so we should continue to pay attention = that we don=E2=80=99t inadvertently make it harder to do than it is now. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >=20 > --=20 > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops From nobody Tue Oct 22 02:23:42 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538F4120025 for ; Tue, 22 Oct 2019 02:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 5B3Uo5dcs7lk for ; Tue, 22 Oct 2019 02:23:37 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7CC91200A1 for ; Tue, 22 Oct 2019 02:23:37 -0700 (PDT) Received: from [192.168.217.110] (p5089AE1C.dip0.t-ipconnect.de [80.137.174.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46y7NR6nKxz10D4; Tue, 22 Oct 2019 11:23:35 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Tue, 22 Oct 2019 11:23:35 +0200 Cc: "Morten V. Pedersen" , loops@ietf.org X-Mao-Original-Outgoing-Id: 593429013.860878-34ff73278d48487380e6ce71deb522b0 Content-Transfer-Encoding: quoted-printable Message-Id: References: <289BCF98-9F51-4E22-B8E2-50E17C1E8644@tzi.org> <3B1DB1C6-9E23-47C2-B7FA-A41079BF1490@ifi.uio.no> <72B131DC-5255-4310-A148-15BC7A5698D1@tzi.org> To: Michael Welzl X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [LOOPS] Packet sequence numbers X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2019 09:23:40 -0000 I seem to remember that one other advantage of a strictly monotonous = sequence number is that this makes it directly suitable as input for a = nonce for the AEAD encryption/authentication, saving bytes by not = needing to send one separately. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Oct 22 03:17:40 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B62912008A for ; Tue, 22 Oct 2019 03:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 cLnWjACOwDKc for ; Tue, 22 Oct 2019 03:17:36 -0700 (PDT) Received: from mailout-taastrup.gigahost.dk (mailout-taastrup.gigahost.dk [46.183.139.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98F04120091 for ; Tue, 22 Oct 2019 03:17:36 -0700 (PDT) Received: from mailout.gigahost.dk (mailout.gigahost.dk [89.186.169.112]) by mailout-taastrup.gigahost.dk (Postfix) with ESMTP id 45A821891DD9; Tue, 22 Oct 2019 10:17:27 +0000 (UTC) Received: from smtp.gigahost.dk (smtp.gigahost.dk [89.186.169.109]) by mailout.gigahost.dk (Postfix) with ESMTP id 8286B783211; Tue, 22 Oct 2019 10:17:33 +0000 (UTC) Received: by smtp.gigahost.dk (Postfix, from userid 1000) id 22E572721A0E; Tue, 22 Oct 2019 10:17:27 +0000 (UTC) X-Screener-Id: f8b5956341cafa01bc0fc2c7b7d4a245e1dff3de Received: from [10.10.138.122] (unknown [77.243.63.160]) by smtp.gigahost.dk (Postfix) with ESMTPSA id E134D27219D6; Tue, 22 Oct 2019 10:17:26 +0000 (UTC) To: Carsten Bormann , Michael Welzl Cc: loops@ietf.org References: <289BCF98-9F51-4E22-B8E2-50E17C1E8644@tzi.org> <3B1DB1C6-9E23-47C2-B7FA-A41079BF1490@ifi.uio.no> <72B131DC-5255-4310-A148-15BC7A5698D1@tzi.org> From: "Morten V. Pedersen" Message-ID: <85a27afa-d7ab-6df8-47f7-400f1bc6d051@steinwurf.com> Date: Tue, 22 Oct 2019 12:17:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [LOOPS] Packet sequence numbers X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2019 10:17:38 -0000 Hi Carsten, That's interesting - such a number is also used in some FEC schemes e.g. RLNC to seed the random number generator (used to create coding coefficients). With the same purpose of saving bytes on the wire. - M On 10/22/19 11:23 AM, Carsten Bormann wrote: > I seem to remember that one other advantage of a strictly monotonous sequence number is that this makes it directly suitable as input for a nonce for the AEAD encryption/authentication, saving bytes by not needing to send one separately. > > Grüße, Carsten >