Subject: [ippm] WGLC for draft-ietf-ippm-capacity-metric-method

From: Tommy Pauly <[email-masked]>
Date: Fri, 14 Aug 2020 14:21:28 -0700

Hello IPPM,

As discussed at IETF 108, draft-ietf-ippm-capacity-metric-method is stable, and the group felt it is ready for Working Group Last Call.

The latest version can be found here: https://tools.ietf.org/html/draft-ietf-ippm-capacity-metric-method-02 <https://tools.ietf.org/html/draft-ietf-ippm-capacity-metric-method-02>

The last call will end on Wednesday, September 2. Please reply to [email-masked] <mailto:[email-masked]> with your reviews and comments, and indicate if you think the document is ready to progress!

Best,
Tommy & Ian

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Fri, 14 Aug 2020 21:31:28 +0000

Thanks Tommy and Ian!

While updating a few references this week, I noticed that the 02 draft had no Security Considerations Section.  That won't do!

The co-authors came together and supplied new text for the Section in version 03, posted minutes ago. Please consider version 03 of the draft during WGLC.  Thank you IPPM.

For the co-authors,
Al

From: ippm [mailto:[email-masked]] On Behalf Of Tommy Pauly
Sent: Friday, August 14, 2020 5:21 PM
To: IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: [ippm] WGLC for draft-ietf-ippm-capacity-metric-method

Hello IPPM,

The latest version can be found here: https://tools.ietf.org/html/draft-ietf-ippm-capacity-metric-method-02<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dcapacity-2Dmetric-2Dmethod-2D02&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=SIvlMcMEEzV1Wv8tA8hftr1Fvi38_c2R6bgbotceIsU&s=WEcaTbukpUJlfOGrn8Lbw-jjrpTxRsPst6bsHPjjExE&e=>

The last call will end on Wednesday, September 2. Please reply to [email-masked]<mailto:[email-masked]> with your reviews and comments, and indicate if you think the document is ready to progress!

Best,
Tommy & Ian

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 28 Aug 2020 15:34:57 -0700

Hi IPPM,

A reminder that our WGLC is ending next week for draft-ietf-ippm-capacity-metric-method. Please take a moment to review the document!

Thanks,
Tommy

> On Aug 14, 2020, at 2:31 PM, MORTON, ALFRED C (AL) <[email-masked]> wrote:
> 
> Thanks Tommy and Ian!
>  
> While updating a few references this week, I noticed that the 02 draft had no Security Considerations Section.  That won’t do!
>  
>   <>
> From: ippm [mailto:ippm-bounces@ietf..org] On Behalf Of Tommy Pauly
> The latest version can be found here: https://tools.ietf.org/html/draft-ietf-ippm-capacity-metric-method-02 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dcapacity-2Dmetric-2Dmethod-2D02&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=SIvlMcMEEzV1Wv8tA8hftr1Fvi38_c2R6bgbotceIsU&s=WEcaTbukpUJlfOGrn8Lbw-jjrpTxRsPst6bsHPjjExE&e=>
>  
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Fri, 28 Aug 2020 23:53:06 +0000

Hi Tommy,
Thanks for sending the reminder!
I support this as an author of course,
Al

From: Tommy Pauly [mailto:[email-masked]]
Sent: Friday, August 28, 2020 6:35 PM
To: IETF IPPM WG ([email-masked]) <[email-masked]>
Cc: Tommy Pauly <tpauly=[email-masked]>; MORTON, ALFRED C (AL) <[email-masked]>
Subject: Re: [ippm] WGLC for draft-ietf-ippm-capacity-metric-method

Hi IPPM,

Thanks,
Tommy

On Aug 14, 2020, at 2:31 PM, MORTON, ALFRED C (AL) <[email-masked]<mailto:[email-masked]>> wrote:

Thanks Tommy and Ian!

For the co-authors,
Al

