IETF Logo Mail Archive

Re: [LOOPS] Measuring forward latency

"Zhouxingwang (Joe)" <zhouxingwang@huawei.com> Thu, 27 June 2019 02:39 UTC

Return-Path: <zhouxingwang@huawei.com>
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 DC129120130 for <loops@ietfa.amsl.com>; Wed, 26 Jun 2019 19:39:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 EpwhwWbbv4Gq for <loops@ietfa.amsl.com>; Wed, 26 Jun 2019 19:39:29 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 C9E8E120041 for <loops@ietf.org>; Wed, 26 Jun 2019 19:39:28 -0700 (PDT)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 138032CB945B4A9C0C4B; Thu, 27 Jun 2019 03:39:27 +0100 (IST)
Received: from dggeme708-chm.china.huawei.com (10.1.199.104) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 27 Jun 2019 03:39:26 +0100
Received: from dggeme758-chm.china.huawei.com (10.3.19.104) by dggeme708-chm.china.huawei.com (10.1.199.104) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Thu, 27 Jun 2019 10:39:24 +0800
Received: from dggeme758-chm.china.huawei.com ([10.6.80.69]) by dggeme758-chm.china.huawei.com ([10.6.80.69]) with mapi id 15.01.1591.008; Thu, 27 Jun 2019 10:39:24 +0800
From: "Zhouxingwang (Joe)" <zhouxingwang@huawei.com>
To: Carsten Bormann <cabo@tzi.org>, Michael Welzl <michawe@ifi.uio.no>
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>
Thread-Topic: [LOOPS] Measuring forward latency
Thread-Index: AQHVJV33B5QH8c2280y2us4ehkzqwqag1PGAgAADpICADCLUgIAAB2yAgAAkxgCAAZnWcA==
Date: Thu, 27 Jun 2019 02:39:24 +0000
Message-ID: <ce78a13b23984e1eb6a7a96bd891b44f@huawei.com>
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>
In-Reply-To: <45F6651A-A39E-4A98-9C16-B7314AE37D51@tzi.org>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.134.27.230]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/loops/NWW_tQdLxv-t_thUGlbATrb-hXQ>
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: Thu, 27 Jun 2019 02:39:31 -0000

Hi,

Generally speaking, maintaining per-flow state in a network node is a heavy solution.
But for this scenario,  the LOOPS node does not need to maintain the state for every flow all the time, the ingress node can start to maintain the state of the flows only for the retransmission packets, then the number of the flows should be much smaller than the total number of flows, based on this, ingress node may make sure every loss-affected flow has one loss event for every RTT.

Thanks
Joe

-----Original Message-----
From: LOOPS [mailto:loops-bounces@ietf.org] On Behalf Of Carsten Bormann
Sent: Wednesday, June 26, 2019 4:51 PM
To: Michael Welzl <michawe@ifi.uio.no>
Cc: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>; Cociglio Mauro <mauro.cociglio@telecomitalia.it>; loops@ietf.org; Brian Trammell (IETF) <ietf@trammell.ch>
Subject: Re: [LOOPS] Measuring forward latency

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

-- 
LOOPS mailing list
LOOPS@ietf.org
https://www.ietf.org/mailman/listinfo/loops

v2.23.0 | Report a Bug | By Email