Subject: [ippm] Spencer Dawkins' Yes on draft-ietf-ippm-type-p-monitor-02: (with COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 22 Oct 2015 04:45:00 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-ippm-type-p-monitor-02: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-type-p-monitor/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 22 Oct 2015 08:08:22 -0400

Hi Spencer and David,

quick reply below,
Al

> -----Original Message-----
> From: ippm [mailto:[email-masked]] On Behalf Of Spencer Dawkins
> Sent: Thursday, October 22, 2015 7:45 AM
> To: The IESG
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: [ippm] Spencer Dawkins' Yes on draft-ietf-ippm-type-p-monitor-
> 02: (with COMMENT)
> 
...
> 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)?
> 
> 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:
> 
> 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.
> 
[ACM] 
This topic (omission of ECN instructions) was a part of my OPS-Dir review. 
Greg and I worked out the following last night (on ippm-list).
we think this (new) last bullet needs to read:

o  if the negotiated/provisioned ECN value is not known,
   ECN SHOULD be set to Not-ECT codepoint value [RFC3168].
   Otherwise, the provisioned ECN value for the session SHALL be used.
Greg>> Yes, agreed.

We could add more about TWAMP sending rates, or that TWAMP Session-Senders 
and Reflectors need to be ECN-responsive ECT(1) is used.

I could live with saying that the *un-provisioned* DSCP should be set to zero 
at the reflector, but we did not discuss that aspect last night.

It would potentially have the effect of testing different classes 
in the forward and reverse directions to set all reflected (reverse path)
DSCPs to zero (when DSCP and ECN are un-provisioned). 

regards,
Al

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 22 Oct 2015 07:17:45 -0500

Hi, Al,

On Thu, Oct 22, 2015 at 7:08 AM, MORTON, ALFRED C (AL) <[email-masked]>
wrote:

> A

It was quick, and helpful. Thanks to you and Greg for being on top of this
draft.

Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 22 Oct 2015 08:05:37 -0500

On one specific point ...

On Thu, Oct 22, 2015 at 7:31 AM, Black, David <[email-masked]> wrote:

> I don't understand what "negotiated/provisioned" means for the ECN value
> because that's usually handled by the protocol (e.g., TCP), so TWAMP
> would have to do this for itself.  This differs from DSCP handling.
>
> > We could add more about TWAMP sending rates,

I observed to David that -00 of the individual draft for TWAMP had roughly
the same "reflect as immediately as possible" behavior in 2005 that we're
discussing now. I'm guessing that this hasn't been recognized as a problem
because of TWAMP sending rates (not that it couldn't be a problem in the
future, of course), but I am guessing.

So, I wouldn't mind hearing more about that, even if it doesn't end up in
the draft.

Thanks,

Spencer

> or that TWAMP Session-Senders
> And "ECN-responsive" would mean what, specifically?  Whatever that is,
> now is probably not a good time to design it, unless it's something rather
> brute-force (e.g., if CE is seen, stop).  This may need to rely on low
> TWAMP sending rates, and caution that TWAMP can discard CE signals from
> the network.
>
> That would be good.  It's probably ok to mention reflecting the DSCP and
> setting it to zero as possibilities - the mention solely of reflection
> of the DSCP comes across as a weak recommendation to do so, whereas
> mentioning multiple possibilities would be more balanced.
>
> Well, ECN is usually only set in one direction, so that testing approach
> for ECN would be realistic.
>
> Thanks,
> --David
>
> > From: MORTON, ALFRED C (AL) [mailto:[email-masked]]
> > Sent: Thursday, October 22, 2015 8:08 AM
> > To: Spencer Dawkins; The IESG
> Black,
> > David; [email-masked]
> > Subject: RE: [ippm] Spencer Dawkins' Yes on
> draft-ietf-ippm-type-p-monitor-02:
> > (with COMMENT)
> >
> > Hi Spencer and David,
> >
> > quick reply below,
> > Al
> >
> the

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 22 Oct 2015 09:23:52 -0400

