Re: [Aeon] Comments and next step proposal

[<[e-mail]>]

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

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.