Subject: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT)

From: "Martin Stiemerling" <[email-masked]>
Date: Wed, 10 Jun 2015 13:35:36 -0700

Martin Stiemerling has entered the following ballot position for
draft-ietf-dime-congestion-flow-attributes-01: Discuss

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-dime-congestion-flow-attributes/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

No general objection to the publication of the document. However, I am
relaying a question from David Black as a DISCUSS point. 

I assume that the draft is more than unclear in Section 3.2  about what
traffic means. Is it a particular flow, a single packet, etc?

"I found an ECN concern, and hence added the TSV ADs to the CC line.

Section 3.2 says:

   The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped and
   indicates how congested traffic, i.e., traffic that has Explicit
   Congestion Notification Congestion Experienced marking set or some
   other administratively defined criteria, is treated.  

That appears to say that the congestion treatment may be applied
solely to packets that have the CE (Congestion Experienced) marking.
That would be a problem, because the defined semantics of a CE marking
is that it applies to the entire flow (e.g., causes TCP to react as if
a packet has been dropped), hence the congestion treatment ought
to apply to the entire flow.

In other words, one wants to be able to use the ECN-IP-Codepoint
AVP as part of the condition that determines whether the filter rule
matches, but ignore that AVP (i.e., wildcard it) in determining what
traffic the action applies to, so that the response to detecting a
congested flow (i.e., packets with ECN field containing CE) applies
to all packets in the flow, regardless of the value in the CE field.

Otherwise, the result may be ineffective, as it won't encompass packets
in the congested flow that aren't CE-marked.

Am I reading the draft correctly?"

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

Section 1, 1st paragraph: 
It says "The first AVP provides direct support for ECN [RFC3168] in the
IP header“. I am  sure that your draft is  ot providing any support for
ECN in the IP header, as we have ECN in the IP header already, isn't it.
I guess you mean something like this "The first AVP provides direct
support for filtering ECN marked traffic[RFC3168]“

---

From: "Bertz, Lyle T [CTO]" <[email-masked]>
Date: Thu, 11 Jun 2015 22:01:36 +0000

Martin,

Regarding the DISCUSS point the language in 3.2 is problematic, we will change

to

   The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped. It
   indicates how to treat traffic flow(s) when congestion is detected.
   The detection of the congestion can be based on the reception of IP
   packets packet  with  the CE (Congestion Experienced) codepoint set
  (see [RFC 3168]) or by any other administratively defined criteria.

The rationale for the word 'flow(s)' in the new language is the last sentence of the section  3.2 -  "The Congestion-Treatment AVP is an action and MUST be  an attribute of the Filter-Rule Grouped AVP as defined in RFC5777. "  It is other AVPs in the Filter-Rule, e.g. Classifier, that describes the scope of traffic impacted.  Saying something in Section 3.2 that does not associate the Congestion-Treatment AVP to the Filter-Rule it is a part of only creates confusion.

---------------------------------
Per the COMMENT, you are correct.  We'll change

"The first AVP provides direct support for ECN [RFC3168] in the IP
  header“

to your suggestion

"The first AVP provides direct support for filtering ECN
  marked traffic[RFC3168]“

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Martin Stiemerling
Sent: Wednesday, June 10, 2015 3:36 PM
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and 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.)

No general objection to the publication of the document. However, I am relaying a question from David Black as a DISCUSS point.

I assume that the draft is more than unclear in Section 3.2  about what traffic means. Is it a particular flow, a single packet, etc?

Section 3.2 says:

That appears to say that the congestion treatment may be applied solely to packets that have the CE (Congestion Experienced) marking.
That would be a problem, because the defined semantics of a CE marking is that it applies to the entire flow (e.g., causes TCP to react as if a packet has been dropped), hence the congestion treatment ought to apply to the entire flow.

In other words, one wants to be able to use the ECN-IP-Codepoint AVP as part of the condition that determines whether the filter rule matches, but ignore that AVP (i.e., wildcard it) in determining what traffic the action applies to, so that the response to detecting a congested flow (i.e., packets with ECN field containing CE) applies to all packets in the flow, regardless of the value in the CE field.

Otherwise, the result may be ineffective, as it won't encompass packets in the congested flow that aren't CE-marked.

Section 1, 1st paragraph:
It says "The first AVP provides direct support for ECN [RFC3168] in the IP header“. I am  sure that your draft is  ot providing any support for ECN in the IP header, as we have ECN in the IP header already, isn't it.
I guess you mean something like this "The first AVP provides direct support for filtering ECN marked traffic[RFC3168]“

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: "Bertz, Lyle T [CTO]" <[email-masked]>
Date: Fri, 12 Jun 2015 00:59:29 +0000

David,

Traffic flow(s) are IP (5-tuple) flow(s).

