Re: [ippm] WGLC for draft-ietf-ippm-tcp-throughput-tm-06.txt

[Al Morton <[e-mail]>]

Barry, Rudi,

My recollection from the March IPPM session is that
  - we agreed to take this up as an Informational RFC
  - we aren't defining metrics here
   (if we were, it would be standards track)

So, I agree with the "Framework" title change.
I would clarify that "Type-P" metric specifications
are un-attempted with this scope (what the draft does now).

I will hopefully add some more comments later today (sigh).

regards,
Al

At 09:44 AM 9/10/2010, Barry Constantine wrote:
>...
>I thought we agreed that if this were to be retitled a framework 
>(and informational versus a standard), then the Type P metrics could 
>remain unaddressed.
>
>Please let me know if I am misunderstanding, will definitely 
>incorporate your comments in this email (minus the Type P metric work).
>
>
>Thanks,
>
>Barry
>
>
>
>Principal Member of Technical Staff
>
>
>
>JDSU Communication Test (formerly Acterna)
>
>Emerging Markets and Technology Research
>
>One Milestone Center Court
>
>Germantown, MD 20876
>
>(W) 240-404-2227
>
>(C) 301-325-7069
>
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]
>Sent: Friday, September 10, 2010 9:26 AM
>To: Barry Constantine
>Cc: [e-mail]
>Subject: RE: [ippm] WGLC for draft-ietf-ippm-tcp-throughput-tm-06.txt
>
>Hi Barry,
>
>Part 1 of the comments. Edirorial text changes express my taste. I 
>don't insist on them. Comments Part 2 follows, if time allows.
>
>Regards, Ruediger
>
>-----
>
>1. Introduction - Editorial
>
>Last section may be reworded to
>
>    This framework proposes a test which should be performed in addisiont
>    to traditional Layer 2/3 type tests, which are conducted to verify the
>    integrity of the network before conducting TCP tests. Examples include
>    RFC 2544 [RFC2544], iperf (UDP mode), or manual packet layer test
>    techniques where packet throughput, loss, and delay measurements
>    are conducted.
>----
>
>2. Goals of this Methodology
>
>...are not intended to be measured or analyzed by such a methodology.
>
>Please add
>    - a method to operate permanently with high measurement loads. TCP
>      performance and optimisation data of operational networks may be
>      captured and evaluated by using data of the "TCP Extended
>      Statistics MIB" [RFC4898].
>
><-- Please add a reference to RFC 4898 or explain why it can't be used -->
>
>----
>
>2.2 Metrics for TCP Throughput
>
>Henk had a comment here which may have been caused by the lack of a
>definition of "transmitted bytes". Please add a definition of the terms
>"Transmitted bytes" and "retransmitted Bytes". If the former is the sum of
>"Succesfully transmitted bytes" and "retransmitted bytes", that would solve
>Henk's problem, as then Transmitted Bytes > Retransmitted Bytes.
>
>Effectively your formula then is: received bytes/transmitted bytes.
>
>You introduce some type P like singletons in the following:
>
>- type-P-TCP Transmitted Bytes
>- type-P-TCP Retransmitted Bytes
>- type-P-TCP Efficiency (you've defined a formula)
>
>These depend on a number of parameters which may vary:
>RTT, Packet Loss, MSS, Path Capacity, MTU size and the time when
>you've measured.
>
>You then introduce another two type P like singletons,
>
>- type-P-TCP Actual Transfer Time
>- type-P-TCP Transfer Index
>
>In adition to the above parameters, both depend on a data block size
>and the transfer index in addition depends on an "ideal TCP transfer
>time".
>
>There's no definition of the "ideal TCP transfer time" - at least I didn't
>see any before or immediately after the Transfer Index is introduced.
>This should be added.
>
>I've tried to scetch some Type-P language here and based it on your
>input. I leave it to you to pick it up. I'm not an expert on type p
>definitions, this definitely requires more work.
>
>----------Finish for today--------
>
>_______________________________________________
>ippm mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ippm