Re: [ippm] 1st review of RFC 8321bis

Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Fri, 03 December 2021 14:03 UTC

Return-Path: <giuseppe.fioccola@huawei.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8C53A09E3; Fri, 3 Dec 2021 06:03:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 BuRedHEK9zIL; Fri, 3 Dec 2021 06:02:56 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 441653A09E2; Fri, 3 Dec 2021 06:02:56 -0800 (PST)
Received: from fraeml708-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4J5Dyr3QGxz67Ys9; Fri, 3 Dec 2021 22:01:56 +0800 (CST)
Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml708-chm.china.huawei.com (10.206.15.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Fri, 3 Dec 2021 15:02:51 +0100
Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.2308.020; Fri, 3 Dec 2021 15:02:52 +0100
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: Martin Duke <martin.h.duke@gmail.com>
CC: "draft-fioccola-rfc8321bis.all@ietf.org" <draft-fioccola-rfc8321bis.all@ietf.org>, IETF IPPM WG <ippm@ietf.org>
Thread-Topic: 1st review of RFC 8321bis
Thread-Index: AQHX5jeFafny0q1BtU2vvHQD5nUPfqwd3hjggABMAYCAAMrK8IAAhngAgAFT2jA=
Date: Fri, 03 Dec 2021 14:02:51 +0000
Message-ID: <7edf4468040446d0baa591f2b38ce99f@huawei.com>
References: <CAM4esxQpsFv4SgE0nfecrtOe=DQbNFYFVMjE-OE+MZvxJ5iH6w@mail.gmail.com> <d239e6d3a8c84cf780e3c882eddb68dc@huawei.com> <CAM4esxSMDBfGVxKhucK3HUHWOYCvc76dwJhPe_p0oyAAksOG9Q@mail.gmail.com> <1cfecebe84124cb5a22a370d6d5125fd@huawei.com> <CAM4esxTcoXVZQaH71Ou0KiKuui44yqZ5rpgYh_kARTve9NHLrg@mail.gmail.com>
In-Reply-To: <CAM4esxTcoXVZQaH71Ou0KiKuui44yqZ5rpgYh_kARTve9NHLrg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.48.214.16]
Content-Type: multipart/alternative; boundary="_000_7edf4468040446d0baa591f2b38ce99fhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/rJ6yJTTsiSDLtV5KYqlkLPcQKTs>
Subject: Re: [ippm] 1st review of RFC 8321bis
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Dec 2021 14:03:02 -0000

Hi Martin,
Ok, I will update this draft soon to address all the agreed changes.

Regards,

Giuseppe

From: Martin Duke <martin.h.duke@gmail.com>
Sent: Thursday, December 2, 2021 7:42 PM
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
Cc: draft-fioccola-rfc8321bis.all@ietf.org; IETF IPPM WG <ippm@ietf.org>
Subject: Re: 1st review of RFC 8321bis



On Thu, Dec 2, 2021 at 2:19 AM Giuseppe Fioccola <giuseppe.fioccola@huawei.com<mailto:giuseppe.fioccola@huawei.com>> wrote:
Hi Martin,
My answers inline as [GF].

Regards,

Giuseppe

From: Martin Duke <martin.h.duke@gmail.com<mailto:martin.h.duke@gmail.com>>
Sent: Wednesday, December 1, 2021 11:35 PM
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com<mailto:giuseppe.fioccola@huawei.com>>
Cc: draft-fioccola-rfc8321bis.all@ietf.org<mailto:draft-fioccola-rfc8321bis.all@ietf.org>; IETF IPPM WG <ippm@ietf.org<mailto:ippm@ietf.org>>
Subject: Re: 1st review of RFC 8321bis



On Wed, Dec 1, 2021 at 10:58 AM Giuseppe Fioccola <giuseppe.fioccola@huawei.com<mailto:giuseppe.fioccola@huawei.com>> wrote:
From: Martin Duke <martin.h.duke@gmail.com<mailto:martin.h.duke@gmail.com>>

- I'm concerned about sizing the block based on packet count. It's clearly your less-preferred option, but including it has some implications. For example, passive eavesdropping is much easier, as it would be straightforward to figure out the expected number of packets and therefore figure out the loss rate. If this wasn't a successful part of the experiment, perhaps we should just remove it.

[GF]: Yes, we could remove it in the PS. But, it is worth noting that draft-ietf-ippm-explicit-flow-measurements suggests a marking method (sQuare bit) based on a fixed number of packets to measure packet loss. It is simpler for Client-Server protocols like QUIC. Another option could be to leave the description of the counter-based method but we should improve the security considerations for this aspect. What do you suggest?

I'm not a practitioner, so I can't say if it's valuable to leave it in the design or not. But the rest of the document (and 8889) is written under the assumption that the blocks are time based. For example, if it's count-based then L needs to be in units of packets, not time. How would that work?

So if we're going to keep packet-based windows in the draft, you either need to review the whole document and in each place add a paragraph that starts "if using packet-based windows...", or there could be a section that enumerates all the ways this mode is different.

[GF]: I would only consider the assumption that the blocks are time based. The count based method can be mentioned only in the general description as additional possibility but we can clarify that its detailed specification is out of scope here.


Moving count-based blocks out of scope sounds like a good solution.


- sec 3.2.The guard band calculation does not seem correct to me. If D_max -> D_min, then the guard band is simply A. But the ingress and egress nodes still need to account for the packet delay from end to end! I would suggest

d = A + D_max.

This would also cover the reordering constraint, as the delay can be no more than Dmax.

[GF]: If D_max becomes equal to D_min, this means that all the packets are delayed of the same value. So the batch of packets is simply shifted and no packet is reordered. But, you are right we still need to take into account the delay. Maybe we could consider the average delay value and its standard deviation in the formula:

d = A + D_avg + D_stddev

I don't understand what that formula accomplishes. Dmax absolutely covers reordering; regardless of reordering, the rightmost packet will not arrive later than (tx_time + A + D_max).

[GF]: I forgot the multiplier. For a data set, most observations fall within one standard deviation of the average. In particular, 68% of the samples are within 1 standard deviation of the average. 95% of the samples are within 2 standard deviation of the average. 99.7% of the samples are within 3 standard deviation of the mean.
It means that D_avg + 3*D_stddev -> D_max
By the way, to make it simple we can also simply consider D_max in the formula.

OK, either D_max or D_avg + 3D_stddev is fine. I agree that your formulation is superior if you're basing it off measurements.

Martin