Subject: Re: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attributes-00 - Use Cases

From: Jouni Korhonen <[email-masked]>
Date: Tue, 15 Jul 2014 20:25:57 +0300

Brent,

I do agree with your conclusion that adding examples would be minimal 
incremental addition to what RFC5777 already has. Also, IMHO use cases 
for ECN should be rather well known. I see no reason to add text for 
"topic 2".

- Jouni

4/29/2014 5:35 PM, Hirschman, Brent B [CTO] kirjoitti:
> At IETF 89 in London, during the discussion of the
> draft-ietf-dime-congestion-flow-attributes-00.txt, Two areas were
> requested to be investigated further.  We will be addressing them in
> separate email threads to keep the discussion focused on each topic.
> This is Topic 2:
>
> Second, we were requested to investigate providing example use cases of
> ECN.  RFC5777 already provides a set of use cases for reporting and ECN
> is just one of many such reporting parameters such as byte count.
> Adding a paragraph of text such as the following may add some
> information but the authors feel little incremental information is
> needed because of the work already in RFC 5777.
>
> “Diameter nodes along the bearer path can implement filters to collect
> accounting and policy control information based on these congestion
> parameters similar to byte count information. These filters on flows and
> overall node congestion for these AVPs can report a measure of quality
> of byte counts to collection points in the network where decisions can
> be made to mitigate or mediate any congestion conditions for accounting
> or real time policy control. These AVPs provide supplemental information
> as described in the use cases discussed in RFC5777.”
>
> Thus, the authors are proposing no modification to the working group
> draft at this time.  Comments are welcome.
>
> */Brent Hirschman/*
>
> Tech Dev Strategist III
>
> Sprint Corporation
>
> 6220 Sprint Parkway
>
> Overland Park, KS 66251//
>
> Office – 913-762-6736
>
> Mobile – 913-593-6221
>
>
> ------------------------------------------------------------------------
>
> 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.
>
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>

---

From: <[email-masked]>
Date: Mon, 21 Jul 2014 14:44:16 +0000

Agreed

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Jouni Korhonen
Envoyé : mardi 15 juillet 2014 19:26
À : Hirschman, Brent B [CTO]; [email-masked]
Cc : Rajagopal, Arun [CTO]; Sershen, Dan J [CTO]
Objet : Re: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attributes-00 - Use Cases

Brent,

- Jouni

4/29/2014 5:35 PM, Hirschman, Brent B [CTO] kirjoitti:
> "Diameter nodes along the bearer path can implement filters to collect
> as described in the use cases discussed in RFC5777."
>
> Office - 913-762-6736
> Mobile - 913-593-6221

_________________________________________________________________________________________________________________________

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.

---

From: <[email-masked]>
Date: Mon, 21 Jul 2014 15:16:41 +0000

I agreed on the wrong email! :)

We have experienced several IETF last calls on similar drafts and the feedback is always the same: difficult to see how the AVPs defined by this new draft are managed by the sending and receiving entities. Moreover, the relation with the RFC5777 should be clarified. For instance, it is really difficult to understand a simplem sentence like:

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de [email-masked]
Envoyé : lundi 21 juillet 2014 16:44
À : Jouni Korhonen; Hirschman, Brent B [CTO]; [email-masked]
Cc : Rajagopal, Arun [CTO]; Sershen, Dan J [CTO]
Objet : Re: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attributes-00 - Use Cases

Agreed

-----Message d'origine-----

Brent,

- Jouni

---

From: <[email-masked]>
Date: Mon, 21 Jul 2014 15:32:26 +0000

>From a technical point of view, this draft is ready for WGLC. However, from an editorial aspect, I think that we could improve the document.

We have experienced several IETF last calls on similar drafts and the feedback is always the same: difficult to see how the AVPs defined by this new draft are really used over Diameter and managed by the sending and receiving entities. Moreover, the relation with the RFC3168 and RFC5777 should be clarified. For instance, it is really difficult to understand a simple section like section 3.1:

   The ECN-IP-Codepoint AVP (AVP Code TBD) is of type Enumerated and
   specifies the Explicit Congestion Notification codepoint values to
   match in the IP header.

   Value | Binary | Keyword                            | References
   -----------------------------------------------------------------
   0     | 00     | Non-ECT (Not ECN-Capable Transport)| [RFC3168]
   1     | 01     | ECT(1) (ECN-Capable Transport)     | [RFC3168]
   2     | 10     | ECT(0) (ECN-Capable Transport)     | [RFC3168]
   3     | 11     | CE (Congestion Experienced)        | [RFC3168]

   When this AVP is used for classification in the Filter-Rule it MUST
   be part of Classifier Grouped AVP as defined in RFC5777.

We should explain why it is used in this Grouped AVP and how this new AVP will be used, how the values are set, etc.
So I would suggest to add some extra text if you want to avoid to spend too much during the LC process.

Regards,

Lionel

-----Message d'origine-----

Agreed

-----Message d'origine-----

Brent,

- Jouni