Re: [ippm] AD review: draft-ietf-ippm-twamp-06.txt

Lars,

Thanks for the detailed review, you've prompted many
valuable improvements.  My responses are below, and a
revised draft will follow shortly.

If anyone replies to this message, please excerpt the
relevant section and change the Subject line, thanks!

The primary open issue requiring more discussion is
TWAMP Light, as you anticipated.  I have suggested one
way forward, but would like to hear other opinions, too.

regards,
Al

At 12:40 AM 4/2/2008, Lars Eggert wrote:
>I'm trying to to the AD review that normally happens after a WG
>requests publication early, such that it overlaps with WGLC. For this
>document, that hasn't happened, but at least I'm not very late,
>because it is still being discussed.

Sorry for the delay replying, many standards bodies I follow
became active in parallel...

>Summary: Not quite ready. My main concern is around the TWAMP light
>variant, and there are a number of small things where the document
>would be improved by a more careful description or some editorial
>changes.
>
>Detailed comments:
>
>INTRODUCTION, paragraph 10:
>    Nit: s/Measurment/Measurement/ (everywhere in the footer)
OK

>INTRODUCTION, paragraph 11:
>  >     The IP Performance Metrics (IPPM) working group's One-way Active
>  >     Measurement Protocol [RFC4656] (OWAMP) provides a common protocol
>  >     for measuring one-way metrics between network devices.
>
>    Rephrase the first sentence to not talk about the IPPM WG - it's
>    ephemeral and for the RFC it doesn't matter where OWAMP came from.
>    (In other words, cut "IP Performance Metrics (IPPM) working group's".)
OK

>Section 1., paragraph 1:
>  >     The IETF IP Performance Metrics (IPPM) working group has
>completed
>  >     a draft standard for the round-trip delay [RFC2681] metric.  IPPM
>  >     has also completed a protocol for the control and collection of
>  >     one-way measurements, the One-way Active Measurement Protocol
>  >     (OWAMP) [RFC4656].
>
>    See above - rephrase to not talk about IPPM.
OK

>Section 1., paragraph 2:
>  >     Two-way measurements are common in IP networks, primarily because
>  >     time accuracy is less demanding for round-trip delay
>
>    I don't quite understand what you mean by "time accuracy is less
>    demanding".

Revised sentence:
"Two-way measurements are common in IP networks, primarily because
synchronization between local and remote clocks is unnecessary for
round-trip delay, and measurement support at the remote end may be
limited to a simple echo function."

>Section 2., paragraph 0:
>  >  2. Protocol Overview
>
>    This section is almost word-by-word identical to a big chunk of
>    section 1.2. Merge?

Yes, this is just a summary of 1.2.  What's really needed here is
an outline for the typical operation of the protocol(s). This should
be understandable since all the entities and protocols have been
introduced in 1.2.  I'll give that a try in the next draft.

>Section 3., paragraph 2:
>  >     All OWAMP [RFC4656] Control messages except for the Fetch-Session
>  >     command apply to TWAMP.
>
>    Does "apply to" mean that TWAMP implementations MUST implement all
>    these OWAMP control messages? If yes, say so with RFC2119 terms.

It is simpler to say something definitive about the Fetch-Session msg:
"One such exception is the Fetch Session command, which is not used in TWAMP."
(Actually, this sentence is part of the 1st paragraph, and just extends
the ways in which TWAMP differs from OWAMP.)

>Section 3.5, paragraph 2:
>  >     In order to distinguish the session as a two-way versus a one-way
>  >     measurement session the first octet of the Request-Session
>command
>  >     MUST be set to 5.  Value of 5 indicates that this is a
>  >     Request-Session for a two-way metrics measurement session.
>
>    That text is a bit misleading. An "OWAMP Request-Session" will always
>    have 1 in that octet. What you're doing here is defining a
>    "Request-TW-Session" command (this is how it's called in the IANA
>    registry below) that looks and is mostly processed like an OWAMP
>    message, but has a 5 in the first octet (because OWAMP uses first
>    octet codes 2-4 for other commands.)

After deleting all the mis-leading stuff above, we have a paragraph
introducing the Command Number Field. Then this new paragraph:

