Subject: [ippm] Magnus Westerlund's Discuss on draft-ietf-ippm-initial-registry-14: (with DISCUSS and COMMENT)

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Thu, 05 Dec 2019 02:10:37 -0800

Magnus Westerlund has entered the following ballot position for
draft-ietf-ippm-initial-registry-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-initial-registry/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I think these entries shows well how the registry is intended to extended and
the benefit in being clear on what information is needed. I do have a question
that I think needs an answer:

Regarding Section 4.2.2:

   o  IPv6 header values:

      *  DSCP: set to 0

      *  Hop Count: set to 255

      *  Protocol: Set to 17 (UDP)

Does anything about the IPv6 flow ID need to be stated here? As this is a path
delay measurement, the value of the flow ID field has the potential to change
the result. If one would use a new random value for each individual measurement
in a sequence one may see different results than from using the same ID for all
the measurements. Or is this specified in any of the references? In most case I
would expect one use a single value, but likely randomly selected. However, it
does depend on what purpose of ones measurement one have, thus I think this do
matter.

I think this question applies to all measurements that are multi-packet ones so
section 5, 7, 8 and 9 most definitely.

I also wonder if IPv6 Flow ID is an output parameter that needs to be kept?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 4.2.2:

   o  UDP header values:

      *  Checksum: the checksum MUST be calculated and included in the
         header

I guess this implies that a non-zero UDP checksum is to be used. Maybe one
could make this water tight by changing it to:

      *  Checksum: the checksum MUST be calculated and the non-zero checksum
           included in the header

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 5 Dec 2019 12:40:47 +0000

Hi Magnus,

Thanks for your comments, please see replies below marked [acm].
Al

> -----Original Message-----
> From: Magnus Westerlund via Datatracker [mailto:[email-masked]]
> Sent: Thursday, December 5, 2019 5:11 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Brian Trammell
> <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
> Subject: Magnus Westerlund's Discuss on draft-ietf-ippm-initial-registry-
> 14: (with DISCUSS and COMMENT)
> 
> Please refer to https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwICaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=uNaAzNBelBC04Qac3yQQCJ11LaNV2
> SuyWN5R8ZfPgWs&s=fcCttJoylEoEFNiuv2oiUa1D_T5DnIWXkdAzSs7vAUc&e=
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2Dinitial-
> 2Dregistry_&d=DwICaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=uNaAzNBelBC04Qac3yQQCJ11LaNV2
> SuyWN5R8ZfPgWs&s=j46jEwl8h5Dqgs2uCQGiqN48ZyUWfY-nl2wvSWsJHXM&e=
> 
> 
> 
> does depend on what purpose of ones measurement one have, thus I think
> this do matter.
> 
> I think this question applies to all measurements that are multi-packet
>
[acm] 
Please see the e-mail exchange on  
Éric Vyncke's DISCUSS (cleared)  
(now listed as a Comment to keep it in the record)
where he raised identical issues, and we quickly 
proposed solutions for the working version of the text.

[acm] 
Thanks, we will lock this down in the working text.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 5 Dec 2019 13:14:33 +0000

Hi Al,

> (now listed as a Comment to keep it in the record) where he raised identical
> issues, and we quickly proposed solutions for the working version of the
> text.
> 

So clarifying that one is to set flow ID to zero and not use any next headers for this specific metrics likely work in most cases. 

Do you agree that a measurement with varying flow ID or source ports over a measurement would be a different measurement that would then measure over the full set of potential paths that ECMP and similar mechanism may produce based on a specific set of source and destination IP address pair? 

Which measurements registrations are you implementing these changes into? 

Have we now created a situation where the text in the registry becomes crucial for correctly doing a measurement? Or was that already the case prior to this change? What I mean is that the references do not define the metric to the detail level and consistency that the IANA registry does.

Cheers

Magnus

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 5 Dec 2019 13:24:15 +0000

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Thursday, December 5, 2019 8:15 AM
> To: MORTON, ALFRED C (AL) <[email-masked]>; [email-masked]
> Cc: [email-masked]; [email-masked]; ippm-
> [email-masked]; [email-masked]
> Subject: RE: Magnus Westerlund's Discuss on draft-ietf-ippm-initial-
> registry-14: (with DISCUSS and COMMENT)
> 
> Hi Al,
> 
> > [acm]
> So clarifying that one is to set flow ID to zero and not use any next
> headers for this specific metrics likely work in most cases.
> 
> Do you agree that a measurement with varying flow ID or source ports over
> a measurement would be a different measurement that would then measure
> over the full set of potential paths that ECMP and similar mechanism may
> produce based on a specific set of source and destination IP address pair?
[acm] 
Yes, very much so.

> Which measurements registrations are you implementing these changes into?
[acm] 
Almost all of them, I believe ICMP Echo-Request Echo-Reply 
was a special case.

> 
> Have we now created a situation where the text in the registry becomes
> crucial for correctly doing a measurement? 
[acm] 
No

> Or was that already the case
> prior to this change? What I mean is that the references do not define the
> metric to the detail level and consistency that the IANA registry does.
[acm] 
Your DISCUSS and Comment is on the Initial registry entries draft, 
and will apply to the registered metrics.  
I don't see a cross-reference problem here,
unless I am mistaken.

Al