Re: [LOOPS] Packet sequence numbers

Michael Welzl <michawe@ifi.uio.no> Fri, 18 October 2019 09:59 UTC

Return-Path: <michawe@ifi.uio.no>
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 <loops@ietfa.amsl.com>; 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 <loops@ietfa.amsl.com>; 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 <loops@ietf.org>; 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 <michawe@ifi.uio.no>) 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 <michawe@ifi.uio.no>) 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 <michawe@ifi.uio.no>
In-Reply-To: <D408889639FC5E4FADB4E00A3E01FA8FC6093104@nkgeml513-mbx.china.huawei.com>
Date: Fri, 18 Oct 2019 11:59:05 +0200
Cc: Carsten Bormann <cabo@tzi.org>, "loops@ietf.org" <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> <D408889639FC5E4FADB4E00A3E01FA8FC6093104@nkgeml513-mbx.china.huawei.com>
To: Liyizhou <liyizhou@huawei.com>
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: <https://mailarchive.ietf.org/arch/msg/loops/UTmjWi11XofU14Ae4jdPom1uudE>
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 <loops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/loops>, <mailto:loops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/loops/>
List-Post: <mailto:loops@ietf.org>
List-Help: <mailto:loops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/loops>, <mailto:loops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Oct 2019 09:59:23 -0000

Hi,

> On Oct 17, 2019, at 2:27 PM, Liyizhou <liyizhou@huawei.com> wrote:
> 
> Hi Carsten,
> 
> For packet sequence number (PSN) in a retransmit packet, using the old PSN looks more reasonable to me.
> 
> 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.
> 
> 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. 
> 
> 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.  

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