"The Command Number value of 5 indicates that this is a
Request-TW-Session Command, and the Server MUST interpret
this command as a request for a two way test session using the
TWAMP-Test protocol."

>    ...You should make sure that you
>    call the command "Request-TW-Session" everywhere in the document, to
>    be consistent with the code allocated in the IANA registry.
good catch, thanks.

>Section 3.5, paragraph 3:
>  >     In TWAMP, the first octet is referred to as the Command Number, and
>  >     the Command Number is a recognized extension mechanism. Readers are
>  >     encouraged to consult the TWAMP Command Number Registry to
>  >     determine if there have been additional values assigned.
>
>    I'd argue that because this document creates a registry that in
>    addition to TWAMP also covers OWAMP, it should update RFC4656, if only
>    to alert implementers of OWAMP that an IANA registry exists that
>    matters for OWAMP but that RFC4656 doesn't descibe.

Although TWAMP is highly dependent on messages and procedures that
OWAMP defined, the registry is only for TWAMP. For example, we made
OWAMP's Request-Session command number (1) Forbidden in TWAMP.
So I'm inclined to agree with Jeff here, TWAMP and OWAMP will be
administrated separately, but it's less about a choice we authors made
and more about the recognition that there will need to be TWAMP-only
implementations (it simply wasn't practical to have TWAMP-only hosts
as an extension of the existing RFC - OWAMP would have to be mandatory).

