Re: [Aeon] Collaborative network proposal

Hi Charles,

I see these limitations existing in the network, and causing difficulty in
effective traffic operation. I think we should address the limitations too
and come to a solution for network and user/application to know each other
better. That would help us a lot in cooperating with ICPs.

Regards,

Peng

发件人: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] 
发送时间: 2014年3月25日 3:20
收件人: Fan, Peng; Hui Deng
抄送: Tirumaleswar Reddy (tireddy); aeon@ietf.org; Ted Lemon; Anton Smith
主题: Re: [Aeon] Collaborative network proposal

Hui and Peng,

Your draft fits very well with the problem statement and use cases discussed
within AEON. It provides valuable insights into the ISP/ICP relationship and
how it can be improved. In addition to those mentioned previously in this
thread, limitations AEON aims to address include:

1) Lack of ability for end user or application to express the relative
priority of this applications traffic or with respect to other applications
or other traffic within this same application (e.g. one video stream more
important than another) .

2) Lack of ability for network to provide explicit feedback to application
regarding network conditions such as congestion, pre-configured limitations,
etc. For example, the network drops packets arbitrarily rather than telling
the application the network conditions and enabling the application to adapt
its traffic accordingly.

Do you agree these limitations exist currently within ISP networks, and do
you see it being within the scope of AEON to address these limitations as
well?

Cheers,

Charles

From: Anton Smith <anton.smith@ericsson.com>
Date: Friday, March 21, 2014 at 9:32 AM
To: Charles Eckel <eckelcu@cisco.com>
Cc: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>om>, "Fan, Peng"
<fanpeng@chinamobile.com>om>, Hui Deng <denghui02@gmail.com>om>, "aeon@ietf.org"
<aeon@ietf.org>rg>, Ted Lemon <Ted.Lemon@nominum.com>
Subject: Re: [Aeon] Collaborative network proposal

Hi all,

I've been lurking but another consideration of course is that DPI doesn't
scale in terms of bps/forwarding.

Regards

Anton

Sent from my iPhone

On 21 mar 2014, at 17:19, "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
wrote:

I agree. Network operators need ways to categorize and provide
differentiated services for traffic, but relying on DPI is error prone,
cumbersome, and potentially done at the expense of user privacy and
application security (e.g. shared keys made available to DPI enabled middle
boxes or HTTP proxies ). In the end, much more information about the user
and the application are revealed than was actually needed by the network
operator to achieve their goals. By eliminating reliance on DPI we reduce
the incentive and justification for such practices.

Cheers,

Charles

From: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
Date: Friday, March 21, 2014 at 5:06 AM
To: "Fan, Peng" <fanpeng@chinamobile.com>om>, 'Hui Deng' <denghui02@gmail.com>om>,
"aeon@ietf.org" <aeon@ietf.org>rg>, 'Ted Lemon' <Ted.Lemon@nominum.com>
Subject: Re: [Aeon] Collaborative network proposal

Hi Peng,

I think DPI should be retired. In addition to the below problems you had
mentioned in the draft, it’s the same problem with WebRTC where DPI would
fail for signaling traffic. WebRTC framework allows any proprietary
signaling to be used, so DPI/ALG will not be able to understand the control
traffic (Even if middle boxes somehow magically figure to act as TLS proxy).
Both home and access network will not be able to identify and prioritize the
media streams.

Cheers,

-Tiru

From: Fan, Peng [mailto:fanpeng@chinamobile.com] 
Sent: Thursday, March 20, 2014 5:20 PM
To: Tirumaleswar Reddy (tireddy); 'Hui Deng'; aeon@ietf.org; 'Ted Lemon'
Subject: RE: [Aeon] Collaborative network proposal

Hi Tiru,

Yes, encrypted traffic is another supporting point. I guess it is time we
consider finding a way to retire or simplify DPI functions.

Regards,

Peng

From: Aeon [ <mailto:aeon-bounces@ietf.org> mailto:aeon-bounces@ietf.org] On
Behalf Of Tirumaleswar Reddy (tireddy)
Sent: Thursday, March 20, 2014 3:03 PM
To: Hui Deng;  <mailto:aeon@ietf.org> aeon@ietf.org; Ted Lemon
Subject: Re: [Aeon] Collaborative network proposal

Hi Hui,

The other problem is that when content providers and clients move to TLS for
privacy reasons, the current DPI mechanisms used by middle boxes will fail. 

You may want to look into
<http://tools.ietf.org/html/draft-eckel-aeon-use-cases-00#section-2.5.1>
http://tools.ietf.org/html/draft-eckel-aeon-use-cases-00#section-2.5.1 which
discusses similar problems with CDN and possible solutions.

Thanks and Regards,

-Tiru

From: Aeon [ <mailto:aeon-bounces@ietf.org> mailto:aeon-bounces@ietf.org] On
Behalf Of Hui Deng
Sent: Thursday, March 20, 2014 7:09 AM
To:  <mailto:aeon@ietf.org> aeon@ietf.org; Ted Lemon
Subject: [Aeon] Collaborative network proposal

Hello all.

We just submitted a draft to propose the concept of the collaborative
network as below link:

http://www.ietf.org/id/draft-fan-intarea-conet-ps-uc-00.txt

Our basic ideal is that there are many similar use cases as AEON, so we post
here to seek for more comments whether we could work together

Here we cc to Int Area AD Ted.

Thanks a lot

-Hui

_______________________________________________
Aeon mailing list
Aeon@ietf.org
https://www.ietf.org/mailman/listinfo/aeon