Re: [ippm] 1st review of RFC 8321bis
Martin Duke <martin.h.duke@gmail.com> Wed, 01 December 2021 22:35 UTC
Return-Path: <martin.h.duke@gmail.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 41E7E3A0C95; Wed, 1 Dec 2021 14:35:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 7Br4MZ4aReai; Wed, 1 Dec 2021 14:35:02 -0800 (PST)
Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 656B53A0C3D; Wed, 1 Dec 2021 14:35:02 -0800 (PST)
Received: by mail-ua1-x935.google.com with SMTP id n6so52318835uak.1; Wed, 01 Dec 2021 14:35:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A/b2B2aaNlcah+SJvxwWVr0PUvv1Om6HghfeDOIVmSg=; b=Y/rl8dQmj7Ovi7/hfsyeNA+JV3i0oM98PeblpGUxtM2lq2y/4VK7NhAhw8eEsdTS5V IgrcGBfx0sRLxlr46IVVyUw26e4q+J0ClS9fOxUlU29jpb+v8XxN8GoQC8twtI5nqFlR Jbj86qJFvIEVa/Xtzh3fHwhzzl6MhqJMODX8dpeM7tHmFDc7D86U6nqTnZbIdYZWVJmG ijBlm7XGZfra1kgQnxjcgmGGVQ6QTbnbPmh/q7kqL4LEKR/U3f4AEE5sNaQHT7YoZ8Ef Qh/R/FhmXu4ZFxFtjT7iUc0PlwL/h/Amvsnm+SNAD0tAWXFZgKcVsuNchLugl+LgbhlC HdWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=A/b2B2aaNlcah+SJvxwWVr0PUvv1Om6HghfeDOIVmSg=; b=VlOhrvyGW/581d4BkhgWXv2VvqD23moLEznw1eH0DoNojRLE6DUhqGOBPRzlCfU3Qw F0RJ+DS9IXQrg2eHQB1+pPGDKPmRfgM0vXqrEK0NdmpRbig/nfDUtjy5ryS7IQikisX3 ZHE8QPWJhFgLKCjvJNVlC+7/LEUbmI2z9r1My3W2LmKMihIN/53KcGAeElAgTDlcoxQ1 soUGWuj4pAXY1bthCICUavaWGIVXUw+ZLIlBbIaWVd80r76lKxeYlyf2XzMqPRtAYMzi J2PG0UEYHz351wUmc4QxMkKapvRIkSCPzY8rAJG2/yZUBAzm1OuaHyiIPwtt0X/bu324 E4Xg==
X-Gm-Message-State: AOAM532W8jTOScMzq1sUWev8UXSMApg9XI5y63GooOxfuJf46XAwKyoY yN4sv53s0ltQ5td1QAjMqaY72a9/fhgeJyvNm3E=
X-Google-Smtp-Source: ABdhPJwmIcP0Qc+BXzdJNsQuDAnVv0g7P02Jw5LzmPnp//Rg9AsRA9DtFn4V0O8vRY3w+WAHdLh5laTB2uSruSOblr8=
X-Received: by 2002:a67:f950:: with SMTP id u16mr11531771vsq.68.1638398100632; Wed, 01 Dec 2021 14:35:00 -0800 (PST)
MIME-Version: 1.0
References: <CAM4esxQpsFv4SgE0nfecrtOe=DQbNFYFVMjE-OE+MZvxJ5iH6w@mail.gmail.com> <d239e6d3a8c84cf780e3c882eddb68dc@huawei.com>
In-Reply-To: <d239e6d3a8c84cf780e3c882eddb68dc@huawei.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Wed, 01 Dec 2021 14:34:49 -0800
Message-ID: <CAM4esxSMDBfGVxKhucK3HUHWOYCvc76dwJhPe_p0oyAAksOG9Q@mail.gmail.com>
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
Cc: "draft-fioccola-rfc8321bis.all@ietf.org" <draft-fioccola-rfc8321bis.all@ietf.org>, IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c9f99005d21d4820"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/LjW4c2wK5R_AJGUMzRY6UBJrMII>
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 22:35:17 -0000
On Wed, Dec 1, 2021 at 10:58 AM Giuseppe Fioccola < giuseppe.fioccola@huawei.com> wrote: > *From:* Martin Duke <martin.h.duke@gmail.com> > > - 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. > Don't omit it, just explain what the reference is contributing. > - 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. > > > - 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). > > > - 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. > My point is that this is generally undetectable and therefore is part of the intrinsic error in the measurement. Maybe your explanation will indicate this. > > > - 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. > OK > > > - 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. > Yes, I think deleted text is fine before we do the reorg. We'll take the diff between 8321 and the last draft with the old organization and send that with the request for review. The 8889 bis review is coming; there are some points relevant to 8321 as well.
- [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