>Section 3.5, paragraph 4:
>  >     If a TWAMP server receives an unexpected command number, it
>SHOULD
>  >     respond with the Accept field set to 3 (meaning "Some aspect of
>  >     request is not supported") in the Server-Start message.
>
>    s/SHOULD/MUST/ (or else explain in which cases the SHOULD may
>    disregarded)
OK, MUST

*** Also, that should be the Accept-Session message, not the Server Start...

>Section 3.5, paragraph 6:
>  >     Both Conf-Sender field and Conf-Receiver field MUST be set to 0
>  >     since the Session-Reflector will both receive and send packets, and
>  >     the roles are established according to which host initiates the TCP
>  >     connection for control.  The server MUST interpret any non-zero
>  >     value as zero.
>
>    If the field is not zero, something is clearly wrong with the peer -
>    shouldn't the session be aborted?

Yes, it's an improperly formed command. So, now we have:
"...The server MUST interpret any non zero value as an improperly
formatted command, and MUST respond with the Accept field set
to 3 (meaning "Some aspect of request is not supported")
in the Accept-Session message."

>Section 3.5, paragraph 10:
>  >     They MAY be set to 0, in which case the IP addresses used for the
>  >     Session-Sender to Session-Reflector Control Message exchange MUST
>  >     be used in the test packets.
>
>    This seems to be a difference to OWAMP. Any particular reason why?
>    (For TWAMP Light?)

It's a convenience, AFAIK, it just simplifies user configurations.
TWAMP light wouldn't use the Request-TW-Session message.
But I note that the TWAMP entities named above should be the
Control-Client and the Server, so fixed that.

>Section 3.5, paragraph 14:
>  >     Point (DSCP) as defined in [RFC2474].  The same value of DCSP
>MUST
>
>    Nit: s/DCSP/DSCP/
OK

>Section 3.9, paragraph 1:
>  >     The purpose of TWAMP is measurement of two-way metrics.  Two-way
>  >     measurements do not rely on packet level data collected by the
>  >     Session-Reflector such as sequence number, timestamp, and TTL. As
>  >     such the protocol does not require the retrieval of packet level
>  >     data from the Server and the Fetch-Session command is not defined
>  >     in TWAMP.
>
>    Since Fetch-Session is defined in OWAMP and TWAMP is a variant of
>    that, I'd be good to define what TWAMP should do if it somehow
>    receives a Fetch-Session message. (Suggestion: stop fail.)

Paragraph 4 in section 3.5 (06 version) covers this case: the
command is rejected with code 3. However, this repeated attention
to the Fetch-Session command leads me to try some very definitive
clarifications:

Section 3.4:  List the commands that ARE supported, and say that
OWAMP's Request-Session and Fetch-Session are NOT used in TWAMP.

Section 3.9:  The text isn't quite as clear as it could be, so
I've suggested some modifications:
"The purpose of TWAMP is measurement of two way metrics.
Two way measurement methods do not require packet level data
to be collected by the Session Reflector (such as sequence number,
timestamp, and TTL) because this data is communicated in the "reflected"
test packets.  As such the protocol does not require the retrieval of
packet level data from the Server and the OWAMP Fetch Session command
is not used in TWAMP."

Section 8.4:  Reserve the Fetch-Session command number for
something else in TWAMP, but don't add Fetch-Session to the
TWAMP control command number registry.

>Section 4.2.1, paragraph 21:
>  >     Implementation note: Naturally, the key schedule for each
>  >     TWAMP-Test session MAY be set up only once per session, not once
>  >     per packet.
>
>    s/MAY/MUST/ (or lowercase, since it's about an implementation choice
>    and not the specification)

Let's use this clarification:
"Implementation note: Naturally, the key schedule for each TWAMP Test
session MUST be set up at most once per session,
not once per packet."
(Note: the original sentence is the same in OWAMP)

>Section 5.1, paragraph 3:
>  >     The responder follows the Session-Reflctor behavior of TWAMP as
>
>    Nit: s/Session-Reflctor/Session-Reflector/
OK

>Section 5.2, paragraph 0:
>  >  5.2 TWAMP Light
>
>    If I understand this correctly, TWAMP Light requires a different
>    processing than Complete TWAMP. The "implementers guide" section is
>    not the place to define specification variants, especially because
>    it's not clear that Light and Complete imoplementations can
>    interoperate without knowing which variant the other side is using.

I agree, this material describes a case where a sub-set of the
TWAMP spec is used (just the TWAMP-Test protocol).

>    If the two variants are desired by the WG, they need to be described in
>    the specification, and there needs to be a mechanism such that Light
>    and Complete implementations can figure out what variant they're
>    talking to at the other end.

Variant discovery will be hard, because the TWAMP Light variant does not
share the control protocol, just the test packet format...

Personally, I think it might be better to move TWAMP Light to
an appendix (informative). "Light" raises a number of Security concerns
that we were asked to address. We could move them to the
Appendix and have a much stronger Security Considerations section.

>Section 8.1, paragraph 1:
>  >     IANA will create an TWAMP-Control Command registry.  TWAMP-
>Control
>  >     commands are specified by the first octet in OWAMP-Control
>messages
>  >     as shown in section 3.4 of [RFC4656], and modified by this
>  >     document. Thus this registry may contain sixteen possible values.
>
>    Elsewhere in this document, the term "command number" is used. Please
>    use one term consistently throughout the document.

Made the changes in Section 8. and 3.5

>Section 8.4, paragraph 2:
>  >     Value  Description             Semantics Definition
>  >     0      Reserved
>  >     1      Forbidden
>  >     2      Start-Sessions          RFC4656, Section 3.7
>  >     3      Stop-Sessions           RFC4656, Section 3.8
>  >     4      Fetch-Session           RFC4656, Section 3.9
>  >     5      Request-TW-Session      this document, Section 3.5
>  >     6      Experimentation         undefined, see Section 8.3.
>
>    This document doesn't specify how implementations shold react if
>    Reserved or Forbidden values are received.

I think the 4th paragraph of section 3.5 covers this
(since they are unexpected numbers), but I'll add a sentence to clarify:
"Command numbers that are Forbidden (and possibly numbers
that are Reserved) are unexpected."

>(Is there a difference?)

Yes, a forbidden number is always unexpected, but a future
implementation/version might use a reserved number. I think
the above text makes this distinction...

>Section 10.1, paragraph 1:
>  >        [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J.,
>  >                   Zekauskas, M., "A One-way Active Measurement
>Protocol
>  >                   (OWAMP)", draft-ietf-ippm-owdp-11.txt, October
>2004.
>
>    s/draft-ietf-ippm-owdp-11.txt/RFC 4656/
OK

>Section 10.1, paragraph 5:
>  >        [RFC2434] Narten, T., Alvestrand, H., Guidelines for Writing
>  >                  an IANA Considerations Section in RFCs, RFC 2474,
>  >                  October 1998.
>
>    s/RFC 2474/RFC 2434/ (copy&paste error?)
OK

>_______________________________________________
>ippm mailing list
>ippm@ietf.org
>https://www.ietf.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm