Subject: Re: [Aeon] Comments and next step proposal

From: Rong Zhang <[email-masked]>
Date: Wed, 23 Apr 2014 16:11:12 +0800

Hi all,

Speaking as the operator, I do see this trend that OTT are working with
operators today which will help to improve the mobile internet user
experience dramatically.

I have one basic comment that current documents have n't talked about 3GPP
PCRF Rx interface which will allow OTT to work with today's mobile
operator, I will work with Sheng to write the gap analysis document by
including how IETF work could be a complimentary to 3GPP's specificaiton.

I am planning to attend next IETF meeting, and hope BoF will happen, I
personally feel it is more Intarea scope than transport.

Cheers.

-Rong ZHANG

On Wed, Apr 23, 2014 at 11:31 AM, Sheng Jiang <[email-masked]> wrote:

>  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.
>
>
>
> 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
>
> _______________________________________________
> Aeon mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aeon
>
>

---

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

Hi Rong,

I do not claim to be a 3GPP expert, so please correct me if I have it wrong. The way I see it, the 3GPP Rx interface provides a means for AEON to interact with the existing 3GPP architecture. One problem for 3GPP is how to get the necessary information to be conveyed over the Rx interface. AEON can be used for end applications to communicate this information to the 3GPP network for consumption over the Rx interface. In 3GPP, I do not believe end applications have direct access to the Rx interface. AEON fills that gap.
As for whether the work proceeds in intarea or transport, the original guidance from the ADs of both areas was to start in transport. Once we have the updated drafts in place, we can certainly revisit that decision.

Cheers,
Charles

From: Rong Zhang <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, April 23, 2014 at 1:11 AM
To: Sheng Jiang <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Fan, Peng" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Aeon] Comments and next step proposal

Hi all,

Speaking as the operator, I do see this trend that OTT are working with operators today which will help to improve the mobile internet user experience dramatically.

I have one basic comment that current documents have n't talked about 3GPP PCRF Rx interface which will allow OTT to work with today's mobile operator, I will work with Sheng to write the gap analysis document by including how IETF work could be a complimentary to 3GPP's specificaiton.

I am planning to attend next IETF meeting, and hope BoF will happen, I personally feel it is more Intarea scope than transport.

Cheers.

-Rong ZHANG

On Wed, Apr 23, 2014 at 11:31 AM, Sheng Jiang <[email-masked]<mailto:[email-masked]>> wrote:
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]<mailto:[email-masked]>] On Behalf Of Fan, Peng
Sent: Tuesday, April 22, 2014 7:48 PM
To: [email-masked]<mailto:[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

_______________________________________________
Aeon mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/aeon

---

From: Hui Deng <[email-masked]>
Date: Wed, 23 Apr 2014 22:42:31 +0800

Hi Rong,

Thanks for your feedback, I guess that you raised one of key point that
3GPP may also consider today about interaction between operators and OTT, I
guess that today Rx interface are still diameter based, they may consider
other high layer protocols as well in the future. but in that case, I think
that they are more focusing on server side negotiation without involvement
client information, for example, client is sitting behind of NAT. and some
other granularity information.

I am cc to Farooq who is quite expert in this field.

Best regards,

-Hui

2014-04-23 16:11 GMT+08:00 Rong Zhang <[email-masked]>:

> On Wed, Apr 23, 2014 at 11:31 AM, Sheng Jiang <[email-masked]>wrote:
>
>>  Hi, all,
>>
>>
>>
>> a)       Req. 3 and 4, do you expect the interaction between network
>> node and host here before the real traffic start?
>>
>> 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:
>>

---

From: Hui Deng <[email-masked]>
Date: Wed, 23 Apr 2014 22:46:22 +0800

Hi Charles,

Rx interface rely on application server to communicate with network
infrastructure, but IS that sufficient and more dynamical, realtime.

Will see whether Farooq could kindly help to explain it.

Best regards,

-Hui

2014-04-23 22:37 GMT+08:00 Charles Eckel (eckelcu) <[email-masked]>:

