Re: [ippm] Feedback on Round-Trip Loss

[Al Morton <[e-mail]>]

Hi Steve,

Thanks for your comments.
Belated replies in-line,
Al

At 08:38 AM 3/21/2011, Steve Baillargeon wrote:

Hi Al
I have two suggestions/comments about draft-ietf-ippm-rt-loss-00 draft.
 
1) In my opinion, the information from section 7 and section 8 is applicable for all metrics measured with a "reflected measurement architecture" like TWAMP.
Is it possible to move the text from section 7 and section 8 in the TWAMP RFC?
This will avoid the need to repeat the same considerations and limitations in different documents.

There's no need to repeat the text while there is a reference mechanism
that works, and with HTML draft presentation IETF's references are
better than most (even at the Internet-Draft stage of development).

Also, there are several forms of TWAMP-like measurements, so these
considerations are by no means TWAMP-unique. Of course, section 8
is the Security Considerations, and therefore required to appear
in this draft.

For instance, you could move the text and associated structure from section 8 into the security considerations of RFC 5357 and make a reference to it in the Round-trip Loss.
You could also move the text from section 7 into a new section in RFC 5357 entitled "Reporting Considerations".

We have effectively covered method and reporting topics with the
metrics RFCs in the past, and that organization still makes sense to me.

 
2) I think it is a good time to clarify the terminology or naming convention associated with the Scr->Dst path and Dst->Scr path. You are also using return path to identify the Dst->Scr path. We prefer to use the terms forward and reverse paths as described in draft-baillargeon-ippm-twamp-value-added-octets. I am open to suggestions as long as we try to be consistent.

We need to be consistent with the existing RFCs, such as
RFC 2681, the Round Trip Delay metric, which says in Section 1.1:

   The measurement of round-trip delay instead of one-way delay has
   several weaknesses, summarized here:

   +  The Internet path from a source to a destination may differ from
      the path from the destination back to the source ("asymmetric
      paths"), such that different sequences of routers are used for the
      forward and reverse paths.  Therefore round-trip measurements
      actually measure the performance of two distinct paths together.

Src and Dst are used heavily throughout RFC 2681, but "return" is only used
once (to refer to a "return packet").

I'll do an intelligent  "1,$ s/return/reverse/g",
and six instances will change in -01.