Subject: [Aeon] Comments and next step proposal

From: "Fan, Peng" <[email-masked]>
Date: Tue, 22 Apr 2014 19:47:41 +0800

Hello all,

Based on our operational experience, we have submitted a draft:
http://datatracker.ietf.org/doc/draft-fan-intarea-conet-ps-uc/ 

The purposes of this draft are to encourage less DPI in the network and
propose more cooperation between OTT and Operators. Please kindly help to
review the draft and comment here.

I have also reviewed the draft:

http://datatracker.ietf.org/doc/draft-eckel-aeon-problem-statement/,

My comments are:

1)       Shall we consider to split the section 4 into an independent gap
analysis document?

2)       For the requirements section, we agree Req. 1, 2, and 7, and just
want to clarify:

a)         Req. 3 and 4, do you expect the interaction between network node
and host here before the real traffic start?

b)         Req. 5 and 8 are not quite clear to us.

c)         I guess that it not always mandatory to apply Diffserv here, it
could be optional?

3)       If you read our draft, we have more experience about the limitation
of current DPI/DFI in section 3.

4)       Analysis of other existing solutions like ACL configuration can
also be added in section 3.

Also for the draft:

http://datatracker.ietf.org/doc/draft-eckel-aeon-use-cases/

Here I feel that too many use cases are listed here. You may consider
narrowing down to a few use cases for which we have strong and specific
needs, in order to get work further progressed.

After reading the current work proposed here, we are wondering whether two
groups of people could work together to propose a BoF in the coming IETF
meeting. To do that, we probably can:

1)       Merge the PS draft into one document.

2)       Write an independent use case document.

3)       Write an gap analysis document.

Once all three documents have finished, we could talk to ADs from both
Internet and Transport area about the next step?

Thanks a lot for your consideration.

Best regards,

Peng

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 23 Apr 2014 03:31:29 +0000

Hi, all,

This is a real requirement from network operation perspective. Both ISPs and ICPs can benefit from this advance collaborative network model.

Rong Zhang and I are working on an gap analysis document, which we hope to share publically early next week.

Best regards,

Sheng

From: Aeon [mailto:[email-masked]] On Behalf Of Fan, Peng
Sent: Tuesday, April 22, 2014 7:48 PM
To: [email-masked]
Subject: [Aeon] Comments and next step proposal

Hello all,

Based on our operational experience, we have submitted a draft: http://datatracker.ietf.org/doc/draft-fan-intarea-conet-ps-uc/
The purposes of this draft are to encourage less DPI in the network and propose more cooperation between OTT and Operators. Please kindly help to review the draft and comment here.

1)      Shall we consider to split the section 4 into an independent gap analysis document?

2)      For the requirements section, we agree Req. 1, 2, and 7, and just want to clarify:

a)       Req. 3 and 4, do you expect the interaction between network node and host here before the real traffic start?

c)        I guess that it not always mandatory to apply Diffserv here, it could be optional?

3)      If you read our draft, we have more experience about the limitation of current DPI/DFI in section 3.

4)      Analysis of other existing solutions like ACL configuration can also be added in section 3.

Also for the draft:
http://datatracker.ietf.org/doc/draft-eckel-aeon-use-cases/
Here I feel that too many use cases are listed here. You may consider narrowing down to a few use cases for which we have strong and specific needs, in order to get work further progressed.

After reading the current work proposed here, we are wondering whether two groups of people could work together to propose a BoF in the coming IETF meeting. To do that, we probably can:

3)      Write an gap analysis document.
Once all three documents have finished, we could talk to ADs from both Internet and Transport area about the next step?

Best regards,
Peng

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 23 Apr 2014 06:08:30 +0000

Hi Peng,

Please see inline [TR]

From: Aeon [mailto:[email-masked]] On Behalf Of Fan, Peng
Sent: Tuesday, April 22, 2014 5:18 PM
To: [email-masked]
Subject: [Aeon] Comments and next step proposal

Hello all,

a)       Req. 3 and 4, do you expect the interaction between network node and host here before the real traffic start ?

[TR] The interaction between the network node and host could be before or after the real traffic starts.

b)       Req. 5 and 8 are not quite clear to us.
[TR] Req. 8 is saying that the flow characteristics signaled by the client to the network should have protection against man-in-middle attacker modifying the flow metadata.

I guess that it not always mandatory to apply Diffserv here, it could be optional?

[TR] Yes, Diffserv is optional.  FYI DART WG is recently formed (https://www.ietf.org/mailman/listinfo/dart) to document the limitations of Diffserv.

[TR] Yes, http://tools.ietf.org/html/draft-eckel-aeon-use-cases-01#section-2.4.8 also discusses similar problem and possible solution to address the problem.

Also for the draft:

[TR] Agreed, we are updating the use case draft.

After reading the current work proposed here, we are wondering whether two groups of people could work together to propose a BoF in the coming IETF meeting.

[TR] Sounds like a good plan to me.

Cheers,
-Tiru

To do that, we probably can:

Best regards,
Peng

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 23 Apr 2014 14:30:42 +0000

Please see addition comment inline.

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 22, 2014 at 11:08 PM
To: "Fan, Peng" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Aeon] Comments and next step proposal

Hi Peng,

Please see inline [TR]

From: Aeon [mailto:[email-masked]] On Behalf Of Fan, Peng
Sent: Tuesday, April 22, 2014 5:18 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Aeon] Comments and next step proposal

