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

[Kathleen Moriarty <[e-mail]>]

Martin,

Could you please verify that your concerns have been addressed?  I believe
they have been.

Thank you!
Kathleen

On Mon, Jun 22, 2015 at 5:08 AM, <[e-mail]> wrote:

>  Hi,
>
>
>
> Martin, do you please confirm that the proposed correction answers your
> concerns identified in the DISCUSS? I'm waiting for a go-ahead before
> authorizing authors to submit a new version of the draft.
>
>
>
> Regards,
>
>
>
> Lionel
>
>
>
> *De :* Black, David [mailto:[e-mail]]
> *Envoyé :* vendredi 12 juin 2015 20:55
> *À :* Bertz, Lyle T [CTO]; MORAND Lionel IMT/OLN; Martin Stiemerling; The
> IESG
> *Cc :* [e-mail]; [e-mail]; Black, David
> *Objet :* RE: Re : [Dime] Martin Stiemerling's Discuss on
> draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT)
>
>
>
> With that extra “packet” dropped ;-), the proposed text looks good enough
>
> for my concern.  I’ll leave any further adjustment to Martin, as he’s
> holding
>
> the Discuss.
>
>
>
> Many thanks for the prompt attention to this, and (as noted earlier), I’m
>
> pleased that this was not an actual design problem.
>
>
>
> Thanks,
> --David
>
>
>
> *From:* Bertz, Lyle T [CTO] [mailto:[e-mail]
> <[e-mail]>]
> *Sent:* Friday, June 12, 2015 2:22 PM
> *To:* [e-mail]; Black, David; Martin Stiemerling; The IESG
> *Cc:* [e-mail]; [e-mail]
> *Subject:* RE: Re : [Dime] Martin Stiemerling's Discuss on
> draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT)
>
>
>
> <sigh>… Even my corrections have errors this week.
>
> *From:* [e-mail] [mailto:[e-mail]
> <[e-mail]>]
> *Sent:* Friday, June 12, 2015 1:12 PM
> *To:* Bertz, Lyle T [CTO]; Black, David; Martin Stiemerling; The IESG
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re : [Dime] Martin Stiemerling's Discuss on
> draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT)
>
>
>
> Except that a "packets packet" is maybe too explicit! :)
>
>
>
> (Second sentence)
>
> Please wait for a formal go-ahead from the AD or myself before submitting
> a new version.
>
>
>
> Regards,
>
>
>
> Lionel
>
>
>
> Envoyé depuis mon mobile Orange
>
>
>
> ----- Reply message -----
> De : "Bertz, Lyle T [CTO]" <[e-mail]>
> Pour : "Black, David" <[e-mail]>, "Martin Stiemerling" <
> [e-mail]>, "The IESG" <[e-mail]>
> Cc : "[e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>
> Objet : [Dime] Martin Stiemerling's Discuss on
> draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT)
> Date : ven., juin 12, 2015 19:32
>
>
>
> 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:[e-mail] <[e-mail]>]
> Sent: Friday, June 12, 2015 10:33 AM
> To: Bertz, Lyle T [CTO]; Martin Stiemerling; The IESG
> Cc: [e-mail]; [e-mail]; 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:[e-mail]
> <[e-mail]>]
> > Sent: Thursday, June 11, 2015 8:59 PM
> > To: Black, David; Martin Stiemerling; The IESG
> > Cc: [e-mail]; [e-mail]
> > 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:[e-mail] <[e-mail]>]
> > Sent: Thursday, June 11, 2015 5:15 PM
> > To: Bertz, Lyle T [CTO]; Martin Stiemerling; The IESG
> > Cc: [e-mail]; [e-mail]; 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:[e-mail]
> <[e-mail]>]
> > > Sent: Thursday, June 11, 2015 6:02 PM
> > > To: Martin Stiemerling; The IESG
> > > Cc: Black, David; [e-mail]; [e-mail]
> > > 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:[e-mail] <[e-mail]>] On
> Behalf Of Martin
> > > Stiemerling
> > > Sent: Wednesday, June 10, 2015 3:36 PM
> > > To: The IESG
> > > Cc: [e-mail]; [e-mail]; [e-mail]
> > > 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
> > > [e-mail]
> > > 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.
>
> _________________________________________________________________________________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
> Thank you.
>
>
>  ------------------------------
>
>
> 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.
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>


-- 

Best regards,
Kathleen