Re: [ippm] 1st review of RFC 8321bis
Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Wed, 01 December 2021 18:58 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 3F9C63A0980; Wed, 1 Dec 2021 10:58:34 -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 se4JWtO4NVf2; Wed, 1 Dec 2021 10:58:29 -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 8F88A3A097E; Wed, 1 Dec 2021 10:58:29 -0800 (PST)
Received: from fraeml713-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4J47cC4CBrz6824j; Thu, 2 Dec 2021 02:56:59 +0800 (CST)
Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml713-chm.china.huawei.com (10.206.15.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Wed, 1 Dec 2021 19:58:25 +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; Wed, 1 Dec 2021 19:58:25 +0100
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: Martin Duke <martin.h.duke@gmail.com>, "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: AQHX5jeFafny0q1BtU2vvHQD5nUPfqwd3hjg
Date: Wed, 01 Dec 2021 18:58:25 +0000
Message-ID: <d239e6d3a8c84cf780e3c882eddb68dc@huawei.com>
References: <CAM4esxQpsFv4SgE0nfecrtOe=DQbNFYFVMjE-OE+MZvxJ5iH6w@mail.gmail.com>
In-Reply-To: <CAM4esxQpsFv4SgE0nfecrtOe=DQbNFYFVMjE-OE+MZvxJ5iH6w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.48.219.166]
Content-Type: multipart/alternative; boundary="_000_d239e6d3a8c84cf780e3c882eddb68dchuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/wPybnFINOOuw_RwhiC_xvtA-0zw>
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: Wed, 01 Dec 2021 18:58:34 -0000
Hi Martin, Thanks a lot for your thorough review. I also agree that for a later version a reorganization of the content can improve the readability. Regarding your comments, please find my answers inline tagged as [GF]. Best Regards, Giuseppe From: Martin Duke <martin.h.duke@gmail.com> Sent: Tuesday, November 30, 2021 11:13 PM To: draft-fioccola-rfc8321bis.all@ietf.org; IETF IPPM WG <ippm@ietf.org> Subject: 1st review of RFC 8321bis Hello authors, I've read through this document carefully for the first time. Having done so, I fully support later doing the reorganization that you've proposed. The current draft presents the information in a strange order. I have no serious issues with the changes from 8321, but I have numerous comments on the 8321 text that ought to be fixed before we take it to Standard. MAJOR COMMENTS: - Why is RFC3393 normative if the other packet definition documents (7679, 7680) are informative? IMO they are all informative, but it should at least be consistent. [GF]: It was my oversight, I will fix it in the next version. In RFC8321, all these RFCs were normative but now can be informative. - Sec 1. Can you clarify the relationship of this draft with [IEEE-Network-PNPM]? Do they repeat each other, or does that one make a different contribution to this project? If the former, who has change control over the design? [GF]: It is not a repetition. The paper [IEEE-Network-PNPM] includes RFC8321 methods but it also explains new mechanisms for the packet marking based on hashing techniques, which are not included in RFC8321. These new variations are described in a separate document (draft-mizrahi-ippm-marking). I can also omit the reference if you think it can be confusing. - 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? - 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 - sec 3.3.1 "a measurement is valid only if no packet loss occurs and if packet misordering can be avoided". So what it's not? Do we throw out the measurement? How can we detect packet misordering unless it delays a packet over the edge? [GF]: This approach is affected by the packet reordering that we cannot detect. You can apply it but you are aware that the first packet of the batch in one point may not be the same packet in a second point due to the reordering. In this case you are not sure to compare the same packet and the delay measure is done with this intrinsic error. I can explain this point in the next version. - Sec 3.3.2 "The conventional [delay] range (maximum-minimum) should be avoided". I don't know how to reconcile this with the guard band calculation, which absolutely uses the range! Is this a valid thing to do or not? [GF]: In this case I did not mean the delay of the network to calculate the guard band, but I meant the delay you are measuring. I think I can also omit this sentence, it is not important. - Section 4. This entire section is largely a subset of section 3, and covers the material both (a) inconsistently and (b) worse. There's a reference to "two-way delay" which occurs nowhere else in the document. The L considerations don't consider delay, unlike Section 3.2. 4.3 says that "a proper interval is out off the scope of this document!" But the document has lots to say about this! Earlier discussions led me to believe you were going to largely get rid of Section 4; perhaps as an intermediate step, in the next draft could we delete the text in that section that no longer applies? [GF]: Yes, indeed I modified a lot this section in my first local revision of the document. As intermediate step, I will surely delete text that no longer applies in the next version. - Section 8. The most potent attack on this would appear to be on the data collection protocol, which is out of scope. It might be good to point the reader to some references that discuss security considerations for gathering data. [GF]: Agree, will do. I also think we have improved a lot the security considerations in draft-ietf-6man-ipv6-alt-mark and we can inherit something from there as well. NITS: Is there a github? There are numerous editorial cleanup issues that would be much easier to do if I could just submit a PR. [GF]: It is a possibility. I could also share the xml file if it works for you. - Abstract: delete the phrase "a method based on" - Sec 1. s/On the other hand, performance/Performance also - Sec 3.1 s/packet loss occurred/if packet loss occurred - Sec 3.1.1 "some applications" are no longer "reported in section 5." Delete the sentence. - Sec 3.1.2 s/a couple of counters are needed/two counters are needed - Sec 3.3.1.1 s/implicates/implies - Update references from RFC8889 to RFC8889bis. [GF]: I will apply all these minor changes in the next version.
- [ippm] 1st review of RFC 8321bis Martin Duke
- Re: [ippm] 1st review of RFC 8321bis Giuseppe Fioccola
- Re: [ippm] 1st review of RFC 8321bis Martin Duke
- Re: [ippm] 1st review of RFC 8321bis Giuseppe Fioccola
- Re: [ippm] 1st review of RFC 8321bis Martin Duke
- Re: [ippm] 1st review of RFC 8321bis Giuseppe Fioccola