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

[<[e-mail]>]

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]]
Sent: Friday, June 12, 2015 2:22 PM
To: [e-mail]<mailto:[e-mail]>; Black, David; Martin Stiemerling; The IESG
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]> [mailto:[e-mail]]
Sent: Friday, June 12, 2015 1:12 PM
To: Bertz, Lyle T [CTO]; Black, David; Martin Stiemerling; The IESG
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>>
Pour : "Black, David" <[e-mail]<mailto:[e-mail]>>, "Martin Stiemerling" <[e-mail]<mailto:[e-mail]>>, "The IESG" <[e-mail]<mailto:[e-mail]>>
Cc : "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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]]
Sent: Friday, June 12, 2015 10:33 AM
To: Bertz, Lyle T [CTO]; Martin Stiemerling; The IESG
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]]
> Sent: Thursday, June 11, 2015 8:59 PM
> To: Black, David; Martin Stiemerling; The IESG
> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]]
> Sent: Thursday, June 11, 2015 5:15 PM
> To: Bertz, Lyle T [CTO]; Martin Stiemerling; The IESG
> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]]
> > Sent: Thursday, June 11, 2015 6:02 PM
> > To: Martin Stiemerling; The IESG
> > Cc: Black, David; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]] On Behalf Of Martin
> > Stiemerling
> > Sent: Wednesday, June 10, 2015 3:36 PM
> > To: The IESG
> > Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[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.