Re: [Aeon] Comments and next step proposal

["Fan, Peng" <[e-mail]>]

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:[e-mail]] On Behalf Of [e-mail]
Sent: Thursday, April 24, 2014 4:41 PM
To: [e-mail]; [e-mail]
Subject: Re: [Aeon] Comments and next step proposal

 

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 J

 

BR,

Pierrick

 

 

From: Aeon [mailto:[e-mail]] On Behalf Of Fan, Peng
Sent: Tuesday, April 22, 2014 7:48 PM
To: [e-mail]
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.

 

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

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