Subject: [ippm] Feedback on Round-Trip Loss

From: Steve Baillargeon <[email-masked]>
Date: Mon, 21 Mar 2011 08:38:46 -0400

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.
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".

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.

Regards
Steve Baillargeon

---

From: Al Morton <[email-masked]>
Date: Mon, 28 Mar 2011 12:01:36 -0400

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.