IETF Logo Mail Archive

Re: [LOOPS] Measuring forward latency

Michael Welzl <michawe@ifi.uio.no> Wed, 26 June 2019 08:52 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 CB8771201CF for <loops@ietfa.amsl.com>; Wed, 26 Jun 2019 01:52:25 -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 BcfHd3_C9Am8 for <loops@ietfa.amsl.com>; Wed, 26 Jun 2019 01:52:23 -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 5D803120170 for <loops@ietf.org>; Wed, 26 Jun 2019 01:52:23 -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 1hg3f1-0008S5-H4; Wed, 26 Jun 2019 10:52:11 +0200
Received: from ti0182q160-3005.bb.online.no ([62.16.247.223] helo=[10.0.0.2]) 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 1hg3f0-0004my-Q8; Wed, 26 Jun 2019 10:52:11 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <45F6651A-A39E-4A98-9C16-B7314AE37D51@tzi.org>
Date: Wed, 26 Jun 2019 10:52:09 +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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <97809E35-385B-4579-B1CD-9BCD407223C8@ifi.uio.no>
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> <45F6651A-A39E-4A98-9C16-B7314AE37D51@tzi.org>
To: Carsten Bormann <cabo@tzi.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 62.16.247.223 is neither permitted nor denied by domain of ifi.uio.no) client-ip=62.16.247.223; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.2];
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: FFA7A9386596324537062BA93E6F281E6B6A73BC
Archived-At: <https://mailarchive.ietf.org/arch/msg/loops/_Ozgd5yswdCYWpq3cVQ3LABTEUA>
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:52:26 -0000


> On Jun 26, 2019, at 10:50 AM, Carsten Bormann <cabo@tzi.org> wrote:
> 
> 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).

Ahh, sure


> (This requires per-flow state, which definitely should remain optional in a LOOPS implementation.)

Yes. Got it, thanks!

Cheers,
Michael

v2.23.0 | Report a Bug | By Email