>  Hi Rong,
>
>  I do not claim to be a 3GPP expert, so please correct me if I have it
> wrong. The way I see it, the 3GPP Rx interface provides a means for AEON to
> interact with the existing 3GPP architecture. One problem for 3GPP is how
> to get the necessary information to be conveyed over the Rx interface. AEON
> can be used for end applications to communicate this information to the
> 3GPP network for consumption over the Rx interface. In 3GPP, I do not
> believe end applications have direct access to the Rx interface. AEON fills
> that gap.
> As for whether the work proceeds in intarea or transport, the original
> guidance from the ADs of both areas was to start in transport. Once we have
> the updated drafts in place, we can certainly revisit that decision.
>
>  Cheers,
> Charles
>
>   From: Rong Zhang <[email-masked]>
> To: Sheng Jiang <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Fan,
> Peng" <[email-masked]>

---

From: "BARI, FAROOQ" <[email-masked]>
Date: Wed, 23 Apr 2014 17:38:40 +0000

Thanks Hui for forwarding this thread. The Rx interface is between an application server in the network and a 3GPP policy server (that can influence IP flow’s assigned QoS). Currently Rx interface uses Diameter to carry QoS needs for a session to the 3GPP network. How the application server becomes aware of the IP session’s QoS needs is application dependent. For example in the case of IMS SDP information carried along with SIP messages provides this type of information to the application server. In other application types it maybe some other protocol or some proprietary means by which the application server is able to identify particular IP flow’s QoS needs. TDF (similar to DPI) in 3GPP  is an additional tool along with Rx interface in this discussion where the network can identify certain service types via packet inspection to provide them with necessary QoS (rather than explicit signaling via Rx).  I do not have enough data to say whether this functionality is sufficient or if more is needed.

BTW I am not subscribed to aeon – so I assume my response will get rejected from that email list ☺.

BR,

Farooq Bari, PhD
Lead Member Technical Staff
Standards & Industry Alliances
AT&T Services, Inc.

Email: [email-masked]<mailto:[email-masked]>
Tel: +1 425 580 5526

This e-mail and any files transmitted with it are AT&T property, are confidential, and are intended solely for the use of the individual or entity to whom this email is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited

From: Hui Deng [mailto:[email-masked]]
Sent: Wednesday, April 23, 2014 7:46 AM
To: Charles Eckel (eckelcu)
Cc: Rong Zhang; Sheng Jiang; [email-masked]; Fan, Peng; BARI, FAROOQ
Subject: Re: [Aeon] Comments and next step proposal

Hi Charles,

Rx interface rely on application server to communicate with network infrastructure, but IS that sufficient and more dynamical, realtime.

Best regards,

-Hui

2014-04-23 22:37 GMT+08:00 Charles Eckel (eckelcu) <[email-masked]<mailto:[email-masked]>>:
Hi Rong,

Cheers,
Charles

Hi all,

Cheers.

-Rong ZHANG

Best regards,

Sheng

Hello all,

Also for the draft:

Best regards,
Peng

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 23 Apr 2014 18:50:01 +0000

Hi Farooq,

Thank you for sharing your insights. I just accepted the pending request to post your message to the alias, so it should be available via the list soon.
Please see additional comments inline.

From: <BARI>, FAROOQ <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, April 23, 2014 at 10:38 AM
To: Hui Deng <[email-masked]<mailto:[email-masked]>>, Charles Eckel <[email-masked]<mailto:[email-masked]>>
Cc: Rong Zhang <[email-masked]<mailto:[email-masked]>>, Sheng Jiang <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Fan, Peng" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Aeon] Comments and next step proposal

Thanks Hui for forwarding this thread. The Rx interface is between an application server in the network and a 3GPP policy server (that can influence IP flow’s assigned QoS). Currently Rx interface uses Diameter to carry QoS needs for a session to the 3GPP network. How the application server becomes aware of the IP session’s QoS needs is application dependent. For example in the case of IMS SDP information carried along with SIP messages provides this type of information to the application server.

Viewing the SDP means either being in the application signaling path and being able to decrypt the encrypted SIP/SDP messages. For OTT this will not be possible, so we need another mechanism.

