Subject: Re: [ippm] WGLC on draft-ietf-ippm-model-based-metrics

From: <[email-masked]>
Date: Wed, 13 May 2015 09:54:15 +0200

Brian

I didn't succeed in reading the complete draft. I appreciate the work and think it should be picked up by IPPM WG. Not sure, whether this should be done with this version (but as stated: didn't read it all).

The draft says

   "A TDS together with additional specification such as "type-p", 
    etc which are out of scope for this document..."

This allows the question whether this is a framework rather than a metric specification.

Further, terminology may be straightened and then should be applied more stringently throughout the document. To me the draft requires concentrated reading to follow the ideas (I don't claim my own drafts to be any better to this respect and I know that the changes I ask for are somewhat painful for authors).

So far I had many editorials and minor comments. I will send them to the authors.

Regards, Ruediger

-----Ursprüngliche Nachricht-----
Von: ippm [mailto:[email-masked]] Im Auftrag von Brian Trammell
Gesendet: Donnerstag, 23. April 2015 10:17
An: [email-masked]
Betreff: Re: [ippm] WGLC on draft-ietf-ippm-model-based-metrics

Greetings, all,

Seeing no comment on this WGLC, we will extend the WGLC by two weeks, now to end next Friday, 1 May 2015.

*Please* review and comment on the draft to the [email-masked] list.

Thanks, best regards,

Brian (chair hat)

> On 27 Mar 2015, at 17:08, Brian Trammell <[email-masked]> wrote:
> 
> Greetings, all,
> 
> Working Group Last Call has started on draft-ietf-ippm-model-based-metrics. Please provide final comments on this document to the IPPM working group list [email-masked] by Friday, 17 April 2015.
> 
> (Note, given that many in the room who had read previous revisions of this document indicated they had not reviewed the latest, this is a three week WGLC to allow additional reading time.)
> 
> Many thanks, best regards,
> 
> Brian (chair hat)
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm

---

From: Brian Trammell <[email-masked]>
Date: Wed, 13 May 2015 11:06:13 +0200

hi Ruediger,

Thanks for the review!

> On 13 May 2015, at 09:54, [email-masked] wrote:
> 
> Brian
> 

This is already a WG draft; this was a WGLC. It's clear from this and other comments that submission to the IESG will be held for a new revision.

> This allows the question whether this is a framework rather than a metric specification.

Matt discussed in Dallas the possibility of sending a framework draft to IPPM for consideration for adoption. Perhaps some of the "frameworkier" bits of this doc could be pulled into the future doc.

In this specific case, though, I think what the document is saying is that this method of bulk transfer capacity measurement is orthogonal to the properties of the specific packets used for the measurement. (There's also something not quite stated here, that this method, as its singleton output is a boolean and as its input parameters describe the "shape" of the traffic rather than the properties of the packets per se, doesn't quite fit into 2330.)

> So far I had many editorials and minor comments. I will send them to the authors.

Many thanks!

Cheers,

Brian

---

From: <[email-masked]>
Date: Fri, 29 May 2015 09:04:27 +0200

Brian

I've sent a commented version of the draft to the authors and read some more lines.

I personally would appreciate if the authors were able to refer to terminology and metrics already specified by IPPM. Spatial metrics, delay and capacity measurements, constant rate measurements, RT measurements and metric composition - if the authors just identify missing terminology and metrics which require adaptation or need to be introduced, I think only a limited set of additional metrics and new terminology is required. 

I think the document contains a lot of useful information. It should be separated in several sections explaining the basic idea of the measurement, an explantation of the measurement and finally the metrics. By now all this information is mixed. TCP specifics still occur in sections 5 and 6 (I think, they shouldn't occur after the measurement idea has been explained). Further, unnecessary and duplicate explanations and duplicate terminology should be removed. The draft contains a lot of terminology. I'm not a TCP expert and I can't easily judge whether some terminology accidentally sounds identical or whether there are small but important differences between two terms. Check different "rates" and "window or pipe" related terminology through the document, if you look for examples.

As an example of an irritating text, look at the following: 

  Repeated Slowstart bursts: Slowstart bursts are typically part of
  larger scale pattern of repeated bursts, such as sending
  target_pipe_size packets as slowstart bursts on a target_RTT
  headway (burst start to burst start). Such a stream has three
  different average rates, depending on the averaging interval. At
  the finest time scale the average rate is the same as the sender
  interface rate, at a medium scale the average rate is twice the
  effective bottleneck link rate and at the longest time scales the
  average rate is equal to the target data rate.

In IP networks, the averaging interval in general impacts the measured rate.  I'm a bit clueless what a fine, medium and long timescale may be. So this text requires concentrated reading to get what is or may be meant. I think, this section defines capacity measurements, 

IP-type-P Link Capacity

   We define the IP-layer link capacity, C(L,T,I), to be the maximum
   number of IP-layer bits that can be transmitted from the source S and
   correctly received by the destination D over the link L during the
   interval [T, T+I], divided by I.

"I" is the variable, "fine"  I is related to the burst length at sender interface rate, and "long" I may be RTT or RTT/2 (I didn't figure it out correctly) and "medium" I is related to the bottleneck rate and the burst size, but certainly could be expressed in a formula (if these three rates are required and can be measured). I also think that there are assumptions about a bottleneck rate <= sender interface rate and about the RTT. 
If these three rates can't be measured or aren't required, the text should be moved to a section explaining the measurement idea (and better explained there) or removed entirely.

Regards, Ruediger

-----Ursprüngliche Nachricht-----
Von: ippm [mailto:[email-masked]] Im Auftrag von Brian Trammell
Gesendet: Donnerstag, 23. April 2015 10:17
An: [email-masked]
Betreff: Re: [ippm] WGLC on draft-ietf-ippm-model-based-metrics

Greetings, all,

Thanks, best regards,

Brian (chair hat)