Hello all,

The flow descriptions could change over time due to changes in application operation, and the network feedback could change as well as the network conditions change.

Req 5 is about incremental deployability. Various heuristic based mechanisms, including DPI, are being used with some success in many networks. These should continue to work as portions of the applications and network are enabled with the functionality proposed in AEON.

Yes, good point.

Also for the draft:

Sounds good to me as well.

Cheers,
Charles

Cheers,
-Tiru

Best regards,
Peng

---

From: <[email-masked]>
Date: Thu, 24 Apr 2014 08:41:26 +0000

Hi Peng, Hui,

Thanks for having informed me about the AEON effort, which is really interesting.
I had a quick look on draft-fan-intarea-conet-ps-uc and I have a short comment (just to check that we are on the same page): if I understand well the last paragraph of the introduction, the ICP could provide its traffic characteristics so that it makes traffic identification easier for the ISP. Such statement is a bit confusing since it seems to advocate for DPI improvement, while, IMHO, the goal of AEON should be to get rid of DPI (at least to relax dependency to DPI). I think the ICP should rather indicate its requirement (e.g. application QoS requirements) to network policy control function (e.g. PCRF in 3GPP network) in order to negotiate network resource before the application session starts, then the ICP should be able to update requirements and re-negotiate resources during the session (but we may also want to keep DPI to update network resource during a session…).

BTW, is content based charging really implemented somewhere? It seems to be a nightmare for the customer ☺

BR,
Pierrick

Hello all,

Also for the draft:

Best regards,
Peng

_________________________________________________________________________________________________________________________

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: "Fan, Peng" <[email-masked]>
Date: Thu, 24 Apr 2014 19:52:59 +0800

He Pierrick,

Many thanks for the comments. I agree the goal of this work is to achieve no DPI or less DPI. With traffic characteristics provided by ICPs, network can better identify traffic flows of applications, without DPI (if the characteristics are easy to be detected by network elements) or with some level of DPI (if the characteristics hide deeply in the packet). But even with DPI involved, flow identification is not heuristic any more, as applications have provided traffic characteristics. Requirement of network resource is also information sent by ICPs.

Content based charging is already deployed in China. For example, Alibaba has the cooperation with China Mobile and China Unicom for the charge of its traffic.

Best regards,

Peng

From: Aeon [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, April 24, 2014 4:41 PM
To: [email-masked]; [email-masked]
Subject: Re: [Aeon] Comments and next step proposal

Hi Peng, Hui,

BTW, is content based charging really implemented somewhere? It seems to be a nightmare for the customer J

BR,

Pierrick

Hello all,

My comments are:

Also for the draft:

Best regards,

Peng

---

From: "Fan, Peng" <[email-masked]>
Date: Thu, 24 Apr 2014 19:56:43 +0800

Hi Charles, Tiru,

Thanks for your kind reply and explanation.

Let's make a next step plan after this thread discussion has concluded.

Best regards,

Peng

From: Charles Eckel (eckelcu) [mailto:[email-masked]] 
Sent: Wednesday, April 23, 2014 10:31 PM
To: Tirumaleswar Reddy (tireddy); Fan, Peng; [email-masked]
Subject: Re: [Aeon] Comments and next step proposal

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tuesday, April 22, 2014 at 11:08 PM
To: "Fan, Peng" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Aeon] Comments and next step proposal

Hi Peng,

Please see inline [TR]

Hello all,

My comments are:

[TR] The interaction between the network node and host could be before or
after the real traffic starts.

The flow descriptions could change over time due to changes in application
operation, and the network feedback could change as well as the network
conditions change.

[TR] Req. 8 is saying that the flow characteristics signaled by the client
to the network should have protection against man-in-middle attacker
modifying the flow metadata.

Req 5 is about incremental deployability. Various heuristic based
mechanisms, including DPI, are being used with some success in many
networks. These should continue to work as portions of the applications and
network are enabled with the functionality proposed in AEON.

I guess that it not always mandatory to apply Diffserv here, it could be
optional?

[TR] Yes, Diffserv is optional.  FYI DART WG is recently formed
(https://www.ietf.org/mailman/listinfo/dart) to document the limitations of
Diffserv.

[TR] Yes,
http://tools.ietf.org/html/draft-eckel-aeon-use-cases-01#section-2.4.8 also
discusses similar problem and possible solution to address the problem.

Yes, good point.

Also for the draft:

meeting. 

Cheers,

Charles

Cheers,

-Tiru

Best regards,

Peng

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 24 Apr 2014 22:42:26 +0000

Peng,

Questions inserted below:

[Linda] is the charging based on total traffic volume? Or is it based on specific applications? Will Alibaba agree to attach some identifier of their specific application to their data packets?

Thanks,
Linda

---

From: "Fan, Peng" <[email-masked]>
Date: Sun, 27 Apr 2014 17:16:52 +0800

Hi Linda,

Thanks for the question. The data packets are not attached with some identifiers. We are thinking that current methods for content based charging are not enough to meet operational needs. That is why we need to have this work discussed and started, and that is also something we need to identify in the gap analysis.

Best regards,

Peng

From: Linda Dunbar [mailto:[email-masked]] 
Sent: Friday, April 25, 2014 6:42 AM
To: Fan, Peng; [email-masked]; [email-masked]
Subject: RE: [Aeon] Comments and next step proposal

Peng, 

Thanks, 

Linda