Subject: RE: [bmwg] WG Last Call: draft-ietf-bmwg-dsmterm-05

From: Debby Stopp <[email-masked]>
Date: Wed, 19 Mar 2003 09:41:08 -0800

I have some comments regarding this definition:

     3.2.4 Delay

        Definition:
          The time interval starting when the last bit of the input IP
          packet reaches the input port of the DUT/SUT and ending when
          the last bit of the output IP packet is seen on the output
          port of the DUT/SUT.

*	 According to this def, we need to be able to determine the time at
which the last bit of the packet reaches the DUT/SUT - isn't this white box?
How are we supposed to find out this time w/out asking the DUT/SUT?  Same
discussion for the other goalpost; how are we supposed to find out the time
that  the last bit left the DUT/SUT? 

*	I question the appropriateness of defining 'delay' specifically in
this document.  The word 'delay', is a well-known & highly utilized term in
the internet community.  I suggest that you append an modifier on this def,
such as "IP Delay" in order to differentiate it from the well-known
terminology usage. 

*	In the same section:

Delay is delay, regardless of the technology being measured. 

 This is an ambiguous statement; either remove it or crisp up exactly what
you were trying to say.

& lastly -  If delay happens and no one measures it, is it still delay?
:) 

Debby Stopp

---

From: David Newman <[email-masked]>
Date: Wed, 19 Mar 2003 10:36:58 -0800 (PST)

Concur regarding locus of measurement. We should reword to state that all
observations are external.

The assertion that "delay" is "well-known terminology usage" is
bogus^H^H^H^H^Hunsupported. Which RFC defines this term in a benchmarking 
context?

dn
Honorary Chairman
Committee to Stamp Out HTML Email

On Wed, 19 Mar 

> & lastly -  If delay happens and no one measures it, is it still delay?

_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg

---

From: David Newman <[email-masked]>
Date: Wed, 19 Mar 2003 10:36:58 -0800 (PST)

dn
Honorary Chairman

On Wed, 19 Mar

---

From: Al Morton <[email-masked]>
Date: Fri, 21 Mar 2003 12:05:22 -0500

David, Debby, and Jerry,

Noting that the Latency definitions RFC1242
are very similar to the Delay definition in dsmterm-05,
what rewording do you have in mind?

I'm thinking that a clarifying note might be good enough,
along the lines of David's statement,
"all observations are external".

Al

At 10:36 AM 03/19/2003 -0800, David Newman wrote:

>...
>...
>On Wed, 19 Mar 2003, Debby Stopp wrote:

---

From: Al Morton <[email-masked]>
Date: Fri, 21 Mar 2003 12:05:22 -0500

David, Debby, and Jerry,

Al

---

From: David Newman <[email-masked]>
Date: Thu, 27 Mar 2003 09:07:35 -0800 (PST)

> what rewording do you have in mind?

Sorry for the high, um, delay in responding.

There is one BIG difference between 1242 latency and dsterm latency, 
namely that delay runs from last bit to last bit (regardless of DUT/SUT 
architecture). Latency is FIFO or LIFO depending on DUT/SUT architecture.

> "all observations are external".

Concur. Here's my fix to make the definition work from the externally
observable standpoint:

"The time interval starting when the last bit of the input IP packet is
offered to the input port of the DUT/SUT and ending when the last bit of
the output IP packet is received from the output port of the DUT/SUT."

And I'd add the following two sentences to the end of the discussion to 
clarify that we are dealing with externally observable events:

"The delay time interval MUST be externally observed. The delay
measurement MUST NOT include delays added by test bed components other
than the DUT/SUT, such as propagation time introduced by cabling or
non-zero delay added by the test instrument."

I don't think this latter sentence is anything particularly new: Whenever
we measure delay (or latency, for that matter) the goal is to determine
the slowdown added by the DUT/SUT and only the DUT/SUT.

dn

---

From: David Newman <[email-masked]>
Date: Thu, 27 Mar 2003 09:07:35 -0800 (PST)

dn