From: ippm [mailto:ippm-bounces@ietf..org] On Behalf Of Tommy Pauly
Sent: Friday, August 14, 2020 5:21 PM
To: IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: [ippm] WGLC for draft-ietf-ippm-capacity-metric-method

Hello IPPM,

Best,
Tommy & Ian
_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ippm&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=WhdjOJaLaKnkqCY9q-_CdCoH6_wwB1_QaV9FHk-qgNc&s=mMx6KKiG6xhHD9mZLMLJ70_AsL7gk_GnydQqC14aB00&e=>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 29 Aug 2020 01:26:42 +0000

Hi,

This document is useful and ready to advance in my opinion.

Thank you!

Carlos.

2020/08/14 午後5:21、Tommy Pauly <tpauly=[email-masked]<mailto:tpauly=[email-masked]>>のメール:

Hello IPPM,

The latest version can be found here: https://tools.ietf.org/html/draft-ietf-ippm-capacity-metric-method-02

Best,
Tommy & Ian

---

From: Cociglio Mauro <[email-masked]>
Date: Sat, 29 Aug 2020 17:21:25 +0000

Hi,
I support this draft.
Regards.
Mauro

-------- Messaggio originale --------
Da: Tommy Pauly <tpauly=[email-masked]>
Data: 29/08/20 00:35 (GMT+01:00)
A: "IETF IPPM WG ([email-masked])" <[email-masked]>
Cc: "MORTON, ALFRED C (AL)" <[email-masked]>, Tommy Pauly <tpauly=[email-masked]>
Oggetto: [EXT] Re: [ippm] WGLC for draft-ietf-ippm-capacity-metric-method

Hi IPPM,

Thanks,
Tommy

Thanks Tommy and Ian!

For the co-authors,
Al

Hello IPPM,

Best,
Tommy & Ian

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. 

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. 

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: <[email-masked]>
Date: Mon, 31 Aug 2020 05:31:37 +0000

Hi Tommy,

as a co-author, I support advancing this draft.

Regards,

Ruediger

Von: ippm <[email-masked]> Im Auftrag von Tommy Pauly
Gesendet: Samstag, 29. August 2020 00:35
An: IETF IPPM WG ([email-masked]) <[email-masked]>
Cc: MORTON, ALFRED C (AL) <[email-masked]>; Tommy Pauly <tpauly=[email-masked]>
Betreff: Re: [ippm] WGLC for draft-ietf-ippm-capacity-metric-method

Hi IPPM,

Thanks,
Tommy

Thanks Tommy and Ian!

For the co-authors,
Al

Hello IPPM,

Best,
Tommy & Ian

---

From: Joachim Fabini <[email-masked]>
Date: Mon, 31 Aug 2020 11:10:26 +0200

Hi Tommy,

the document is imo stable and ready for WGLC.

thanks
Joachim

On 29/08/2020 00:34, Tommy Pauly wrote:
> Hi IPPM,
> 
> A reminder that our WGLC is ending next week for
> draft-ietf-ippm-capacity-metric-method. Please take a moment to review
> the document!
> 
> Thanks,
> Tommy
> 
>> On Aug 14, 2020, at 2:31 PM, MORTON, ALFRED C (AL)
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Thanks Tommy and Ian!
>>  
>> While updating a few references this week, I noticed that the 02 draft
>> had no Security Considerations Section.  That won’t do!
>>  
>> The co-authors came together and supplied new text for the Section in
>> version 03, posted minutes ago. Please consider version 03 of the
>> draft during WGLC.  Thank you IPPM. 
>>  
>> For the co-authors,
>> Al
>>  
>>  
>> *From:* ippm [mailto:ippm-bounces@ietf..org] *On Behalf Of *Tommy Pauly
>> *Sent:* Friday, August 14, 2020 5:21 PM
>> *To:* IETF IPPM WG ([email-masked] <mailto:[email-masked]>)
>> <[email-masked] <mailto:[email-masked]>>
>> *Subject:* [ippm] WGLC for draft-ietf-ippm-capacity-metric-method
>>  
>> Hello IPPM,
>>  
>> As discussed at IETF 108, draft-ietf-ippm-capacity-metric-method is
>> stable, and the group felt it is ready for Working Group Last Call.
>>  
>> The latest version can be found
>> here: https://tools.ietf.org/html/draft-ietf-ippm-capacity-metric-method-02
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dcapacity-2Dmetric-2Dmethod-2D02&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=SIvlMcMEEzV1Wv8tA8hftr1Fvi38_c2R6bgbotceIsU&s=WEcaTbukpUJlfOGrn8Lbw-jjrpTxRsPst6bsHPjjExE&e=>
>>  
>> The last call will end on *Wednesday, September 2*. Please reply
>> to [email-masked] <mailto:[email-masked]> with your reviews and
>> comments, and indicate if you think the document is ready to progress!
>>  
>> Best,
>> Tommy & Ian
>> [email-masked] <mailto:[email-masked]>