My question to you is would it be best to say "IP flows" or "IP (5-tuple) flows" or "5-tuple flows"?   I am unsure of the best wording here.  This treatment applies to all packets associated to all 5-tuples (flows) captured by the Filter-Rule.

A Filter-Rule may contain a Classifier that describes one or many 5-tuples per RFC 5777.

Thanks.
Lyle

-----Original Message-----
From: Black, David [mailto:[email-masked]]
Sent: Thursday, June 11, 2015 5:15 PM
To: Bertz, Lyle T [CTO]; Martin Stiemerling; The IESG
Cc: [email-masked]; [email-masked]; Black, David
Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT)

Lyle,

>   (see [RFC 3168]) or by any other administratively defined criteria.

What does "traffic flow(s)" mean in this text?

A clear explanation of that should remove the concern that this draft might be applying congestion treatment to just the CE-marked packets and not the entire 5-tuple (or more).

Thanks,
--David

> From: Bertz, Lyle T [CTO] [mailto:[email-masked]]
> Sent: Thursday, June 11, 2015 6:02 PM
> To: Martin Stiemerling; The IESG
> Cc: Black, David; [email-masked]; [email-masked]
> Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-
> congestion-flow-attributes-01: (with DISCUSS and COMMENT)
>
> Martin,
>
> The rationale for the word 'flow(s)' in the new language is the last
> sentence of the section  3.2 -  "The Congestion-Treatment AVP is an
> action and MUST be an attribute of the Filter-Rule Grouped AVP as
> defined in RFC5777. "  It is other AVPs in the Filter-Rule, e.g.
> Classifier, that describes the scope of traffic impacted.  Saying
> something in Section 3.2 that does not associate the
> Congestion-Treatment AVP to the Filter-Rule it is a part of only creates confusion.
>
> Subject: [Dime] Martin Stiemerling's Discuss on
> draft-ietf-dime-congestion-
> flow-attributes-01: (with DISCUSS and COMMENT)
>
> 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
> I assume that the draft is more than unclear in Section 3.2  about
> what traffic means. Is it a particular flow, a single packet, etc?
>
> a packet has been dropped), hence the congestion treatment ought to
> apply to the entire flow.
>
> In other words, one wants to be able to use the ECN-IP-Codepoint AVP
> as part of the condition that determines whether the filter rule
> congested flow (i.e., packets with ECN field containing CE) applies to
> all packets in the flow, regardless of the value in the CE field.
>
> Otherwise, the result may be ineffective, as it won't encompass
> packets in the congested flow that aren't CE-marked.
>
> It says "The first AVP provides direct support for ECN [RFC3168] in
> the IP header“. I am  sure that your draft is  ot providing any
> support for ECN in the IP header, as we have ECN in the IP header already, isn't it.
> This e-mail may contain Sprint proprietary information intended for
> the sole use of the recipient(s). Any use by others is prohibited. If
> you are not the intended recipient, please contact the sender and
> delete all copies of the message.

---

From: "Black, David" <[email-masked]>
Date: Thu, 11 Jun 2015 22:15:05 +0000

Lyle,

A clear explanation of that should remove the concern that this draft might be
applying congestion treatment to just the CE-marked packets and not the entire
5-tuple (or more).

Thanks,
--David

> The rationale for the word 'flow(s)' in the new language is the last sentence
> of the section  3.2 -  "The Congestion-Treatment AVP is an action and MUST be
> an attribute of the Filter-Rule Grouped AVP as defined in RFC5777. "  It is
> other AVPs in the Filter-Rule, e.g. Classifier, that describes the scope of
> traffic impacted.  Saying something in Section 3.2 that does not associate the
> Subject: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-
> 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.)
> 
> 
> That appears to say that the congestion treatment may be applied solely to
> packets that have the CE (Congestion Experienced) marking.
> That would be a problem, because the defined semantics of a CE marking is that
> it applies to the entire flow (e.g., causes TCP to react as if a packet has
> been dropped), hence the congestion treatment ought to apply to the entire
> flow.
> 
> In other words, one wants to be able to use the ECN-IP-Codepoint AVP as part
> of the condition that determines whether the filter rule matches, but ignore
> that AVP (i.e., wildcard it) in determining what traffic the action applies
> to, so that the response to detecting a congested flow (i.e., packets with ECN
> field containing CE) applies to all packets in the flow, regardless of the
> value in the CE field.
> 
> It says "The first AVP provides direct support for ECN [RFC3168] in the IP
> header“. I am  sure that your draft is  ot providing any support for ECN in
> the IP header, as we have ECN in the IP header already, isn't it.
> I guess you mean something like this "The first AVP provides direct support
> for filtering ECN marked traffic[RFC3168]“
> 
> 
> This e-mail may contain Sprint proprietary information intended for the sole
> use of the recipient(s). Any use by others is prohibited. If you are not the
> intended recipient, please contact the sender and delete all copies of the
> message.