Re: [LOOPS] Measuring forward latency

Michael Welzl <michawe@ifi.uio.no> Tue, 18 June 2019 12:53 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 C3EC1120047 for <loops@ietfa.amsl.com>; Tue, 18 Jun 2019 05:53:02 -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 xo1IgxrEpz3l for <loops@ietfa.amsl.com>; Tue, 18 Jun 2019 05:52:59 -0700 (PDT)
Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 D23A51200FD for <loops@ietf.org>; Tue, 18 Jun 2019 05:52:58 -0700 (PDT)
Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <michawe@ifi.uio.no>) id 1hdDbS-0003q2-B5; Tue, 18 Jun 2019 14:52:46 +0200
Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx12.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.92) (envelope-from <michawe@ifi.uio.no>) id 1hdDbR-0005tO-E7; Tue, 18 Jun 2019 14:52:46 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <E92F9C7E59A8854E8BED73140B879B4E012C1D1D@lhreml507-mbs>
Date: Tue, 18 Jun 2019 14:52:41 +0200
Cc: Carsten Bormann <cabo@tzi.org>, "loops@ietf.org" <loops@ietf.org>, Cociglio Mauro <mauro.cociglio@telecomitalia.it>, "Brian Trammell (IETF)" <ietf@trammell.ch>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8033CD47-410C-4C04-B4E1-F70EBC2B92C3@ifi.uio.no>
References: <F64CD006-3F60-4D63-B97D-0251A7B7F0B0@tzi.org> <E92F9C7E59A8854E8BED73140B879B4E012C1D1D@lhreml507-mbs>
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no;
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: 2479DBB2EF0F81B8D1CEAF5CF021E7A9DDF1B4B6
Archived-At: <https://mailarchive.ietf.org/arch/msg/loops/HUbqQ9wGNbMax7U0-Dm3wXzuKNI>
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: Tue, 18 Jun 2019 12:53:03 -0000

Hi,

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.

Cheers,
Michael


> On 18 Jun 2019, at 14:39, Giuseppe Fioccola <giuseppe.fioccola@huawei.com> wrote:
> 
> Dear Carsten, All,
> I think it would be very useful to do a classification of the possible measurement methods for LOOPS.
> And, there are Pros and Cons to be considered for each methodologies.
> In addition to the methodologies already on the table (TCP-like mechanisms, one-way forward latency mechanism and so on...) I would suggest to consider also the so called spin bit approach as described in the following drafts: https://tools.ietf.org/html/draft-trammell-ippm-spin-00 and https://tools.ietf.org/html/draft-cfb-ippm-spinbit-new-measurements-00.
> The main difference is that the spin bit is a resource conserving mechanism since there is no timestamp processing and no timestamp on the wire, the RTT is given by the duration of the spin period. But it can only do measurements once for every RTT.
> What do you think?
> 
> Best Regards,
> 
> Giuseppe
> 
> 
> -----Original Message-----
> From: LOOPS [mailto:loops-bounces@ietf.org] On Behalf Of Carsten Bormann
> Sent: Tuesday, June 18, 2019 12:42 AM
> To: loops@ietf.org
> Subject: [LOOPS] Measuring forward latency
> 
> The proposal in
> 
> https://tools.ietf.org/html/draft-welzl-loops-gen-info
> 
> measures forward latency by having the egress node send back some acknowledgements that carry a timestamp of arrival (expressed in egress node local clock time).  No timing information is conveyed in the forward direction.
> 
> This assumes that the local clock of the egress node is useful for relaying timing information to the ingress node.  In many cases in today’s networks, nodes are synchronized using NTP (or maybe even PTP), so the clocks should not be diverging wildly.  Also, the assumption is that today’s nodes can keep their clock drift in check well enough that the latency measurements are not useless.
> 
> However, there is some systematic error being introduced if the nodes are not perfectly in sync.  This error should be an essentially constant addend (positive or negative) to the measured latency (maybe even leading to mostly negative “latency” measurements, which may seem illogical but may not invalidate the congestion detection math).
> 
> If the latency measurement is mostly used to detect upticks in latency that might be indicative of congestion, all this should not be a big problem.
> 
> Alternative approaches might:
> 
> — need to send more information (essentially running a per-tunnel time synchronization protocol, which is wasteful) — complicate the processing.
> 
> Note that the ingress node has under control how many ACKs with a time stamp it receives, by controlling the rate of setting the “ACK desired” flag; an ingress node that does not care about latency might never set that flag (and rely on cumulative “bitmap” style acknowledgements, called “block 2” in section 4.3).
> 
> So are we happy with the latency measurement approach described in the proposal?
> 
> Note that an ingress node can independently estimate RTT by noting when packets have been sent (in ingress node clock time) and noting the arrival time of an acknowledgement for that packet (if the PSN is different per transmission there is no ambiguity).  The overhead for storing the transmission point in time nearly vanishes behind the storage of the packet itself (which is needed at least in retransmission mode).  This independent RTT measurement is necessary because the path for the reverse information may be rather different from the forward path and also because delayed acknowledgement schemes add to the RTT.
> 
> Does the proposed design look right?
> 
> Grüße, Carsten
> 
> --
> LOOPS mailing list
> LOOPS@ietf.org
> https://www.ietf.org/mailman/listinfo/loops
> -- 
> LOOPS mailing list
> LOOPS@ietf.org
> https://www.ietf.org/mailman/listinfo/loops