---

From: J Ignacio Alvarez-Hamelin <[email-masked]>
Date: Mon, 31 Aug 2020 10:57:00 -0300

Hi Tommy, 

I think this draft is useful, and it represents some methods that are used nowadays. I have a couple of comments:

1_ The equation in section 5.3 does not consider times spending on transmitting (or I did not see it clearly). It is true that for some measurements, the destination is close to the source, and these times are tiny. 
2_ A recommendation about the minimum time during the process could be useful to overcome some traffic shapers operation. 
3_ 3_ For the "Related Round-Trip Delay and Loss Definitions" sections, I suggest to include the "median," according to the observations in draft-ietf-ippm-route-10.

Many thanks to the authors for their work. 

Sincerely,

	J. Ignacio Alvarez-Hamelin

_______________________________________________________________

Dr. Ing. José Ignacio Alvarez-Hamelin
CONICET and Facultad de Ingeniería, Universidad de Buenos Aires
Av. Paseo Colón 850 - C1063ACV - Buenos Aires - Argentina
+54 (11) 5285 0716 / 5285 0705
e-mail: [email-masked]
web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/
_______________________________________________________________

> On 28 Aug 2020, at 19:34, Tommy Pauly <tpauly=[email-masked]> wrote:
> 
> Hi IPPM,
> 
>> The last call will end on Wednesday, September 2. Please reply to [email-masked] with your reviews and comments, and indicate if you think the document is ready to progress!
>>  
>> Best,
>> Tommy & Ian

---

From: Joachim Fabini <[email-masked]>
Date: Mon, 31 Aug 2020 16:33:27 +0200

All,

as a follow-up some nits that I noticed while reading through the
capacity draft:

1. Newly added security considerations: my expectation is that UDP-based
capacity measurements can be potentially more harmful and more difficult
to protect against when compared to TCP-based ones, in particular when
considering (D)DoS. First, there is no state involved at transport layer
that an attacker may need to track/establish and no flow/congestion
control involved. Second, firewalls and other stateful protection
devices can easily identify a missing 3-way handshake for TCP and block
subsequent (unsolicited, harmful) measurement packets sent by an
attacker. But there's no such option for UDP, meaning that the
application layer must handle this case.
If an attacker misuses the packet pattern of UDP capacity measurements
and directs these measurements to an open UDP port of the
destination/target, then middlebox and firewall protections may fail and
consider the traffic to be a legitimate one.
The authors may consider adding some details and guidelines on these
aspects to the security section.

2. A potential architectural/wording issue (disclaimer: I just skimmed
over the draft and may have ommitted some relevant statements, will
hopefully find some more time during the next weeks to review it more
thoroughly): in the beginning the unidirectionality of the capacity
measurement was not obvious to me. Perhaps add it to the draft title to
make this explicit?
In particular the discussion about round-trip delay (RTD) and round-trip
loss (RTL) created this impression and, infact, may also be misleading
wrt inferences about the capacity measurement results.
I assume that the correct capacity measurement depends on the forward
path only, but a lossy reverse path may increase the RTL. This may
introduce some artificial bias and impression that the measurement limit
is reached, while infact the forward link is still under-utilized. So
I'm wondering if Round-trip delay/loss is acceptable or one-way-loss is
needed and more accurate.