Hi David,
one quick reply before I back-out and let the 
authors take-over, I jumped in because time
is of the essence on the morning of a telechat...

> From: Black, David [mailto:[email-masked]]
> Sent: Thursday, October 22, 2015 8:32 AM
> To: MORTON, ALFRED C (AL); Spencer Dawkins; The IESG
> [email-masked]; Black, David
> Subject: RE: [ippm] Spencer Dawkins' Yes on draft-ietf-ippm-type-p-
> monitor-02: (with COMMENT)
> 
[ACM] 
Lack of negotiation of the values used in the test session,
usually means that there is no TWAMP-Control protocol in use
and the system uses some version of the informative Appendix 
of TWAMP (TWAMP Light). The negotiation is usually a command
on the Control protocol (Request-TW-Session) and the response 
to Accept or reject with reason code. So, the command indicates
the values of DSCP and ECN that the TWAMP Test Protocol Reflector
should insert in its out-going packets (these same values will be 
sent in the forward direction).  

But ECN works differently than DSCP: Perhaps the Reflector SHOULD return 
ECN 11 CE in the IP header when it receives it and behave like a normal
ECN endpoint, in addition to returning the received
DSCP and ECN bits in the new field that this draft specifies (in payload).
This potentially revises my OPS-DIR comment, and I'm glad you weighed-in
to help sort this behavior.

regards,
Al

...

> > We could add more about TWAMP sending rates, or that TWAMP
> > Session-Senders and Reflectors need to be ECN-responsive ECT(1) is
> used.
> 
> now is probably not a good time to design it, unless it's something
> rather brute-force (e.g., if CE is seen, stop).  This may need to rely
> on low TWAMP sending rates, and caution that TWAMP can discard CE
> signals from the network.
> 
> > I could live with saying that the *un-provisioned* DSCP should be set
> > to zero at the reflector, but we did not discuss that aspect last
> night.
> 
> > It would potentially have the effect of testing different classes in
> > the forward and reverse directions to set all reflected (reverse path)
> > Black, David; [email-masked]
> > Subject: RE: [ippm] Spencer Dawkins' Yes on draft-ietf-ippm-type-p-
> monitor-02:
> > (with COMMENT)
> >
> > Hi Spencer and David,
> >
> > quick reply below,
> > Al
> >
> > > 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?
> > >
> > > 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:
> > >
> > > 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.
> > >
> > We could add more about TWAMP sending rates, or that TWAMP
> > Session-Senders and Reflectors need to be ECN-responsive ECT(1) is
> used.
> >
> > I could live with saying that the *un-provisioned* DSCP should be set
> > to zero at the reflector, but we did not discuss that aspect last
> night.
> >
> > It would potentially have the effect of testing different classes in
> > the forward and reverse directions to set all reflected (reverse path)

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 22 Oct 2015 10:06:40 -0400

Ahhh, below...

> Sent: Thursday, October 22, 2015 9:59 AM
> > But ECN works differently than DSCP: Perhaps the Reflector SHOULD
> > return ECN 11 CE in the IP header when it receives it and behave like
> > a normal ECN endpoint,
> 
> NOOO!!! ;-)
> 
> ECN is directional - the usual ECN reflection to the sender is via a
> higher-level protocol header, e.g., TCP (ECE bit).  The sender should
> *never* set CE in the IP header.
[ACM] 
[ACM] 
So I had it right the first time, something made me think I got it wrong.

As we were,
Al

