Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol (TWAMP)
RFC 7750

Note: This ballot was opened for revision 02 and is now closed.

(Spencer Dawkins) Yes

Comment (2015-10-22 for -02)
No email
send info
My apologies for thinking slowly ... but it doesn't look like these questions will be difficult to resolve.

I talked with David Black about this draft, and he had questions that I translated into AD-speak as:

Reflecting an unknown DSCP value is a MAY. Can reflecting packets using a DSCP value you don't understand be a bad idea? How important is that the DSCP value is NOT 0 (CS0, default forwarding)?

If you are reflecting a DSCP value, are you also reflecting the ECN(0) bit unchanged?

TWAMP doesn't look congestion-controlled to me (certainly not in the reflected direction - https://tools.ietf.org/html/rfc5357 says the packet is reflected as quickly/immediately as possible in at least three places I can see. What is a typical sending rate for the Session-Sender, and is that likely to cause problems in the reflected direction?

His note to me follows:

This bullet at the end of 2.2.2 bothers me:
 
   o  if the negotiated/provisioned DSCP value is not known (e.g.  TWAMP
      Light), the choice of the DSCP is implementation specific.  For
      instance, Session-Reflector MAY copy the DSCP value from the
      received test packet and set it as DSCP in a reflected packet
 
This is implicitly recommending reflection of the DSCP value, and by
omitted implication, reflection of the ECN value.  Both of those seem
like bad ideas, it would be better to say that in this case the DSCP
should be set to 0 (CS0, Default forwarding).  I would also say that
the ECN field MUST be set to 0 (not-ECT) in the reflected packet, always.
 
I’m a bit concerned about setting ECT(0) or ECT(1) on the forward
measurement path, as TWAMP is not congestion-responsive.  Is the
transmission rate of TWAMP low enough to not cause a problem if CE
signals are received and ignored in the ECN field at the Reflector?

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2015-10-20 for -02)
No email
send info
Just a few mostly editorial comments:

- Abstract: Did you mean OPTIONAL to be capitalized in the abstract? I'm not sure what the purpose of a 2119 keyword would be there.

- 1, first paragraph:
There are lots of missing articles ("the") in the first paragraph.

-1, 2nd paragraph:
There's no need to say it's OPTIONAL more than once.

- 2.1, 1st paragraph:
"DSCP and ECN monitoring flag" and "Mode" each need a leading "the".

- 2.2.1:
The MUST in the first paragraph is not really needed. The Session-Reflector either supports the extension and does these things, or does not support the extension and does not do these things.

- First bullet in list at end of 2.2.1:
s/extracts/extract

(Benoît Claise) No Objection

Comment (2015-10-19 for -02)
No email
send info
As mentioned by Al Morton, part of his OPS DIR review:

Summary: Almost ready, comments and editorial suggestions follow.

The draft header should indicate that this draft updates RFC 5357.

Section 2.2.1

Figure 1 has a number of canonical references that should 
be cited to ensure IPv4 and IPv6 applicability, including 
RFC 2474, RFC 3168, and other relevant updates (of which 
there are many).

<later>
   o  if the negotiated/provisioned DSCP value is not known (e.g.  TWAMP
      Light), the choice of the DSCP is implementation specific.  For
      instance, Session-Reflector MAY copy the DSCP value from the
      received test packet and set it as DSCP in a reflected packet.
Question:
What about the ECN value?   From 3168:
      +-----+-----+
      | ECN FIELD |
      +-----+-----+
        ECT   CE         [Obsolete] RFC 2481 names for the ECN bits.
         0     0         Not-ECT
         0     1         ECT(1)
         1     0         ECT(0)
         1     1         CE
It makes little sense to copy a "11" == CE into the reflected packet,
and it may affect the measured performance if "11" were copied.
The draft needs more guidance here (there is a general problem
when the negotiated values are "not known"; this does not apply 
to the Standards Track TWAMP protocol or its extensions).

-=-=-=-=-=-=-=-=-=-=-=-=-

Editorial comments/suggestions:

OLD
2.2.  TWAMP-Test Extension

   Monitoring of DSCP and ECN requires support by the Session-Reflector
   and changes the format of its test packet format both in
   unauthenticated, authenticated and encrypted modes. 
Suggest:
   Monitoring of DSCP and ECN requires support by the Session-Reflector
   and changes the test packet format in all the original
   (unauthenticated, authenticated and encrypted) modes. 

2.2.1

OLD
   o  the first six bits of the Differentiated Service field MUST be
      copied from received Session-Sender test packet into Sender DSCP
      (S-DSCP) field;

   o  the following two bits of the ECN field MUST be copied from
      received Session-Sender test packet into Sender ECN (S-ECN) field.
Suggest:
   o  the six (least-significant) bits of the Differentiated Service field MUST be
      copied from received Session-Sender test packet into Sender DSCP
      (S-DSCP) field;

   o  the two bits of the ECN field MUST be copied from
      received Session-Sender test packet into Sender ECN (S-ECN) field.

because RFC 3168 defines:
         0     1     2     3     4     5     6     7
      +-----+-----+-----+-----+-----+-----+-----+-----+
      |          DS FIELD, DSCP           | ECN FIELD |
      +-----+-----+-----+-----+-----+-----+-----+-----+

        DSCP: differentiated services codepoint
        ECN:  Explicit Congestion Notification

      Figure 2: The Differentiated Services and ECN Fields in IP.
-=-=-=-=-=-=-=-

OLD
    0     1     2     3     4     5     6     7     8
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               S-DSCP              |   S-ECN   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 1: Sender DSCP and ECN field format

Suggest:
The extra "+" within bit positions are distracting,
and don't conform to the conventions of these diagrams.
Also, there's no "8" when numbering from 0.

Some attempt should be made to put Figure 3 on a single page in the 
final version. There's one line taken up by "+" that is unnecessary
in the modified field:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Sender TTL  |  S-DSCP-ECN   |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    |                                                             |
 >> +                                                             + <<
    |                       MBZ (14 octets)                       |
    |                                                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(Stephen Farrell) No Objection

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Comment (2015-10-21 for -02)
No email
send info
Since rfc5357 has more discussion on the differences between unauthenticated, authenticated, and encrypted modes, it would be helpful to have a pointer to that specific point in the Security Considerations section.

Alvaro Retana No Objection

Comment (2015-10-20 for -02)
No email
send info
Just a couple of nits:

In Section 2.2.1., please put a reference to rfc5357 (?) to show where the test packet formats came from and to indicate where the fields are described.

Figure 4 doesn't show the S-DSCP-ECN field in it.

(Martin Stiemerling) No Objection