But, as written in the disclaimer: it's a potential issue that needs
some more time and deeper analysis. Hope to find some time to go more
into details later on.

Overall I find the concept of UDP-based capacity measurement to be a
compelling mechanism that can help to overcome some of the downsides of
TCP-based bulk transfer capacities. Thanks to the authors for their
contribution.

regards
Joachim

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Mon, 31 Aug 2020 14:40:12 +0000

Thanks for getting the document to the finish line. I support advancing the document – but noticed a couple of nits while reading through the -03 version of draft (see below).

Cheers, Frank

A few nits:

* Section 1: [copycat][copycat] mentioned twice
* Notation: Would it make sense to use a notation which is more Latex-style, e.g. use dt_n, dt_n+1 instead of dtn,dtn+1. Initially I got a bit confused because the dtn wasn’t defined in section 4, whereas dt was.
* Notation: Would it make sense to use a different character that “I” for the duration, because “I” can easily be confused with (me, myself)? E.g. section 8 says: “The duration of a test, I, MUST be constrained in a production network, since this is an active test method and it will likely cause congestion on the Src to Dst host path during a test.”.. and at first glimpse, I was wondering why I should be constrained in a production network :-).
* Section 5.3: IMHO it would be useful to add a sentence / stress the fact, that the definition of “IP Layer Capacity” is always wrt/ particular endpoints, i.e. E2E – rather than that of a channel between endpoints. I.e. the capacity of the channel between endpoints could be lower (in case e.g. compression is used) than the capacity between endpoints. Another place to put this discussion could be section 8.3.
* Section 5.4: Shouldn’t the text say [T0, T0+I]? T0 is defined in section 4, T is not. (There are several occurrences of T in the document)
* Section 6.3: Replace “[see section Related Round-Trip Delay and Loss Definitions below]” with a proper reference
* Section 6.3: What are “Standard Formed packets”? Could we add a reference?

* Section 6.5: Line break in “Maximum_C(T,I,PM)”

* Section 6.6: Does one Megabit consist of 1048576 bits or 1000000 bits?

* Section 8.1: If I understand things correctly, the examples given here refer to Mbps as a unit, i.e. Rx+10 would mean Rx+10Mbps. Correct? Is there a way to future proof these numbers and methods: What is Mbps might be Gbps in 10 years? E.g. we could consider defining those formulas in relation to the nominal interface speeds of the Src and Dst. Relative numbers might be better than absolute values, e.g. Rx-30: How would we know that we can always reduce the rate by 30 Mbps?

* Section 8.4: Empty bullet

* Section 10.: How about adding a requirement that the identity and integrity of Src and Dst should be checked and confirmed? That way we ensure that we indeed measure Src to Dst  and not to some MIM “friendly” proxy that would give me the impression of stellar IP layer capacity...

From: ippm <[email-masked]> On Behalf Of MORTON, ALFRED C (AL)
Sent: Samstag, 29. August 2020 01:53
To: Tommy Pauly <[email-masked]>; IETF IPPM WG ([email-masked]) <[email-masked]>
Cc: Tommy Pauly <tpauly=[email-masked]>
Subject: Re: [ippm] WGLC for draft-ietf-ippm-capacity-metric-method

Hi Tommy,

Cc: Tommy Pauly <tpauly=[email-masked]<mailto:tpauly=[email-masked]>>; MORTON, ALFRED C (AL) <[email-masked]<mailto:[email-masked]>>

Hi IPPM,

Thanks,
Tommy

Thanks Tommy and Ian!

For the co-authors,
Al

Hello IPPM,

Best,
Tommy & Ian