> 
> The problem is that "normal ECN endpoint" behavior requires ECN support
> in the protocol running over IP to send congestion indications back to
> the sender.
> 
> Thanks,
> --David
> 
> > Sent: Thursday, October 22, 2015 9:24 AM
> > To: Black, David; Spencer Dawkins; The IESG
> > [email-masked]
> > one quick reply before I back-out and let the authors take-over, I
> > jumped in because time is of the essence on the morning of a
> > telechat...
> >
> > > I don't understand what "negotiated/provisioned" means for the ECN
> > > value because that's usually handled by the protocol (e.g., TCP), so
> > > TWAMP would have to do this for itself.  This differs from DSCP
> handling.
> > >
> > [ACM]
> > Lack of negotiation of the values used in the test session, usually
> > means that there is no TWAMP-Control protocol in use and the system
> > uses some version of the informative Appendix of TWAMP (TWAMP Light).
> > The negotiation is usually a command on the Control protocol
> > (Request-TW-Session) and the response to Accept or reject with reason
> > code. So, the command indicates the values of DSCP and ECN that the
> > TWAMP Test Protocol Reflector should insert in its out-going packets
> > (these same values will be sent in the forward direction).
> >
> > But ECN works differently than DSCP: Perhaps the Reflector SHOULD
> > return ECN 11 CE in the IP header when it receives it and behave like
> > a normal ECN endpoint, in addition to returning the received DSCP and
> > ECN bits in the new field that this draft specifies (in payload).
> > This potentially revises my OPS-DIR comment, and I'm glad you
> > weighed-in to help sort this behavior.
> >
> > regards,
> > Al
> >
> >
> >
> >
> > ...
> >
> > > And "ECN-responsive" would mean what, specifically?  Whatever that
> > > is, now is probably not a good time to design it, unless it's
> > > something rather brute-force (e.g., if CE is seen, stop).  This may
> > > need to rely on low TWAMP sending rates, and caution that TWAMP can
> > > discard CE signals from the network.
> > >
> > > > I could live with saying that the *un-provisioned* DSCP should be
> > > > set to zero at the reflector, but we did not discuss that aspect
> > > > last
> > > night.
> > >
> > > That would be good.  It's probably ok to mention reflecting the DSCP
> > > and setting it to zero as possibilities - the mention solely of
> > > reflection of the DSCP comes across as a weak recommendation to do
> > > so, whereas mentioning multiple possibilities would be more
> balanced.
> > >
> > > > in the forward and reverse directions to set all reflected
> > > > (reverse path) DSCPs to zero (when DSCP and ECN are un-
> provisioned).
> > >
> > > Well, ECN is usually only set in one direction, so that testing
> > > approach for ECN would be realistic.
> > >
> > > Thanks,
> > > --David
> > >
> > > > > ----------------------------------------------------------------
> > > > > ----
> > > > > --
> > > > > COMMENT:
> > > > > ----------------------------------------------------------------
> > > > > ----
> > > > > --
> > > > >
> > > > > My apologies for thinking slowly ... but it doesn't look like
> > > > > these questions will be difficult to resolve.
> > > > >
> > > > > 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)?
> > > > >
> > > > > 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:
> > > > >
> > > > >    o  if the negotiated/provisioned DSCP value is not known
> (e.g.
> > > TWAMP
> > > > > 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?
> > > > >
> > > > [ACM]
> > > > I could live with saying that the *un-provisioned* DSCP should be
> > > > set to zero at the reflector, but we did not discuss that aspect
> > > > last
> > > night.
> > > >
> > > > in the forward and reverse directions to set all reflected
> > > > (reverse path) DSCPs to zero (when DSCP and ECN are un-
> provisioned).
> > > >
> > > > regards,
> > > > Al
> > > >

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 22 Oct 2015 16:04:11 +0000

Hi David, Al, et. al,
continuing very interesting thread:
> to zero at the reflector, but we did not discuss that aspect last night.

That would be good.  It's probably ok to mention reflecting the DSCP and setting it to zero as possibilities - the mention solely of reflection of the DSCP comes across as a weak recommendation to do so, whereas mentioning multiple possibilities would be more balanced.

Authors discussed the suggestion and I'll update the statement to the following:
	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.
	Alternatively Session-Reflector MAY set DSCP value to CS0 (zero) [RFC2474];

	Regards,
		Greg

-----Original Message-----
From: Black, David [mailto:[email-masked]] 
Sent: Thursday, October 22, 2015 5:32 AM
To: MORTON, ALFRED C (AL); Spencer Dawkins; The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; Black, David
Subject: RE: [ippm] Spencer Dawkins' Yes on draft-ietf-ippm-type-p-monitor-02: (with COMMENT)

>    Otherwise, the provisioned ECN value for the session SHALL be used.

I don't understand what "negotiated/provisioned" means for the ECN value because that's usually handled by the protocol (e.g., TCP), so TWAMP would have to do this for itself.  This differs from DSCP handling.

> Session-Senders and Reflectors need to be ECN-responsive ECT(1) is used.

And "ECN-responsive" would mean what, specifically?  Whatever that is, now is probably not a good time to design it, unless it's something rather brute-force (e.g., if CE is seen, stop).  This may need to rely on low TWAMP sending rates, and caution that TWAMP can discard CE signals from the network.

> to zero at the reflector, but we did not discuss that aspect last night.

That would be good.  It's probably ok to mention reflecting the DSCP and setting it to zero as possibilities - the mention solely of reflection of the DSCP comes across as a weak recommendation to do so, whereas mentioning multiple possibilities would be more balanced.

> DSCPs to zero (when DSCP and ECN are un-provisioned).

Well, ECN is usually only set in one direction, so that testing approach for ECN would be realistic.

Thanks,
--David

> Subject: RE: [ippm] Spencer Dawkins' Yes on draft-ietf-ippm-type-p-monitor-02:
> (with COMMENT)
> 
> Hi Spencer and David,
> 
> quick reply below,
> Al
> 
> > Session-Sender, and is that likely to cause problems in the reflected direction?
> >
> > His note to me follows:
> >
> > that the ECN field MUST be set to 0 (not-ECT) in the reflected packet, always.
> >
> Session-Senders and Reflectors need to be ECN-responsive ECT(1) is used.
> 
> to zero at the reflector, but we did not discuss that aspect last night.
>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 22 Oct 2015 17:51:11 -0400

Hi Greg, I noticed that this bullet’s wording:

o  the Session-Reflector MUST extract the S-DSCP-ECN value from the
   DSCP and ECN values of received packets;

seems to reverse the meaning of “extract”, and would probably
be better if worded:

o  the Session-Reflector MUST populate the S-DSCP-ECN value with the
   DSCP and ECN values extracted from the corresponding the received packet;

Sorry, I don’t know why I missed this before.
Otherwise, I think this is what we want.
thanks,
Al

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 12:40 PM
To: Spencer Dawkins; The IESG; MORTON, ALFRED C (AL); Black, David; Kathleen Moriarty ([email-masked]); Suresh Krishnan; Ben Campbell ([email-masked]); Alvaro Retana (aretana) ([email-masked])
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Spencer Dawkins' Yes on draft-ietf-ippm-type-p-monitor-02: (with COMMENT)

Dear All,

thank you all for your reviews, comments, help and patience.

Attached are:

·         diff with highlighted updates;

·         -03 version that includes all the updates.

Hope that you find your comments have been satisfactorily addressed.

                Regards,

                                Greg

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 4:45 AM
To: The IESG
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Spencer Dawkins' Yes on draft-ietf-ippm-type-p-monitor-02: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

COMMENT:

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 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?

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 22 Oct 2015 22:17:25 +0000

Hi Al,
thank you for your thorough check of the update. Would the following be acceptable:
the Session-Reflector MUST extract DSCP and ECN values from the received packet and MUST populate with them the S-DSCP-ECN field of the corresponding reflected packet;

                Regards,
                                Greg

From: MORTON, ALFRED C (AL) [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 2:51 PM
To: Gregory Mirsky; Spencer Dawkins; The IESG; Black, David; Suresh Krishnan
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Spencer Dawkins' Yes on draft-ietf-ippm-type-p-monitor-02: (with COMMENT)

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 12:40 PM
To: Spencer Dawkins; The IESG; MORTON, ALFRED C (AL); Black, David; Kathleen Moriarty ([email-masked]<mailto:[email-masked]>); Suresh Krishnan; Ben Campbell ([email-masked]<mailto:[email-masked]>); Alvaro Retana (aretana) ([email-masked]<mailto:[email-masked]>)
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Spencer Dawkins' Yes on draft-ietf-ippm-type-p-monitor-02: (with COMMENT)

Dear All,

Attached are:

                Regards,

                                Greg

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 4:45 AM
To: The IESG
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Spencer Dawkins' Yes on draft-ietf-ippm-type-p-monitor-02: (with COMMENT)

COMMENT:

His note to me follows:

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 22 Oct 2015 18:33:32 -0400

That’s fine, “extract: has to go with the received information.

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 6:17 PM
To: MORTON, ALFRED C (AL); Spencer Dawkins; The IESG; Black, David; Suresh Krishnan
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Spencer Dawkins' Yes on draft-ietf-ippm-type-p-monitor-02: (with COMMENT)

Hi Al,

                Regards,
                                Greg

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Dear All,

Attached are:

                Regards,

                                Greg

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 4:45 AM
To: The IESG
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Spencer Dawkins' Yes on draft-ietf-ippm-type-p-monitor-02: (with COMMENT)

COMMENT:

His note to me follows:

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 23 Oct 2015 14:13:02 -0500

I'm putting my summary of how other comments have been addressed in this
thread, just to keep everything in one place. Spoiler alert - they've
mostly been addressed! But please see below.

   - Alvero's comment - looks addressed, but there was a nit in the
   proposed text.
   - Benoit's comment - just referenced Al's OPSDIR review. Not addressed
   in this thread, but addressed in Al's OPSDIR review thread.
   - Ben's comment - looks addressed.
   - Al's OPSDIR review - looks addressed.
   - Suresh's Gen-ART review - looks addressed.
   - Kathleen's comment - looks addressed.
   - Spencer's comment - this was based on a conversation I had with David
   Black. It looks mostly addressed in the unsubmitted -03 version, with one
   question remaining.

In this text:

   o  if the negotiated/provisioned ECN value is not known, ECN SHOULD
       be set to Not-ECT codepoint value [RFC3168].  Otherwise, the
       provisioned ECN value for the session SHALL be used.

David pointed out that TWAMP isn't ECN-responsive. He said perhaps saying
"stop when CE=1" would make sense as the least complicated response
possible, but also said we're pretty late in the process to be making
changes like that. I agree on "pretty late", and also wonder if anything
that does need to be said about ECN with TWAMP belongs in another draft
(this one's describing an optional extension, so there's no reason anyone
would be looking at it for guidance about ECN).

I also noted that TWAMP hasn't been ECN-responsive since -00 of the
individual base protocol draft, so maybe this isn't urgent (simply because
sending rates are low enough that reflection packet rates are low enough
that they aren't significant contributors to congestion).

Is that the way it's looking to others?

Spencer

On Thu, Oct 22, 2015 at 5:33 PM, MORTON, ALFRED C (AL) <[email-masked]>
wrote:

> *From:* Gregory Mirsky [mailto:[email-masked]]
> *Sent:* Thursday, October 22, 2015 6:17 PM
> *To:* MORTON, ALFRED C (AL); Spencer Dawkins; The IESG; Black, David;
> Suresh Krishnan
>
> *Cc:* [email-masked]; [email-masked];
> [email-masked]
> *Subject:* RE: Spencer Dawkins' Yes on draft-ietf-ippm-type-p-monitor-02:
> (with COMMENT)
>
>
>
> Hi Al,
>
> the Session-Reflector MUST extract DSCP and ECN values from the received
> packet and MUST populate with them the S-DSCP-ECN field of the
> corresponding reflected packet;
>
>
>
>                 Regards,
>
>                                 Greg
>
>
>
>
>
> *From:* MORTON, ALFRED C (AL) [mailto:[email-masked] <[email-masked]>]
>
> *Sent:* Thursday, October 22, 2015 2:51 PM
> *To:* Gregory Mirsky; Spencer Dawkins; The IESG; Black, David; Suresh
> Krishnan
> *Cc:* [email-masked]; [email-masked];
> [email-masked]
> *Subject:* RE: Spencer Dawkins' Yes on draft-ietf-ippm-type-p-monitor-02:
> (with COMMENT)
>
>
>
> *From:* Gregory Mirsky [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Thursday, October 22, 2015 12:40 PM
> *To:* Spencer Dawkins; The IESG; MORTON, ALFRED C (AL); Black, David;
> Kathleen Moriarty ([email-masked]); Suresh Krishnan;
> Ben Campbell ([email-masked]); Alvaro Retana (aretana) ([email-masked]
> )
> *Cc:* [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* RE: Spencer Dawkins' Yes on draft-ietf-ippm-type-p-monitor-02:
> (with COMMENT)
>
>
>
> Dear All,
>
> From: Spencer Dawkins [mailto:[email-masked]
> <[email-masked]>]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> 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:
>
>
>
> 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.
>
>
>
> 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?
>
>
>
>
>

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 23 Oct 2015 14:38:59 -0500

On 23 Oct 2015, at 14:13, Spencer Dawkins at IETF wrote:

> * Ben's comment - looks addressed.

Yep.

Thanks!

Ben.

---

From: "Black, David" <[email-masked]>
Date: Thu, 22 Oct 2015 12:31:48 +0000

Thanks,
--David

> Cc: [email-masked]; [email-masked]; Black,
> David; [email-masked]

---

From: "Black, David" <[email-masked]>
Date: Thu, 22 Oct 2015 13:59:16 +0000

> ECN endpoint,

NOOO!!! ;-)

Thanks,
--David

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 22 Oct 2015 16:40:21 +0000

Dear All,

Attached are:

                Regards,

                                Greg

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 4:45 AM
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Spencer Dawkins' Yes on draft-ietf-ippm-type-p-monitor-02: (with COMMENT)

COMMENT:

His note to me follows:

---

From: "Black, David" <[email-masked]>
Date: Fri, 23 Oct 2015 19:23:02 +0000

David also doesn’t understand what “provisioned ECN value for the session” means.  Who/what provisions that value?

David hopes that Spencer is correct on “sending rates are low enough”.

Thanks,
--David

From: Spencer Dawkins at IETF [mailto:[email-masked]]
Sent: Friday, October 23, 2015 3:13 PM
To: MORTON, ALFRED C (AL)
Cc: Gregory Mirsky; The IESG; Black, David; Suresh Krishnan; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Spencer Dawkins' Yes on draft-ietf-ippm-type-p-monitor-02: (with COMMENT)

I'm putting my summary of how other comments have been addressed in this thread, just to keep everything in one place. Spoiler alert - they've mostly been addressed! But please see below.

  *   Alvero's comment - looks addressed, but there was a nit in the proposed text.
  *   Benoit's comment - just referenced Al's OPSDIR review. Not addressed in this thread, but addressed in Al's OPSDIR review thread.
  *   Ben's comment - looks addressed.
  *   Al's OPSDIR review - looks addressed.
  *   Suresh's Gen-ART review - looks addressed.
  *   Kathleen's comment - looks addressed.
  *   Spencer's comment - this was based on a conversation I had with David Black. It looks mostly addressed in the unsubmitted -03 version, with one question remaining.
In this text:

David pointed out that TWAMP isn't ECN-responsive. He said perhaps saying "stop when CE=1" would make sense as the least complicated response possible, but also said we're pretty late in the process to be making changes like that. I agree on "pretty late", and also wonder if anything that does need to be said about ECN with TWAMP belongs in another draft (this one's describing an optional extension, so there's no reason anyone would be looking at it for guidance about ECN).

I also noted that TWAMP hasn't been ECN-responsive since -00 of the individual base protocol draft, so maybe this isn't urgent (simply because sending rates are low enough that reflection packet rates are low enough that they aren't significant contributors to congestion).

Spencer

On Thu, Oct 22, 2015 at 5:33 PM, MORTON, ALFRED C (AL) <[email-masked]<mailto:[email-masked]>> wrote:
That’s fine, “extract: has to go with the received information.

From: Gregory Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, October 22, 2015 6:17 PM
To: MORTON, ALFRED C (AL); Spencer Dawkins; The IESG; Black, David; Suresh Krishnan

Hi Al,

                Regards,
                                Greg

Dear All,

Attached are:

•         diff with highlighted updates;

•         -03 version that includes all the updates.

                Regards,

                                Greg

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 4:45 AM
To: The IESG
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Spencer Dawkins' Yes on draft-ietf-ippm-type-p-monitor-02: (with COMMENT)

COMMENT:

His note to me follows:

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 23 Oct 2015 19:35:24 +0000

Hi David,
ECN is part of Type-P Descriptor according to OWAMP [RFC 4656] and can be configured through TWAMP-Control or by other means (CLI or Central Controller).

                Regards,
                                Greg

From: Black, David [mailto:[email-masked]]
Sent: Friday, October 23, 2015 12:23 PM
To: Spencer Dawkins at IETF; MORTON, ALFRED C (AL)
Cc: Gregory Mirsky; The IESG; Suresh Krishnan; [email-masked]; [email-masked]; [email-masked]; Black, David
Subject: RE: Spencer Dawkins' Yes on draft-ietf-ippm-type-p-monitor-02: (with COMMENT)

Thanks,
--David

Cc: Gregory Mirsky; The IESG; Black, David; Suresh Krishnan; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Spencer

Hi Al,

                Regards,
                                Greg

Dear All,

Attached are:

                Regards,

                                Greg

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 4:45 AM
To: The IESG
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Spencer Dawkins' Yes on draft-ietf-ippm-type-p-monitor-02: (with COMMENT)

COMMENT:

His note to me follows:

---

From: "Black, David" <[email-masked]>
Date: Fri, 23 Oct 2015 19:56:59 +0000

Ok, got it - “provisioned through TWAMP-Control or by other means (CLI or Central Controller)” would be clearer than “provisioned” for both DSCP and ECN.  This is mostly editorial.

Thanks, --David

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Friday, October 23, 2015 3:35 PM
To: Black, David; Spencer Dawkins at IETF; MORTON, ALFRED C (AL)
Cc: The IESG; Suresh Krishnan; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Spencer Dawkins' Yes on draft-ietf-ippm-type-p-monitor-02: (with COMMENT)

Hi David,

                Regards,
                                Greg

Cc: Gregory Mirsky; The IESG; Suresh Krishnan; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Black, David

Thanks,
--David

Spencer

Hi Al,

                Regards,
                                Greg

Dear All,

Attached are:

                Regards,

                                Greg

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 4:45 AM
To: The IESG
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Spencer Dawkins' Yes on draft-ietf-ippm-type-p-monitor-02: (with COMMENT)

COMMENT:

His note to me follows:

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 23 Oct 2015 20:01:33 +0000

Hi Spencer,

On 10/23/2015 03:13 PM, Spencer Dawkins at IETF wrote:
> # Suresh's Gen-ART review - looks addressed.

Yep. The changes look good to me.

Thanks
Suresh

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 23 Oct 2015 20:03:09 +0000

Hi David,
thank you. I’ll use this wording then in the updated text.

                Regards,
                                Greg

From: Black, David [mailto:[email-masked]]
Sent: Friday, October 23, 2015 12:57 PM
To: Gregory Mirsky; Spencer Dawkins at IETF; MORTON, ALFRED C (AL)
Cc: The IESG; Suresh Krishnan; [email-masked]; [email-masked]; [email-masked]; Black, David
Subject: RE: Spencer Dawkins' Yes on draft-ietf-ippm-type-p-monitor-02: (with COMMENT)

Thanks, --David

Cc: The IESG; Suresh Krishnan; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi David,

                Regards,
                                Greg

Thanks,
--David

Spencer

Hi Al,

                Regards,
                                Greg

Dear All,

Attached are:

                Regards,

                                Greg

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 4:45 AM
To: The IESG
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Spencer Dawkins' Yes on draft-ietf-ippm-type-p-monitor-02: (with COMMENT)

COMMENT:

His note to me follows:

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 23 Oct 2015 20:32:44 +0000

Hi David,
would the following be acceptable to address your comment (apologies for lengthy quote):
   The DSCP and ECN values (part of the Type-P Descriptor [RFC4656]) can
   be provisioned through TWAMP-Control or by other means (CLI or
   Central Controller).  The DSCP and ECN values are often copied into
   reflected test packets with current TWAMP implementations without
   TWAMP-Control protocol.  With DSCP and ECN Monitoring Extension, the
   Session-Reflector handles DSCP as following:

   o  the Session-Reflector MUST extract the DSCP and ECN values from
      the received packet and MUST populate with them S-DSCP-ECN field
      of the corresponding reflected packet;

   o  the Session-Reflector MUST transmit each reflected test packet
      with DSCP set to the provisioned value;

   o  if the 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.  Alternatively
      Session-Reflector MAY set DSCP value to CS0 (zero) [RFC2474];

   o  if the provisioned ECN value is not known, ECN SHOULD be set to
      Not-ECT codepoint value [RFC3168].  Otherwise, the provisioned ECN
      value for the session SHALL be used.

                Regards,
                                Greg

Thanks, --David

Hi David,

                Regards,
                                Greg

Thanks,
--David

Spencer

Hi Al,

                Regards,
                                Greg

Dear All,

Attached are:

                Regards,

                                Greg

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 4:45 AM
To: The IESG
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Spencer Dawkins' Yes on draft-ietf-ippm-type-p-monitor-02: (with COMMENT)

COMMENT:

His note to me follows:

---

From: "Black, David" <[email-masked]>
Date: Mon, 26 Oct 2015 00:04:28 +0000

Yes, that test looks reasonable.  Looking forward to the text on sending rate.

Thanks,
--David

Sent: Friday, October 23, 2015 4:33 PM

Hi David,

                Regards,
                                Greg

Cc: The IESG; Suresh Krishnan; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Black, David

Thanks, --David

Hi David,

                Regards,
                                Greg

Thanks,
--David

Spencer

Hi Al,

                Regards,
                                Greg

Dear All,

Attached are:

                Regards,

                                Greg

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 4:45 AM
To: The IESG
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Spencer Dawkins' Yes on draft-ietf-ippm-type-p-monitor-02: (with COMMENT)

COMMENT:

His note to me follows:

---

From: "Black, David" <[email-masked]>
Date: Mon, 26 Oct 2015 00:08:03 +0000

“test” -> “text” ;-)

From: Black, David
Sent: Sunday, October 25, 2015 8:04 PM
To: Gregory Mirsky; Spencer Dawkins at IETF; MORTON, ALFRED C (AL)
Cc: The IESG; Suresh Krishnan; [email-masked]; [email-masked]; [email-masked]; Black, David
Subject: RE: Spencer Dawkins' Yes on draft-ietf-ippm-type-p-monitor-02: (with COMMENT)

Thanks,
--David

Hi David,

                Regards,
                                Greg

Thanks, --David

Hi David,

                Regards,
                                Greg

Thanks,
--David

Spencer

Hi Al,

                Regards,
                                Greg

Dear All,

Attached are:

                Regards,

                                Greg

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 4:45 AM
To: The IESG
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Spencer Dawkins' Yes on draft-ietf-ippm-type-p-monitor-02: (with COMMENT)

COMMENT:

His note to me follows: