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