IETF Logo Mail Archive

Re: [LOOPS] Measuring forward latency

Carsten Bormann <cabo@tzi.org> Wed, 26 June 2019 08:50 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 06B5212010E for <loops@ietfa.amsl.com>; Wed, 26 Jun 2019 01:50:43 -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 YUmqqU1XcL51 for <loops@ietfa.amsl.com>; Wed, 26 Jun 2019 01:50:41 -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 5B24F120043 for <loops@ietf.org>; Wed, 26 Jun 2019 01:50:41 -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 45YcDt5ms9zyW7; Wed, 26 Jun 2019 10:50:38 +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: <7A59934F-9143-4048-950F-02E1D7E7C795@ifi.uio.no>
Date: Wed, 26 Jun 2019 10:50:38 +0200
Cc: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Cociglio Mauro <mauro.cociglio@telecomitalia.it>, "loops@ietf.org" <loops@ietf.org>, "Brian Trammell (IETF)" <ietf@trammell.ch>
X-Mao-Original-Outgoing-Id: 583231836.690906-9b3c705cb345bb56ae69fe3e970128ab
Content-Transfer-Encoding: quoted-printable
Message-Id: <45F6651A-A39E-4A98-9C16-B7314AE37D51@tzi.org>
References: <F64CD006-3F60-4D63-B97D-0251A7B7F0B0@tzi.org> <E92F9C7E59A8854E8BED73140B879B4E012C1D1D@lhreml507-mbs> <8033CD47-410C-4C04-B4E1-F70EBC2B92C3@ifi.uio.no> <0D13F099-6EC3-427F-A2A2-BED45E781766@tzi.org> <7A59934F-9143-4048-950F-02E1D7E7C795@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/hg9INPyRaL3p1Avx8O808sOyxzo>
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 08:50:43 -0000

On Jun 26, 2019, at 08:39, Michael Welzl <michawe@ifi.uio.no> wrote:
> 
>> 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.
> 
> I agree with all that. Just a side question: what makes you say “non-ECT transports”?  How is this different for ECT ones?

Indeed, congestion signaling has to happen for either.
It is just massively simpler for ECT transports, as we can simply hand through loss/CE events in the CE marking.
For non-ECT transports, we don’t want to hand through each loss (there would be no point in recovering them if we then have to drop all of them).
(This requires per-flow state, which definitely should remain optional in a LOOPS implementation.)

Grüße, Carsten

v2.23.0 | Report a Bug | By Email