In other application types it maybe some other protocol or some proprietary means by which the application server is able to identify particular IP flow’s QoS needs. TDF (similar to DPI) in 3GPP  is an additional tool along with Rx interface in this discussion where the network can identify certain service types via packet inspection to provide them with necessary QoS (rather than explicit signaling via Rx).  I do not have enough data to say whether this functionality is sufficient or if more is needed.

Such heuristic based mechanisms will face difficulties when it comes to OTT applications. I think this is a good use case to be addressed by AEON, to use explicit and standards based communication between the application and the network to achieve what is currently achieved through a combination of proprietary mechanisms and heuristics. Would you be able to propose some text for that use case, or to review some text if I take a shot at it.

Cheers,
Charles

BTW I am not subscribed to aeon – so I assume my response will get rejected from that email list :).

BR,

Farooq Bari, PhD

Cc: Rong Zhang; Sheng Jiang; [email-masked]<mailto:[email-masked]>; Fan, Peng; BARI, FAROOQ

Hi Charles,

Best regards,

-Hui

Cheers,
Charles

Hi all,

Cheers.

-Rong ZHANG

Best regards,

Sheng

Hello all,

Also for the draft:

Best regards,
Peng

---

From: Hui Deng <[email-masked]>
Date: Thu, 24 Apr 2014 23:08:32 +0800

Thank you, Farooq, I believe you are Mr. PCRF, thanks for your advice about
gap.
Inline please with two discussions.

2014-04-24 1:38 GMT+08:00 BARI, FAROOQ <[email-masked]>:

>  Thanks Hui for forwarding this thread. The Rx interface is between an
> application server in the network and a 3GPP policy server (that can
> influence IP flow’s assigned QoS). Currently Rx interface uses Diameter to
> carry QoS needs for a session to the 3GPP network. How the application
> server becomes aware of the IP session’s QoS needs is application
> dependent. For example in the case of IMS SDP information carried along
> with SIP messages provides this type of information to the application
> server. In other application types it maybe some other protocol or some
> proprietary means by which the application server is able to identify
> particular IP flow’s QoS needs.
>
I understand that Rx can identify QoS needs, and does Rx can identify IP
sessions based on diameter signaling? can we think that will be sufficient
to identify the IP session, do we still have space to allow IETF to work on
this？

> TDF (similar to DPI) in 3GPP  is an additional tool along with Rx
> interface in this discussion where the network can identify certain service
> types via packet inspection to provide them with necessary QoS (rather than
> explicit signaling via Rx).  I do not have enough data to say whether this
> functionality is sufficient or if more is needed.
>
This two directions have only one difference that whether UE/client's
involvement is useful or not.

Thanks again for your advice

Best regards,

-Hui

>
>
> BTW I am not subscribed to aeon – so I assume my response will get
> rejected from that email list J.
>
>
>
>
>
> BR,
>
>
>
> Farooq Bari, PhD
> Email: [email-masked]
> Tel: +1 425 580 5526
>
>
>
> This e-mail and any files transmitted with it are AT&T property, are
> confidential, and are intended solely for the use of the individual or
> entity to whom this email is addressed. If you are not one of the named
> recipient(s) or otherwise have reason to believe that you have received
> this message in error, please notify the sender and delete this message
> immediately from your computer. Any other use, retention, dissemination,
> forwarding, printing, or copying of this e-mail is strictly prohibited
>
>
>
> *From:* Hui Deng [mailto:[email-masked]]
> *Sent:* Wednesday, April 23, 2014 7:46 AM
> *To:* Charles Eckel (eckelcu)
> *Cc:* Rong Zhang; Sheng Jiang; [email-masked]; Fan, Peng; BARI, FAROOQ
>
> *Subject:* Re: [Aeon] Comments and next step proposal
>
>
>
> Hi Charles,
>
>
>
> *From: *Rong Zhang <[email-masked]>
> *Date: *Wednesday, April 23, 2014 at 1:11 AM
> *To: *Sheng Jiang <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Fan,
> *Subject: *Re: [Aeon] Comments and next step proposal
>
>
>
>   Hi all,
>
>
>