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

David,

Thanks for the guidance here.  We definitely want to meet the goals you note below.

I will assume Martin has no objection to "IP (5-tuple) flows".  If so, we can adjust the language.

New language (I also changed 'In case the" to "If the" at the beginning of the next paragraph.

> >    The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped. It
> >    indicates how to treat traffic IP (5-tuple) 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.
> >
> >   A Filter-Rule may contain a Classifier that describes one or many 5-tuples per
> >   RFC 5777.  This treatment applies to all packets associated to all 5-tuples (flows) > >   captured by the Filter-Rule.
> >
> >   If the Congestion-Treatment AVP is absent...

I believe this language meets the objectives outlined below.

Thank you.
Lyle

-----Original Message-----
From: Black, David [mailto:david.black@emc.com]
Sent: Friday, June 12, 2015 10:33 AM
To: Bertz, Lyle T [CTO]; Martin Stiemerling; The IESG
Cc: dime@ietf.org; dime-chairs@ietf.org; Black, David
Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT)

Lyle,

Thanks for the explanation - for my concern, I think we're close to done...

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

That's a relief - I'm glad that we're only dealing with editorial concerns in the draft, and not an actual design problem.

> My question to you is would it be best to say "IP flows" or "IP
> (5-tuple) flows" or "5-tuple flows"?

I like "IP (5-tuple) flows" - Martin?

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

Please add that latter sentence ("This treatment applies ...") to the draft ...

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

... and please add that sentence also ;-).

The goal is to be clear that:
- adding an ECN-IP-Codepoint AVP to a Classifier still results in the
Classifier describing 5-tuple flows (as opposed to subsets of 5-tuple
flows that contain a specific value or values in the ECN field); and
- hence, the Congestion-Treatment AVP applies to 5-tuples and not to
anything smaller.

Thanks,
--David

> -----Original Message-----
> From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com]
> Sent: Thursday, June 11, 2015 8:59 PM
> To: Black, David; Martin Stiemerling; The IESG
> Cc: dime@ietf.org; dime-chairs@ietf.org
> Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-
> congestion-flow-attributes-01: (with DISCUSS and COMMENT)
>
> 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:david.black@emc.com]
> Sent: Thursday, June 11, 2015 5:15 PM
> To: Bertz, Lyle T [CTO]; Martin Stiemerling; The IESG
> Cc: dime@ietf.org; dime-chairs@ietf.org; Black, David
> Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-
> congestion-flow-attributes-01: (with DISCUSS and COMMENT)
>
> Lyle,
>
> >    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.
>
> 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
>
> > -----Original Message-----
> > From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com]
> > Sent: Thursday, June 11, 2015 6:02 PM
> > To: Martin Stiemerling; The IESG
> > Cc: Black, David; dime@ietf.org; dime-chairs@ietf.org
> > Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-
> > congestion-flow-attributes-01: (with DISCUSS and COMMENT)
> >
> > Martin,
> >
> > Regarding the DISCUSS point the language in 3.2 is problematic, we
> > will change
> >
> >    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.
> >
> > 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:dime-bounces@ietf.org] On Behalf Of Martin
> > Stiemerling
> > Sent: Wednesday, June 10, 2015 3:36 PM
> > To: The IESG
> > Cc: david.black@emc.com; dime@ietf.org; dime-chairs@ietf.org
> > Subject: [Dime] Martin Stiemerling's Discuss on
> > draft-ietf-dime-congestion-
> > flow-attributes-01: (with DISCUSS and COMMENT)
> >
> > 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-att
> > ri
> > butes/
> >
> >
> >
> > --------------------------------------------------------------------
> > --
> > 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]“
> >
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > 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.
>
> ________________________________
>
> 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.

________________________________

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.