Re: [LOOPS] Measuring forward latency

Carsten Bormann <cabo@tzi.org> Wed, 26 June 2019 06:12 UTC

Return-Path: <cabo@tzi.org>
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 605D9120096 for <loops@ietfa.amsl.com>; Tue, 25 Jun 2019 23:12:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 MWaaa8agvfJT for <loops@ietfa.amsl.com>; Tue, 25 Jun 2019 23:12:30 -0700 (PDT)
Received: from smtp.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 1B30E120122 for <loops@ietf.org>; Tue, 25 Jun 2019 23:12:30 -0700 (PDT)
Received: from [192.168.217.110] (p54A6CA4C.dip0.t-ipconnect.de [84.166.202.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45YXkN2QfSzygP; Wed, 26 Jun 2019 08:12:28 +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 <cabo@tzi.org>
In-Reply-To: <8033CD47-410C-4C04-B4E1-F70EBC2B92C3@ifi.uio.no>
Date: Wed, 26 Jun 2019 08:12:27 +0200
Cc: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, "loops@ietf.org" <loops@ietf.org>, Cociglio Mauro <mauro.cociglio@telecomitalia.it>, "Brian Trammell (IETF)" <ietf@trammell.ch>
X-Mao-Original-Outgoing-Id: 583222345.9755009-18d7ec7c009535603c4008f314da2a3c
Content-Transfer-Encoding: quoted-printable
Message-Id: <0D13F099-6EC3-427F-A2A2-BED45E781766@tzi.org>
References: <F64CD006-3F60-4D63-B97D-0251A7B7F0B0@tzi.org> <E92F9C7E59A8854E8BED73140B879B4E012C1D1D@lhreml507-mbs> <8033CD47-410C-4C04-B4E1-F70EBC2B92C3@ifi.uio.no>
To: Michael Welzl <michawe@ifi.uio.no>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/loops/xYWUZV47v2u8VHR5uGeP6mw0ILw>
Subject: Re: [LOOPS] Measuring forward latency
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: Wed, 26 Jun 2019 06:12:32 -0000

On Jun 18, 2019, at 14:52, Michael Welzl <michawe@ifi.uio.no> wrote:
> 
> I thought the spin bit is meant for a router somewhere along the path to understand the end-to-end RTT of a flow.
> We, on the other hand, need a LOOPS ingress node to understand the RTT (or, better, OWD) to the LOOPS egress node. So this is (LOOPS-)end-to-(LOOPS)-end.

We need a number of measurements, and an implementation could also make use of additional measurements.  If a measurement for the end-to-end RTT is available for a flow, it can be used to properly dose congestion event signaling for non-ECT flows in the way described at the end of Section 2.4 of gen-info [1].  It may also be useful to derive an upper limit for the timing of retransmissions (and the latency variance these will introduce).

But I would argue that getting that end-to-end RTT measurement is not a function of LOOPS — it is a function that implementations could provide to improve the LOOPS function of congestion signaling.  (Besides, that measurement is per-flow, not a per-tunnel wholesale measurement.)

As Yizhou listed [2], we need a number of different per-tunnel measurements, and we need them to be available for different functions of the LOOPS protocol.  Specifically:

— per-tunnel RTT, to time retransmissions
— per-tunnel one-way latency, to detect congestion and sort congestion from non-congestion losses
— per-tunnel loss rate (and other statistical properties of the loss), for parameterizing FEC

These differ in how they can be achieved, where the data is produced and where it is needed, and that should guide the design.  E.g., moving the timestamps into the forward information makes latency variation immediately available at the egress, which is also the place where the congestion signaling to non-ECT transports will need to happen.

Grüße, Carsten


[1]: https://tools.ietf.org/html/draft-welzl-loops-gen-info-00#section-2.4
[2]: https://mailarchive.ietf.org/arch/msg/loops/P3LdmvVvMeeYUzv-6r9oB91pkvQ