From nobody Sun Mar 2 05:52:22 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E191A0722 for ; Sun, 2 Mar 2014 05:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GhTRrAKospG for ; Sun, 2 Mar 2014 05:52:19 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id E1F0E1A070D for ; Sun, 2 Mar 2014 05:52:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=331; q=dns/txt; s=iport; t=1393768336; x=1394977936; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=NY7gKvHCfhAbsQRZj/0H9AoNAyBfsbk5xNHdJfaSaBA=; b=ddEWBXAPeK9qi7wdebEbIAyuMKckQJ+BxivLIV1aFkpxDT7jDA/8/0lY YMXh+E4G+qXdeZQsCQN9sRhWbt5ne/28tkXDfvojaUUnvNuAjja6hPpNd Pn12T6FjyLps/AzZKsbc/lY4roUPO5h3HHEcVrySDQj+gD5WqTMKTeOLU o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAGg2E1OtJV2Y/2dsb2JhbABagwY7V8IzFnSCLDpRAT5CJwSIDA2cBq9OEwSTGASYPJIrgy2CKg X-IronPort-AV: E=Sophos;i="4.97,572,1389744000"; d="scan'208";a="24306006" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP; 02 Mar 2014 13:52:16 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s22DqGfS007144 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 2 Mar 2014 13:52:16 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.8]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Sun, 2 Mar 2014 07:52:15 -0600 From: "Charles Eckel (eckelcu)" To: "aeon@ietf.org" Thread-Topic: AEON meeting at IETF 89 - update Thread-Index: AQHPNh6etSLK47/9x0qk06ZQFy9AUg== Date: Sun, 2 Mar 2014 13:52:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.117.143] Content-Type: text/plain; charset="us-ascii" Content-ID: <16A7EEE1543D2C4DB5DA7583E81194D7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/OHF6RgM8H62EeK1D48dK7MC3DC4 Subject: [Aeon] AEON meeting at IETF 89 - update X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 13:52:20 -0000 The AEON site page has been updated with the latest info about our meeting tomorrow, including the finalized agenda and additional details on the location. I have uploaded some slides as well. https://sites.google.com/site/aeonsignalling/home/upcoming-meetings I look forward to seeing you all tomorrow. Cheers, Charles From nobody Mon Mar 3 08:30:43 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E562D1A023E for ; Mon, 3 Mar 2014 08:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.037 X-Spam-Level: X-Spam-Status: No, score=-15.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNvclz2X-sY8 for ; Mon, 3 Mar 2014 08:30:35 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id EF7831A0240 for ; Mon, 3 Mar 2014 08:30:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9477; q=dns/txt; s=iport; t=1393864232; x=1395073832; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=tt323XyQuyLjTMxrUdDtWBQ9xwT3YwNRPaAMDs0V8n0=; b=e00Au8lb2TvfEK8j9oPmgvTVR/3uIRFo7bkPOJs19Vw4jCASFNX2TQVU Tlvqq1msSp9FJzVhxbPzFR4u2ZTwY5FxJjriWPOM6D7zyRuE9VHVL3ti2 NFCG0guSYInE2C//wUHBvXkvXQkvXAeV5qTk2KBDvKoyrKSHi0/MBvZF7 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwFABWtFFOtJXG9/2dsb2JhbABAFwOCREQ4Vbw2gSMWAXSDfQEBAQQpBiYRIwIBAgYRAwECFQQMAwcyFAcBAQUCAQIBAxOIBA02r1STbxeOMBEBDB4VAQwLEQeEHgSYFoEwkGSCWVKBcTk X-IronPort-AV: E=Sophos;i="4.97,863,1389744000"; d="scan'208,217";a="304653286" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 03 Mar 2014 16:30:31 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s23GUVLL028249 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 3 Mar 2014 16:30:31 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.8]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Mon, 3 Mar 2014 10:30:31 -0600 From: "Charles Eckel (eckelcu)" To: "aeon@ietf.org" Thread-Topic: Please join now, meeting in progress: My Meeting Thread-Index: AQHPNv3DwGqgc1Ion0eZI0oW4OyclprP8mIA Importance: high X-Priority: 1 Date: Mon, 3 Mar 2014 16:30:30 +0000 Message-ID: References: <47849295.50714.1393864141241.JavaMail.nobody@jsj6tc107.webex.com> In-Reply-To: <47849295.50714.1393864141241.JavaMail.nobody@jsj6tc107.webex.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.115.52] Content-Type: multipart/alternative; boundary="_000_CF3A5E9021761eckelcuciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/IZM_y1UmgY0K0fDwa4G83o9uikc Subject: [Aeon] FW: Please join now, meeting in progress: My Meeting X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 16:30:38 -0000 --_000_CF3A5E9021761eckelcuciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Charles Eckel > Reply-To: Charles Eckel > Date: Monday, March 3, 2014 at 4:29 PM To: Charles Eckel > Subject: Please join now, meeting in progress: My Meeting Hello Charles Eckel, Please join my meeting that is currently in progress. Topic: My Meeting Date: Monday, March 3, 2014 Time: 8:27 am, Pacific Standard Time (San Francisco, GMT-08:00) Meeting Number: 209 990 784 Meeting Password: aeon ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ciscosales.webex.com/ciscosales/e.php?MTID=3Dme6b3fc121d4f= 7a1d3469688e2f206995 2. Enter your name and email address. 3. Enter the meeting password: aeon 4. Click "Join Now". 5. Follow the instructions that appear on your screen. To view in other time zones or languages, please click the link: https://ciscosales.webex.com/ciscosales/e.php?MTID=3Dmb0bd80fe5f66ef1135d01= f984950685b ---------------------------------------------------------------- ALERT =96 PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE (4= 08) OR (919) AREA CODES ---------------------------------------------------------------- Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 Dialing the WebEx toll free numbers from within 408 or 919 area codes is no= t enabled (non-Cisco phones). =93 If you dial the toll-free numbers within = the 408 or 919 area codes you will be instructed to hang up and dial the lo= cal access number.=94 Please use the call-back option whenever possible and= otherwise dial local numbers only. The affected toll free numbers are: (86= 6) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP a= rea. ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access = Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ciscosales.webex.com/ciscosales/mc 2. On the left navigation bar, click "Support". You can contact me at: eckelcu@cisco.com 1--408-525 7569 http://www.webex.com CCP:+14085256800x209990784# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. --_000_CF3A5E9021761eckelcuciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <487611510A84A84E95DF6E2830505592@emea.cisco.com> Content-Transfer-Encoding: quoted-printable


From: Charles Eckel <messenger@webex.com>
Reply-To: Charles Eckel <eckelcu@cisco.com>
Date: Monday, March 3, 2014 at 4:29= PM
To: Charles Eckel <eckelcu@cisco.com>
Subject: Please join now, meeting i= n progress: My Meeting

Hel= lo Charles Eckel,

Please join my meeting that is currently in progress.

Topic: My Meeting
Date: Monday, March 3, 2014
Time: 8:27 am, Pacific Standard Time (San Francisco, GMT-08:00)
Meeting Number: 209 990 784
Meeting Password: aeon


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://ciscosales.webex.com/ciscosales/e.php?MTID=3Dme6b3fc121d4f7a1d34696= 88e2f206995
2. Enter your name and email address.
3. Enter the meeting password: aeon
4. Click "Join Now".
5. Follow the instructions that appear on your screen.

To view in other time zones or languages, please click the link:
https://ciscosales.webex.com/cisc= osales/e.php?MTID=3Dmb0bd80fe5f66ef1135d01f984950685b

----------------------------------------------------------------
ALERT =96 PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE (4= 08) OR (919) AREA CODES
----------------------------------------------------------------
Please dial the local access number for your area from the list below:
- San Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330

Dialing the WebEx toll free numbers from within 408 or 919 area codes is no= t enabled (non-Cisco phones). =93 If you dial the toll-free numbers within = the 408 or 919 area codes you will be instructed to hang up and dial the lo= cal access number.=94 Please use the call-back option whenever possible and otherwise dial local numbers only. = The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita= s area and (866) 349-3520 for the RTP area.

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
1. Dial into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferen= cing/index.html
2. Follow the prompts to enter the Meeting Number (listed above) or Access = Code followed by the # sign.

San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117

India: +91.80.4350.1111 Germany: +49.619.6773.9002

Japan: +81.3.5763.9394 China: +86.10.8515.5666

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://ciscosales.webex.com/ciscosales/mc
2. On the left navigation bar, click "Support".

You can contact me at:
eckelcu@cisco.com
1--408-525 7569




http://www.webex.com=

CCP:+14085256800x209990784#

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the= start of the recording or do not join the session. Please note that any su= ch recordings may be subject to discovery in the event of litigation.
--_000_CF3A5E9021761eckelcuciscocom_-- From nobody Mon Mar 3 09:31:46 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DECE1A02F7 for ; Mon, 3 Mar 2014 09:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpXhtoxXo1Ih for ; Mon, 3 Mar 2014 09:31:33 -0800 (PST) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id 57AF51A02EF for ; Mon, 3 Mar 2014 09:31:33 -0800 (PST) Received: from jsaldanapc (dhcp-a7b4.meeting.ietf.org [31.133.167.180]) (authenticated bits=0) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id s23HVMLI018579 for ; Mon, 3 Mar 2014 18:31:22 +0100 From: "Jose Saldana" To: Date: Mon, 3 Mar 2014 17:31:22 -0000 Message-ID: <008601cf3706$65b3d710$311b8530$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0087_01CF3706.65B55DB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac83BhjMJB36qkRjQ2KUUcf4Bdxw0Q== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/3MxB13O63XEQA9anSzcAn9-UTSg Subject: [Aeon] A paper about Skype and Vidyo adaptation when network conditions change X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 17:31:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0087_01CF3706.65B55DB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, During the discussion today in London we have talked about how applications are able to self-adapt to network conditions. Perhaps you may find this paper interesting: http://downloads.hindawi.com/journals/tswj/2014/860170.pdf We put a bandwidth limitation, additional delay and packet loss between the two nodes making a video conference and we saw how the applications adapted their traffic. Best regards, Jose Saldana ------=_NextPart_000_0087_01CF3706.65B55DB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

During the discussion today in London we have talked about = how applications are able to self-adapt to network = conditions.

 

Perhaps you may find this paper interesting: http:= //downloads.hindawi.com/journals/tswj/2014/860170.pdf

 

We put a bandwidth limitation, additional delay and packet = loss between the two nodes making a video conference and we saw how the = applications adapted their traffic.

 

Best = regards,

 

Jose Saldana

------=_NextPart_000_0087_01CF3706.65B55DB0-- From nobody Sun Mar 9 11:08:47 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9629E1A02C2 for ; Sun, 9 Mar 2014 11:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.447 X-Spam-Level: X-Spam-Status: No, score=-7.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBhXFp_125ez for ; Sun, 9 Mar 2014 11:08:34 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3B01A028C for ; Sun, 9 Mar 2014 11:08:34 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 09 Mar 2014 11:08:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,619,1389772800"; d="scan'208,217";a="495067004" Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34]) by fmsmga002.fm.intel.com with ESMTP; 09 Mar 2014 11:08:28 -0700 Received: from fmsmsx104.amr.corp.intel.com ([169.254.4.214]) by FMSMSX103.amr.corp.intel.com ([169.254.3.43]) with mapi id 14.03.0123.003; Sun, 9 Mar 2014 11:08:28 -0700 From: "Feng, Wu-chi" To: "aeon@ietf.org" Thread-Topic: Meeting minutes for AEON discussion Thread-Index: Ac87woBoR1YQyMS+QJKcRaJkUscKVQ== Date: Sun, 9 Mar 2014 18:08:28 +0000 Message-ID: <35CD9086F35C8944A930BB1F40CF22944036FD3A@FMSMSX104.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.200.108] Content-Type: multipart/alternative; boundary="_000_35CD9086F35C8944A930BB1F40CF22944036FD3AFMSMSX104amrcor_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/Iwu1e2FLZNMxufgU3kIm2xQ8CZk Subject: [Aeon] Meeting minutes for AEON discussion X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 18:08:42 -0000 --_000_35CD9086F35C8944A930BB1F40CF22944036FD3AFMSMSX104amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, It was good to see such a large turnout at the AEON discussion at IETF 89. = Here are the meeting minutes... There was quite the lively discussion and= I tried to capture most of the comments that were raised. I will add my c= omments in a different e-mail to the list. Regards, Wu-chi In attendance: approximately 30 people Agenda *) Problem statement review - Charles Eckel *) Opinions from people Charles went over the problem statement and had discussions regarding quest= ions / comments people had. Some of the discussion points included: *) Some comments regarding quality of service The goal is to be able to benefit applications *) Is adaptation a focus? Yes, it is. Perhaps, this need to be brought up more clearly in the draf= t. *) Are there other flow characteristics that are not QoS related? In some routing, you may want to avoid parts of the network. An example = of not routing through a particular country came up. *) A brief discussion regarding whether the goal of AEON is to benefit te s= ervice provider or the user. The goal is to do both. If you can't help both then there would be no ne= ed to use the protocol. That is, if the user isn't benefiting, then it wou= ldn't use AEON. Similarly, if the network doesn't benefit, it would ignore= the messages *) Discussion regarding the TAPS BOF occurring on Wednesday. There seems to be a bit of a complementary interaction between these TAPS: Users-> transport services AEON: application (transport) -> network It was acknowledged that this might be useful. Having people in the room= that were interested in TAPS is useful. *) How do you do scaling, aggregating, bundling of flows It is up to us to define. There was a bit of discussion regarding what i= t meant for an application to bundle its flows together and how the network= might react to it. Clearly, AEON will need to address such bundling. *) Discussion regarding whether the network can trust the declaration and w= hether or not it is the same as diff-serv It depends on what is being shared and how the network is using it. In t= he simple case the applications may not have a reason to lie and feedback f= rom the network may be information (here, the app benefits from feedback an= d the network benefits from essentially having the app better behave / matc= h up to the network resources). More complicated scenarios may need authen= tication. This will need to be discussed. *) Authentication, flow control, admission control, etc seems overly comple= x There was a discussion that if we did need authentication that it would r= aise the complexity level significantly. In total, it will depend upon wha= t the action required is... the more complex, the mor need for authenticat= ion. A point was brought up regarding DSCPs and that they were not meant t= o do policy. It was also noted that AEON is intended to do both sending an= d receiving policy for a user.. *) Comment regarding QoS only being needed when the network is overloaded. A response was that the network could use it to optimize routing decision= s. For example, splitting network traffic over wired and satellite links (= or not routing through particular areas) *) Comment regarding Skype working over everything, why bother? It seems a basic cost / benefit analysis might be useful. If people deve= loping Skype want to incorporate AEON, the app needs to benefit for the add= ed complexity. It might be useful to do such an analysis. *) Comment regarding perhaps getting more application folks involved, other= wise might be an issue There seemed to be general consensus that this was a good idea... otherwi= se it might never be used. There was a discussion about the WebRTC WG as well as the STUN / Malice w= ork ongoing. *) Question regarding where is enforcement of AEON? Could be information or enforcement. It could be done at any network dev= ice (e.g., AP, L2 / L3 router / switch). Anything that sees the packet cou= ld act on the flow --_000_35CD9086F35C8944A930BB1F40CF22944036FD3AFMSMSX104amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi,

= It was good to see such a large turnout at the AEON discussion at IETF 89.&= nbsp; Here are the meeting minutes...  There was quite the lively disc= ussion and I tried to capture most of the comments that were raised.  I will add my comments in a different e-mail to the lis= t.

=  

= Regards,

= Wu-chi

=  

= In attendance: approximately 30 people

=  

= Agenda

=   *) Problem statement review – Charles Eckel<= /p>

=   *) Opinions from people

=  

= Charles went over the problem statement and had discussions regarding quest= ions / comments people had.

=  

= Some of the discussion points included:

=  

= *) Some comments regarding quality of service

=   The goal is to be able to benefit applications

=  

= *) Is adaptation a focus?

=   Yes, it is.  Perhaps, this need to be brought up more clearly i= n the draft.

=  

= *) Are there other flow characteristics that are not QoS related?

=   In some routing, you may want to avoid parts of the network.  A= n example of not routing through a particular country came up. 

=  

= *) A brief discussion regarding whether the goal of AEON is to benefit te s= ervice provider or the user.

=   The goal is to do both.  If you can’t help both then ther= e would be no need to use the protocol.  That is, if the user isn̵= 7;t benefiting, then it wouldn’t use AEON.  Similarly, if the ne= twork doesn’t benefit, it would ignore the messages

=  

= *) Discussion regarding the TAPS BOF occurring on Wednesday.

=   There seems to be a bit of a complementary interaction between these=

=   TAPS: Users-> transport services

=   AEON: application (transport) -> network

=  

=   It was acknowledged that this might be useful.  Having people i= n the room that were interested in TAPS is useful.

=  

= *) How do you do scaling, aggregating, bundling of flows<= /p>

=   It is up to us to define.  There was a bit of discussion regard= ing what it meant for an application to bundle its flows together and how t= he network might react to it.  Clearly, AEON will need to address such bundling.

=  

= *) Discussion regarding whether the network can trust the declaration and w= hether or not it is the same as diff-serv

=   It depends on what is being shared and how the network is using it.&= nbsp; In the simple case the applications may not have a reason to lie and = feedback from the network may be information (here, the app benefits from feedback and the network benefits from essentially havin= g the app better behave / match up to the network resources).  More co= mplicated scenarios may need authentication.  This will need to be dis= cussed.

=  

= *) Authentication, flow control, admission control, etc seems overly comple= x

=   There was a discussion that if we did need authentication that it wo= uld raise the complexity level significantly.  In total, it will depen= d upon what the action required is...  the more complex, the mor need for authentication.  A point was brought up regarding DS= CPs and that they were not meant to do policy.  It was also noted that= AEON is intended to do both sending and receiving policy for a user..=

=  

= *) Comment regarding QoS only being needed when the network is overloaded.<= o:p>

=   A response was that the network could use it to optimize routing dec= isions.  For example, splitting network traffic over wired and satelli= te links (or not routing through particular areas)

=  

= *) Comment regarding Skype working over everything, why bother?<= /span>

=   It seems a basic cost / benefit analysis might be useful.  If p= eople developing Skype want to incorporate AEON, the app needs to benefit f= or the added complexity.  It might be useful to do such an analysis.

=  

=  

= *) Comment regarding perhaps getting more application folks involved, other= wise might be an issue

=   There seemed to be general consensus that this was a good idea... ot= herwise it might never be used.

=  

=   There was a discussion about the WebRTC WG as well as the STUN / Mal= ice work ongoing.

=  

= *) Question regarding where is enforcement of AEON?

=   Could be information or enforcement.  It could be done at any n= etwork device (e.g., AP, L2 / L3 router / switch).  Anything that sees= the packet could act on the flow

 

--_000_35CD9086F35C8944A930BB1F40CF22944036FD3AFMSMSX104amrcor_-- From nobody Wed Mar 12 13:39:09 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648101A0761 for ; Wed, 12 Mar 2014 13:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.047 X-Spam-Level: X-Spam-Status: No, score=-10.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTOeG2dXrZCT for ; Wed, 12 Mar 2014 13:39:01 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4701A0644 for ; Wed, 12 Mar 2014 13:39:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20822; q=dns/txt; s=iport; t=1394656735; x=1395866335; h=from:to:subject:date:message-id:mime-version; bh=kaea76uBWGNt3moQvLWCd8fWA++DxIcuJ8dV0C0UtWA=; b=KSTheHkH5J5nD5aTijjsMGnjp1bGJ4AMmeMi3rP1qoO33pN9iXwvhHZC 8L7kzIfm6G8mBZmLl8+I71ZCloDtBUOhFCEcS21pU4eJ/gQFXMtm2H8QF gymIef1bqEi0l0MP6gNp18ym3iP0FQwDCu2emuW0y6OIvk6vY8vYoIqbf I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEHALHEIFOtJXG+/2dsb2JhbABagkJEO1eEJLRJiGuBIBZ0giUBAgQnBl4BCBEDAQIoORQJCgQBEod5DbNGn0AXjjgTGoQ2BJhFgTKQe4Mtgis X-IronPort-AV: E=Sophos; i="4.97,640,1389744000"; d="scan'208,217"; a="26982489" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-7.cisco.com with ESMTP; 12 Mar 2014 20:38:54 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2CKcsWT023759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Mar 2014 20:38:54 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.8]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Wed, 12 Mar 2014 15:38:54 -0500 From: "Charles Eckel (eckelcu)" To: "Feng, Wu-chi" , "aeon@ietf.org" Thread-Topic: [Aeon] Meeting minutes for AEON discussion Thread-Index: AQHPPjMUh4qN0MIgEkSYflrk4h3gNQ== Date: Wed, 12 Mar 2014 20:38:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.86.33] Content-Type: multipart/alternative; boundary="_000_CF46106E229C0eckelcuciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/XICfzH7SoJzPlkqfnRanECb2jO0 Subject: Re: [Aeon] Meeting minutes for AEON discussion X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 20:39:06 -0000 --_000_CF46106E229C0eckelcuciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks to all who participated, and especially to Wu-chi for capturing and = sharing his notes. Please see some additional thoughts inline. From: , Wu-chi Feng > Date: Sunday, March 9, 2014 at 11:08 AM To: "aeon@ietf.org" > Subject: [Aeon] Meeting minutes for AEON discussion Hi, It was good to see such a large turnout at the AEON discussion at IETF 89. = Here are the meeting minutes... There was quite the lively discussion and= I tried to capture most of the comments that were raised. I will add my c= omments in a different e-mail to the list. Regards, Wu-chi In attendance: approximately 30 people Agenda *) Problem statement review =96 Charles Eckel *) Opinions from people Charles went over the problem statement and had discussions regarding quest= ions / comments people had. Some of the discussion points included: *) Some comments regarding quality of service The goal is to be able to benefit applications *) Is adaptation a focus? Yes, it is. Perhaps, this need to be brought up more clearly in the draf= t. *) Are there other flow characteristics that are not QoS related? In some routing, you may want to avoid parts of the network. An example = of not routing through a particular country came up. *) A brief discussion regarding whether the goal of AEON is to benefit te s= ervice provider or the user. The goal is to do both. If you can=92t help both then there would be no = need to use the protocol. That is, if the user isn=92t benefiting, then it= wouldn=92t use AEON. Similarly, if the network doesn=92t benefit, it woul= d ignore the messages *) Discussion regarding the TAPS BOF occurring on Wednesday. There seems to be a bit of a complementary interaction between these TAPS: Users-> transport services AEON: application (transport) -> network It was acknowledged that this might be useful. Having people in the room= that were interested in TAPS is useful. *) How do you do scaling, aggregating, bundling of flows It is up to us to define. There was a bit of discussion regarding what i= t meant for an application to bundle its flows together and how the network= might react to it. Clearly, AEON will need to address such bundling. The Session ID use case is meant to address this: http://tools.ietf.org/html/draft-eckel-aeon-use-cases-01#section-2.8.1 Comments, preferably as a separate thread, as to whether or not this hits t= he mark are appreciated. *) Discussion regarding whether the network can trust the declaration and w= hether or not it is the same as diff-serv It depends on what is being shared and how the network is using it. In t= he simple case the applications may not have a reason to lie and feedback f= rom the network may be information (here, the app benefits from feedback an= d the network benefits from essentially having the app better behave / matc= h up to the network resources). More complicated scenarios may need authen= tication. This will need to be discussed. *) Authentication, flow control, admission control, etc seems overly comple= x There was a discussion that if we did need authentication that it would r= aise the complexity level significantly. In total, it will depend upon wha= t the action required is... the more complex, the mor need for authenticat= ion. A point was brought up regarding DSCPs and that they were not meant t= o do policy. It was also noted that AEON is intended to do both sending an= d receiving policy for a user.. *) Comment regarding QoS only being needed when the network is overloaded. A response was that the network could use it to optimize routing decision= s. For example, splitting network traffic over wired and satellite links (= or not routing through particular areas) *) Comment regarding Skype working over everything, why bother? It seems a basic cost / benefit analysis might be useful. If people deve= loping Skype want to incorporate AEON, the app needs to benefit for the add= ed complexity. It might be useful to do such an analysis. *) Comment regarding perhaps getting more application folks involved, other= wise might be an issue There seemed to be general consensus that this was a good idea... otherwi= se it might never be used. There was a discussion about the WebRTC WG as well as the STUN / Malice w= ork ongoing. The MALICE draft was replaced by the DISCUSS draft: http://tools.ietf.org/html/draft-martinsen-tram-discuss-00 Note that this draft is being discussed on the TRAM list. Comments specific= ally on the draft should be directed to the TRAM list, but comments or ques= tions regarding how this relates to AEON are still appropriate for this lis= t. *) Question regarding where is enforcement of AEON? Could be information or enforcement. It could be done at any network dev= ice (e.g., AP, L2 / L3 router / switch). Anything that sees the packet cou= ld act on the flow Cheers, Charles --_000_CF46106E229C0eckelcuciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3AFA20E98B40ED48BCB51577D23D4B91@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Thanks to all who participated, and especially to Wu-chi for capturing= and sharing his notes.
Please see some additional thoughts inline.

From: <Feng>, Wu-chi Feng <= ;wu-chi.feng@intel.com>
Date: Sunday, March 9, 2014 at 11:0= 8 AM
To: "aeon@ietf.org" <aeon@i= etf.org>
Subject: [Aeon] Meeting minutes for= AEON discussion

Hi,=

It was g= ood to see such a large turnout at the AEON discussion at IETF 89.  He= re are the meeting minutes...  There was quite the lively discussion a= nd I tried to capture most of the comments that were raised.  I will add my comments in a different e-mail to the lis= t.

&nb= sp;

Regards,=

Wu-chi

&nb= sp;

In atten= dance: approximately 30 people

&nb= sp;

Agenda

  *= ) Problem statement review =96 Charles Eckel

  *= ) Opinions from people

&nb= sp;

Charles = went over the problem statement and had discussions regarding questions / c= omments people had.

&nb= sp;

Some of = the discussion points included:

&nb= sp;

*) Some = comments regarding quality of service

  T= he goal is to be able to benefit applications

&nb= sp;

*) Is ad= aptation a focus?

  Y= es, it is.  Perhaps, this need to be brought up more clearly in the dr= aft.

&nb= sp;

*) Are t= here other flow characteristics that are not QoS related?=

  I= n some routing, you may want to avoid parts of the network.  An exampl= e of not routing through a particular country came up. 

&nb= sp;

*) A bri= ef discussion regarding whether the goal of AEON is to benefit te service p= rovider or the user.

  T= he goal is to do both.  If you can=92t help both then there would be n= o need to use the protocol.  That is, if the user isn=92t benefiting, = then it wouldn=92t use AEON.  Similarly, if the network doesn=92t benefit, it would ignore the messages

&nb= sp;

*) Discu= ssion regarding the TAPS BOF occurring on Wednesday.

  T= here seems to be a bit of a complementary interaction between these

  T= APS: Users-> transport services

  A= EON: application (transport) -> network

&nb= sp;

  I= t was acknowledged that this might be useful.  Having people in the ro= om that were interested in TAPS is useful.

&nb= sp;

*) How d= o you do scaling, aggregating, bundling of flows

  I= t is up to us to define.  There was a bit of discussion regarding what= it meant for an application to bundle its flows together and how the netwo= rk might react to it.  Clearly, AEON will need to address such bundling.

The Session ID use case is meant to address this:

Comments, preferably as a separate thread, as to whether or not this h= its the mark are appreciated.

&nb= sp;

*) Discu= ssion regarding whether the network can trust the declaration and whether o= r not it is the same as diff-serv

  I= t depends on what is being shared and how the network is using it.  In= the simple case the applications may not have a reason to lie and feedback= from the network may be information (here, the app benefits from feedback and the network benefits from essentially havin= g the app better behave / match up to the network resources).  More co= mplicated scenarios may need authentication.  This will need to be dis= cussed.

&nb= sp;

*) Authe= ntication, flow control, admission control, etc seems overly complex

  T= here was a discussion that if we did need authentication that it would rais= e the complexity level significantly.  In total, it will depend upon w= hat the action required is...  the more complex, the mor need for authentication.  A point was brought up regarding DS= CPs and that they were not meant to do policy.  It was also noted that= AEON is intended to do both sending and receiving policy for a user..=

&nb= sp;

*) Comme= nt regarding QoS only being needed when the network is overloaded.

  A= response was that the network could use it to optimize routing decisions.&= nbsp; For example, splitting network traffic over wired and satellite links= (or not routing through particular areas)

&nb= sp;

*) Comme= nt regarding Skype working over everything, why bother?

  I= t seems a basic cost / benefit analysis might be useful.  If people de= veloping Skype want to incorporate AEON, the app needs to benefit for the a= dded complexity.  It might be useful to do such an analysis.

&nb= sp;

&nb= sp;

*) Comme= nt regarding perhaps getting more application folks involved, otherwise mig= ht be an issue

  T= here seemed to be general consensus that this was a good idea... otherwise = it might never be used.

&nb= sp;

  T= here was a discussion about the WebRTC WG as well as the STUN / Malice work= ongoing.

The MALICE draft was replaced by the DISCUSS draft:

Note that this draft is being discussed on the TRAM list. Comments spe= cifically on the draft should be directed to the TRAM list, but comments or= questions regarding how this relates to AEON are still appropriate for thi= s list.
 

&nb= sp;

*) Quest= ion regarding where is enforcement of AEON?

  C= ould be information or enforcement.  It could be done at any network d= evice (e.g., AP, L2 / L3 router / switch).  Anything that sees the pac= ket could act on the flow

 

Cheers,
Charles
--_000_CF46106E229C0eckelcuciscocom_-- From nobody Wed Mar 19 18:39:09 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EBE1A02A4 for ; Wed, 19 Mar 2014 18:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzlMS4vwNN-M for ; Wed, 19 Mar 2014 18:39:06 -0700 (PDT) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 76A161A04B7 for ; Wed, 19 Mar 2014 18:39:06 -0700 (PDT) Received: by mail-ve0-f179.google.com with SMTP id db12so175135veb.38 for ; Wed, 19 Mar 2014 18:38:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Vtzz2hLqhy2oAfIgEsjfIL0Ve261tmEmVgbuMta1biQ=; b=F43lKsWEmu9XEycXkTgLNmuRq7go1jVWD4T9On7YYO34vRsBvws0AKIC59YNxQO8zI oc6LNagsGs+rYAjg3PmCrN6gCsVUKJnA+CEYMMO1jkg950vRstNSg6lvcvPtiMIXyw4L Gb6SoQhqElaFiA5i/GEDbEf2Ctuphkc5JVGkb2nerZr5oPfCfrDcSUQ5BpaRJrLlvbw9 RGFisvl/xvGd5y/ItEuH6ot82LhKtVhSpM2cnKTWeLlyLRw92F0qfgw7uwMOcZajZjFH uhRA4hPC6xy6OAD2QwOZry6B19EJzozVcBzl2GNafVgMho45FqCtLqJob2bhWUZCetqa otqQ== MIME-Version: 1.0 X-Received: by 10.221.55.199 with SMTP id vz7mr1093360vcb.40.1395279537553; Wed, 19 Mar 2014 18:38:57 -0700 (PDT) Received: by 10.220.75.2 with HTTP; Wed, 19 Mar 2014 18:38:57 -0700 (PDT) Date: Thu, 20 Mar 2014 09:38:57 +0800 Message-ID: From: Hui Deng To: aeon@ietf.org, Ted Lemon Content-Type: multipart/alternative; boundary=001a1133ae6a32c4fc04f4ffd544 Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/vCd9CxNIxyubUX9ZPPgOWbspC2E Subject: [Aeon] Collaborative network proposal X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 01:39:07 -0000 --001a1133ae6a32c4fc04f4ffd544 Content-Type: text/plain; charset=ISO-8859-1 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 --001a1133ae6a32c4fc04f4ffd544 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all.

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

Our basic ideal is that there are many similar us= e 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
--001a1133ae6a32c4fc04f4ffd544-- From nobody Thu Mar 20 00:03:32 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33111A04E8 for ; Thu, 20 Mar 2014 00:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Escgl8PkZja1 for ; Thu, 20 Mar 2014 00:03:27 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A5B251A034C for ; Thu, 20 Mar 2014 00:03:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6521; q=dns/txt; s=iport; t=1395298999; x=1396508599; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=DX1/xBwbUpjmYDzZqgAXCV2MeBhg52Eg/8ogEZlIsCs=; b=EOC+DT5cn/cjo1p6MN127hUCB1NE9AEhnzNrgGGGbpgs3leAvUzW+7ju Pskhvy8QBqoOuLDHhG4eJ4M5UKH2KhXKJPGb4OJfT+ao8s3YVjO0mC6tO TzC1q1G1p9HETaF07vxnKZndFNZEcckHN3eGhSk51D/vEF7qwa6aPxwM+ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwGAH6RKlOtJXG8/2dsb2JhbABagkJEO1e5XIhygRsWdIIlAQEBBC1cAgEIEQQBAQsdBzIUCQgCBAESCAESh14N0B4XjjQ3AYMkgRQEmXmQfoMtgis X-IronPort-AV: E=Sophos;i="4.97,692,1389744000"; d="scan'208,217";a="311615969" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 20 Mar 2014 07:03:18 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2K73IN2008197 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Mar 2014 07:03:18 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.233]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Thu, 20 Mar 2014 02:03:18 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Hui Deng , "aeon@ietf.org" , Ted Lemon Thread-Topic: [Aeon] Collaborative network proposal Thread-Index: AQHPQ90tpLiBxnSLnEicuIA9Xd4AfJrpiSsw Date: Thu, 20 Mar 2014 07:03:17 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242D8A25@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.72.19] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A242D8A25xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/PeKIVf-Bv4bIBzCmLlPdwe1Y74I Subject: Re: [Aeon] Collaborative network proposal X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 07:03:30 -0000 --_000_913383AAA69FF945B8F946018B75898A242D8A25xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hui, The other problem is that when content providers and clients move to TLS fo= r privacy reasons, the current DPI mechanisms used by middle boxes will fai= l. You may want to look into http://tools.ietf.org/html/draft-eckel-aeon-use-c= ases-00#section-2.5.1 which discusses similar problems with CDN and possibl= e solutions. Thanks and Regards, -Tiru From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Hui Deng Sent: Thursday, March 20, 2014 7:09 AM To: aeon@ietf.org; Ted Lemon Subject: [Aeon] Collaborative network proposal Hello all. We just submitted a draft to propose the concept of the collaborative netwo= rk 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 pos= t here to seek for more comments whether we could work together Here we cc to Int Area AD Ted. Thanks a lot -Hui --_000_913383AAA69FF945B8F946018B75898A242D8A25xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Hui,=

 <= /p>

The other problem is that= when content providers and clients move to TLS for privacy reasons, the cu= rrent 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 = which discusses similar problems with CDN and possible solutions.

 <= /p>

Thanks and Regards,<= /o:p>

-Tiru

 <= /p>

From: Aeon [ma= ilto:aeon-bounces@ietf.org] On Behalf Of Hui Deng
Sent: Thursday, March 20, 2014 7:09 AM
To: 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:

 

Our basic ideal is that there are many similar use c= ases as AEON, so we post here to seek for more comments whether we could wo= rk together

 

Here we cc to Int Area AD Ted.

 

Thanks a lot

 

-Hui

--_000_913383AAA69FF945B8F946018B75898A242D8A25xmbrcdx10ciscoc_-- From nobody Thu Mar 20 04:49:54 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7DF51A0780 for ; Thu, 20 Mar 2014 04:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.224 X-Spam-Level: X-Spam-Status: No, score=-0.224 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lebVtFN-xsLJ for ; Thu, 20 Mar 2014 04:49:49 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id B52EE1A08C6 for ; Thu, 20 Mar 2014 04:49:48 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee2532ad5431c2-0e1c2; Thu, 20 Mar 2014 19:47:15 +0800 (CST) X-RM-TRANSID: 2ee2532ad5431c2-0e1c2 Received: from X6X8D79D8F49E2 (unknown[10.2.52.144]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee3532ad542555-2df9f; Thu, 20 Mar 2014 19:47:15 +0800 (CST) X-RM-TRANSID: 2ee3532ad542555-2df9f From: "Fan, Peng" To: "'Tirumaleswar Reddy \(tireddy\)'" , "'Hui Deng'" , , "'Ted Lemon'" References: <913383AAA69FF945B8F946018B75898A242D8A25@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A242D8A25@xmb-rcd-x10.cisco.com> Date: Thu, 20 Mar 2014 19:50:25 +0800 Message-ID: <001801cf4432$9583cc50$c08b64f0$@chinamobile.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01CF4475.A3B2F330" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF1u9mrdOWjkZ0RXgF0BtQKlZIAmAIy0zd8m4tO/CA= Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/M8j_40C6u3WuKdkxAE1mKnOO5Io Subject: Re: [Aeon] Collaborative network proposal X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 11:49:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0019_01CF4475.A3B2F330 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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] On Behalf Of Tirumaleswar Reddy (tireddy) Sent: Thursday, March 20, 2014 3:03 PM To: Hui Deng; 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 which discusses similar problems with CDN and possible solutions. Thanks and Regards, -Tiru From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Hui Deng Sent: Thursday, March 20, 2014 7:09 AM To: 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 ------=_NextPart_000_0019_01CF4475.A3B2F330 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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] On Behalf Of Tirumaleswar Reddy = (tireddy)
Sent: Thursday, March 20, 2014 3:03 PM
To: = Hui Deng; 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 which discusses similar problems with CDN and possible = solutions.

 

Thanks and Regards,

-Tiru

 

From:= Aeon = [mailto:aeon-bounces@ietf.org] On Behalf Of Hui = Deng
Sent: Thursday, March 20, 2014 7:09 AM
To: = 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:

 

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

------=_NextPart_000_0019_01CF4475.A3B2F330-- From nobody Fri Mar 21 05:06:55 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00031A096C for ; Fri, 21 Mar 2014 05:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.047 X-Spam-Level: X-Spam-Status: No, score=-10.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZ8RxPvbpp16 for ; Fri, 21 Mar 2014 05:06:48 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA561A072C for ; Fri, 21 Mar 2014 05:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15377; q=dns/txt; s=iport; t=1395403599; x=1396613199; h=from:to:subject:date:message-id:mime-version; bh=kDMvnDNJF0QfonMVMMebZo87yMBPG+/WjGt8EuPRzlM=; b=hh/XsT1+5uQqR+iInmTAbrMkgEElWf0bxaX8EpoyzrPhkYAh4Ke1SAS+ sDwZyxVLTcCJXgaymadegEZqBC+39GaoAiLHRnhH8deXIWBX8upeHvAs1 j5QI4qdW/QkyKiPP1nW7tU7GFxOrJs5TwAmBf/bSrCbYgqvYDWoB1DlLW k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4FAFQqLFOtJXHB/2dsb2JhbABPCoJCRDtXuWiIcYEWFnSCJQEBAQQtXgEIEQQBAQsdORQJCQEEARIIARKHXg3PWxeODis3gyWBFASZe5B/gy2CKw X-IronPort-AV: E=Sophos; i="4.97,703,1389744000"; d="scan'208,217"; a="29285975" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-2.cisco.com with ESMTP; 21 Mar 2014 12:06:38 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2LC6coZ002664 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Mar 2014 12:06:38 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.233]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Fri, 21 Mar 2014 07:06:38 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Fan, Peng" , "'Hui Deng'" , "aeon@ietf.org" , "'Ted Lemon'" Thread-Topic: [Aeon] Collaborative network proposal Thread-Index: Ac9E/e2FwCfU9vrUT9acrKqmZrxP7w== Date: Fri, 21 Mar 2014 12:06:37 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242D9B09@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.67.67] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A242D9B09xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/AIsryV3AXJtJCRgXtgzilQKXdE4 Subject: Re: [Aeon] Collaborative network proposal X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 12:06:51 -0000 --_000_913383AAA69FF945B8F946018B75898A242D9B09xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peng, I think DPI should be retired. In addition to the below problems you had me= ntioned in the draft, it's the same problem with WebRTC where DPI would fai= l 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 h= ome and access network will not be able to identify and prioritize the medi= a 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 c= onsider finding a way to retire or simplify DPI functions. Regards, Peng From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy (= tireddy) Sent: Thursday, March 20, 2014 3:03 PM To: Hui Deng; 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 fo= r privacy reasons, the current DPI mechanisms used by middle boxes will fai= l. You may want to look into http://tools.ietf.org/html/draft-eckel-aeon-use-c= ases-00#section-2.5.1 which discusses similar problems with CDN and possibl= e solutions. Thanks and Regards, -Tiru From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Hui Deng Sent: Thursday, March 20, 2014 7:09 AM To: aeon@ietf.org; Ted Lemon Subject: [Aeon] Collaborative network proposal Hello all. We just submitted a draft to propose the concept of the collaborative netwo= rk 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 pos= t here to seek for more comments whether we could work together Here we cc to Int Area AD Ted. Thanks a lot -Hui --_000_913383AAA69FF945B8F946018B75898A242D9B09xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Peng,

 <= /p>

I think DPI should be ret= ired. In addition to the below problems you had mentioned in the draft, it&= #8217;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 h= ome and access network will not be able to identify and prioritize the media streams.

 <= /p>

Cheers,=

-Tiru

 <= /p>

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

 

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

&nbs= p;

http://tools.ietf.or= g/html/draft-eckel-aeon-use-cases-00#section-2.5.1 which discusses similar problems with CDN and possible solutions.

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

&nbs= p;

Hello all= .

&nbs= p;

We just s= ubmitted a draft to propose the concept of the collaborative network as bel= ow link:

&nbs= p;

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

&nbs= p;

Here we c= c to Int Area AD Ted.

&nbs= p;

Thanks a = lot

&nbs= p;

-Hui=

--_000_913383AAA69FF945B8F946018B75898A242D9B09xmbrcdx10ciscoc_-- From nobody Fri Mar 21 09:19:14 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C811A08CB for ; Fri, 21 Mar 2014 09:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzDRZF_tYhZ5 for ; Fri, 21 Mar 2014 09:19:10 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id AC62B1A0772 for ; Fri, 21 Mar 2014 09:19:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17336; q=dns/txt; s=iport; t=1395418740; x=1396628340; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=uFRvIk4/vucvSzCks5lwZixF8w6cauuxQD+xdGHNS+I=; b=UswGnAQxZwIoejhL8B95Zd9x/qMj6O+qFRLKjVp2vFFMxKVJaRH4i6FD 5/Z9AbhxWV1RsdPTJxJJGtRTcEoCV6tpL0RM0XFPoTwXhRfgc6vegr2BV ixKwvkfjr4DbCy3K6l00GmsEj/RjNuxAym4k2JnS/stg84Lt5JWeQXLXS E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQGALllLFOtJV2Y/2dsb2JhbABPCoJCRDtXuWiId4EVFnSCJQEBAQQtXAIBCBEDAQEBKAchERQJCAEBBAESCRKHSgMQAQ3ISg2HCheMUoE8OBMXAQKENgSWXIFtgTKLNoVJgy2CKw X-IronPort-AV: E=Sophos;i="4.97,704,1389744000"; d="scan'208,217";a="311974763" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 21 Mar 2014 16:18:59 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2LGIxIa001010 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Mar 2014 16:19:00 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.148]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Fri, 21 Mar 2014 11:18:59 -0500 From: "Charles Eckel (eckelcu)" To: "Tirumaleswar Reddy (tireddy)" , "Fan, Peng" , "'Hui Deng'" , "aeon@ietf.org" , "'Ted Lemon'" Thread-Topic: [Aeon] Collaborative network proposal Thread-Index: Ac9E/e2F9LxhCAqLRE6sXsjuwdf/NwAEpNIA Date: Fri, 21 Mar 2014 16:18:59 +0000 Message-ID: References: <913383AAA69FF945B8F946018B75898A242D9B09@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A242D9B09@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [171.68.20.16] Content-Type: multipart/alternative; boundary="_000_CF51B2E4234F4eckelcuciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/sAD2zYL3m8VDerhtY8lbuOTK8Dg Subject: Re: [Aeon] Collaborative network proposal X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 16:19:12 -0000 --_000_CF51B2E4234F4eckelcuciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree. Network operators need ways to categorize and provide differentiat= ed 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 ar= e revealed than was actually needed by the network operator to achieve thei= r goals. By eliminating reliance on DPI we reduce the incentive and justifi= cation for such practices. Cheers, Charles From: "Tirumaleswar Reddy (tireddy)" > Date: Friday, March 21, 2014 at 5:06 AM To: "Fan, Peng" >, = 'Hui Deng' >, "aeon@ietf.or= g" >, 'Ted Lemon'= > Subject: Re: [Aeon] Collaborative network proposal Hi Peng, I think DPI should be retired. In addition to the below problems you had me= ntioned in the draft, it=92s the same problem with WebRTC where DPI would f= ail for signaling traffic. WebRTC framework allows any proprietary signalin= g 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 me= dia 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 c= onsider finding a way to retire or simplify DPI functions. Regards, Peng From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy (= tireddy) Sent: Thursday, March 20, 2014 3:03 PM To: Hui Deng; 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 fo= r privacy reasons, the current DPI mechanisms used by middle boxes will fai= l. You may want to look into http://tools.ietf.org/html/draft-eckel-aeon-use-c= ases-00#section-2.5.1 which discusses similar problems with CDN and possibl= e solutions. Thanks and Regards, -Tiru From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Hui Deng Sent: Thursday, March 20, 2014 7:09 AM To: aeon@ietf.org; Ted Lemon Subject: [Aeon] Collaborative network proposal Hello all. We just submitted a draft to propose the concept of the collaborative netwo= rk 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 pos= t here to seek for more comments whether we could work together Here we cc to Int Area AD Ted. Thanks a lot -Hui --_000_CF51B2E4234F4eckelcuciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <12D053EE01002D43B77E9DCFD05581E1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I agree. Network operators need ways to categorize and provide differe= ntiated services for traffic, but relying on DPI is error prone, cumbersome= , and potentially done at the expense of user privacy and application secur= ity (e.g. shared keys made available to DPI enabled middle boxes or HTTP proxies ). In the end, much more infor= mation about the user and the application are revealed than was actually ne= eded by the network operator to achieve their goals. By eliminating relianc= e on DPI we reduce the incentive and justification for such practices.

Cheers,
Charles

From: "Tirumaleswar Reddy (tir= eddy)" <tireddy@cisco.com&= gt;
Date: Friday, March 21, 2014 at 5:0= 6 AM
To: "Fan, Peng" <fanpeng@chinamobile.com>, 'Hui= Deng' <denghui02@gmail.com&g= t;, "aeon@ietf.org" <aeon@ietf.org>, 'Ted Lemon' <Ted.Lemon@nominum= .com>
Subject: Re: [Aeon] Collaborative n= etwork proposal

Hi Peng,

 

I think DPI should be retired. In a= ddition to the below problems you had mentioned in the draft, it=92s the sa= me problem with WebRTC where DPI would fail for signaling traffic. WebRTC framework allows any proprietary signal= ing to be used, so DPI/ALG will not be able to understand the control traff= ic (Even if middle boxes somehow magically figure to act as TLS proxy).&nbs= p; 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 o= r simplify DPI functions.

 

Regards,

Peng

 

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

&nbs= p;

Hi Hui,

 

The other problem is that when cont= ent 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 which discusses similar problems with CDN and possible solutions.

 

Thanks and Regards,

-Tiru

 

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

&nbs= p;

Hello all= .

&nbs= p;

We just s= ubmitted a draft to propose the concept of the collaborative network as bel= ow link:

&nbs= p;

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

&nbs= p;

Here we c= c to Int Area AD Ted.

&nbs= p;

Thanks a = lot

&nbs= p;

-Hui=

--_000_CF51B2E4234F4eckelcuciscocom_-- From nobody Fri Mar 21 09:32:49 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6021A09BD for ; Fri, 21 Mar 2014 09:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5dnEq32-uYJ for ; Fri, 21 Mar 2014 09:32:44 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 049901A09BC for ; Fri, 21 Mar 2014 09:32:43 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-fa-532c69a11147 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 04.4A.10875.1A96C235; Fri, 21 Mar 2014 17:32:33 +0100 (CET) Received: from ESESSMB305.ericsson.se ([169.254.5.240]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0387.000; Fri, 21 Mar 2014 17:32:33 +0100 From: Anton Smith To: "Charles Eckel (eckelcu)" Thread-Topic: [Aeon] Collaborative network proposal Thread-Index: Ac9E/e2FWpNXp5x/bEmEdeY5Re0NkgAGvR2AAAKRm7s= Date: Fri, 21 Mar 2014 16:32:31 +0000 Message-ID: <6CFE8000-610F-403B-A361-60D996CD62F9@ericsson.com> References: <913383AAA69FF945B8F946018B75898A242D9B09@xmb-rcd-x10.cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6CFE8000610F403BA36160D996CD62F9ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM+Jvje7CTJ1gg0vtahYHblVb9Cy5xWax adYXNov1DS/YLbZ2x1qc2L2N0YHNY96FhWweU35vZPXYOesuu8eSJT+ZPF4fmM8awBrFZZOS mpNZllqkb5fAlfHy/CW2gmf9jBV9P+exNjDOqOti5OSQEDCR2HzwIguELSZx4d56ti5GLg4h gUOMEte/LmSHcJYwSsxdNQHI4eBgE9CReNJXANIgImAosWjSOhaQGmaBo4wS81v2s4EkhAWM JF4d+MwOUWQsMXXGZUYI20ri0f3/YHEWAVWJazv3gm3mFbCXmH3jK1hcSCBf4sCEOawgNqeA vsT7lQuYQWxGoOu+n1rDBGIzC4hL3HoynwniagGJJXvOM0PYohIvH/9jhahJltjS+YERYr6g xMmZT1gmMIrMQtI+C0nZLCRlEHEDiffn5jND2NoSyxa+hrL1JTZ+OcuILL6AkX0VI3tuYmZO ernhJkZgBB7c8lt3B+OpcyKHGKU5WJTEeT+8dQ4SEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSkF jAsvj7lLW+pTdzrW/ZYK9d/JeeTWsS63wN0z11sE/frFeTmx6fC0zuV337zizDu84PVBu9r7 vz9bp959rbJm3ltWjSOR/YW7XK955583U5285PS/PpOu0leXxJa0ya2tN7cSlo/5zHeubeep L3rxjzvWzFf9ajpJPdXq0vv777cdvrV+Us2T/vlKLMUZiYZazEXFiQCw7JVHjgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/25Wjx7XgYn1jhSjp1Tz7asDVWqs Cc: Hui Deng , "aeon@ietf.org" , "Fan, Peng" , "Tirumaleswar Reddy \(tireddy\)" , Ted Lemon Subject: Re: [Aeon] Collaborative network proposal X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 16:32:47 -0000 --_000_6CFE8000610F403BA36160D996CD62F9ericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, I've been lurking but another consideration of course is that DPI doesn't s= cale in terms of bps/forwarding. Regards Anton Sent from my iPhone On 21 mar 2014, at 17:19, "Charles Eckel (eckelcu)" > wrote: I agree. Network operators need ways to categorize and provide differentiat= ed 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 ar= e revealed than was actually needed by the network operator to achieve thei= r goals. By eliminating reliance on DPI we reduce the incentive and justifi= cation for such practices. Cheers, Charles From: "Tirumaleswar Reddy (tireddy)" > Date: Friday, March 21, 2014 at 5:06 AM To: "Fan, Peng" >, = 'Hui Deng' >, "aeon@ietf.or= g" >, 'Ted Lemon'= > Subject: Re: [Aeon] Collaborative network proposal Hi Peng, I think DPI should be retired. In addition to the below problems you had me= ntioned in the draft, it=92s the same problem with WebRTC where DPI would f= ail for signaling traffic. WebRTC framework allows any proprietary signalin= g 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 me= dia 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 c= onsider finding a way to retire or simplify DPI functions. Regards, Peng From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy (= tireddy) Sent: Thursday, March 20, 2014 3:03 PM To: Hui Deng; 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 fo= r privacy reasons, the current DPI mechanisms used by middle boxes will fai= l. You may want to look into http://tools.ietf.org/html/draft-eckel-aeon-use-c= ases-00#section-2.5.1 which discusses similar problems with CDN and possibl= e solutions. Thanks and Regards, -Tiru From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Hui Deng Sent: Thursday, March 20, 2014 7:09 AM To: aeon@ietf.org; Ted Lemon Subject: [Aeon] Collaborative network proposal Hello all. We just submitted a draft to propose the concept of the collaborative netwo= rk 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 pos= t 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 --_000_6CFE8000610F403BA36160D996CD62F9ericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi all,

I've been lurking but another consideration of course is that DPI does= n'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 differe= ntiated services for traffic, but relying on DPI is error prone, cumbersome= , and potentially done at the expense of user privacy and application secur= ity (e.g. shared keys made available to DPI enabled middle boxes or HTTP proxies ). In the end, much more infor= mation about the user and the application are revealed than was actually ne= eded by the network operator to achieve their goals. By eliminating relianc= e on DPI we reduce the incentive and justification for such practices.

Cheers,
Charles

From: "Tirumaleswar Reddy (tir= eddy)" <tireddy@cisco.com&= gt;
Date: Friday, March 21, 2014 at 5:0= 6 AM
To: "Fan, Peng" <fanpeng@chinamobile.com>, 'Hui= Deng' <denghui02@gmail.com&g= t;, "aeon@ietf.org" <aeon@ietf.org>, 'Ted Lemon' <Ted.Lemon@nominum= .com>
Subject: Re: [Aeon] Collaborative n= etwork proposal

Hi Peng,

 

I think DPI should be retired. In a= ddition to the below problems you had mentioned in the draft, it=92s the sa= me problem with WebRTC where DPI would fail for signaling traffic. WebRTC framework allows any proprietary signal= ing to be used, so DPI/ALG will not be able to understand the control traff= ic (Even if middle boxes somehow magically figure to act as TLS proxy).&nbs= p; 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 o= r simplify DPI functions.

 

Regards,

Peng

 

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

&nbs= p;

Hi Hui,

 

The other problem is that when cont= ent 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 which discusses similar problems with CDN and possible solutions.

 

Thanks and Regards,

-Tiru

 

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

&nbs= p;

Hello all= .

&nbs= p;

We just s= ubmitted a draft to propose the concept of the collaborative network as bel= ow link:

&nbs= p;

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

&nbs= p;

Here we c= c to Int Area AD Ted.

&nbs= p;

Thanks a = lot

&nbs= p;

-Hui=

_______________________________________________
Aeon mailing list
Aeon@ietf.org
https://www.ie= tf.org/mailman/listinfo/aeon
--_000_6CFE8000610F403BA36160D996CD62F9ericssoncom_-- From nobody Mon Mar 24 12:19:52 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF3F1A02AC for ; Mon, 24 Mar 2014 12:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xntYMNSa8y7N for ; Mon, 24 Mar 2014 12:19:45 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3971A029A for ; Mon, 24 Mar 2014 12:19:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23325; q=dns/txt; s=iport; t=1395688785; x=1396898385; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uE5NUjGn7AaEM4EmO2Xjj1yY0+u4e+u+QPIxN3Vo4/Q=; b=UwXTj1FQVi2IwAmjGcHeuv7e6EmMC6S9sGp/iUj3EG14cziQoRm7p6w5 laeqTQXw5y20d/xd174+G0cw+9gw7nq7W/2mlHI41uRxVrve5SQ0Q5jbw a6p2NcknfgWtyBJXnk4sYx9Bt/PARHadVHgVuwE4YYnghBoE7qQ6wCB73 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFALiEMFOtJV2Z/2dsb2JhbABPCoJCRDtXuXuBP4c1gR8WdIIlAQEBBAEBASpBBAcQAgEIEQMBAQEhBwchBgsUCQgBAQQBDQUJEodKAxABDcd1DYcyF4xdgUE4Ew0EBgEChDYEll2BbYEyizaFSYMtgis X-IronPort-AV: E=Sophos;i="4.97,722,1389744000"; d="scan'208,217";a="312481295" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 24 Mar 2014 19:19:43 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2OJJhFq000642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Mar 2014 19:19:43 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.148]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Mon, 24 Mar 2014 14:19:43 -0500 From: "Charles Eckel (eckelcu)" To: "Fan, Peng" , Hui Deng Thread-Topic: [Aeon] Collaborative network proposal Thread-Index: Ac9E/e2F9LxhCAqLRE6sXsjuwdf/NwAEpNIAAA8j8YAAjgsoAA== Date: Mon, 24 Mar 2014 19:19:42 +0000 Message-ID: References: <913383AAA69FF945B8F946018B75898A242D9B09@xmb-rcd-x10.cisco.com> <6CFE8000-610F-403B-A361-60D996CD62F9@ericsson.com> In-Reply-To: <6CFE8000-610F-403B-A361-60D996CD62F9@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [171.68.20.27] Content-Type: multipart/alternative; boundary="_000_CF55D20F23767eckelcuciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/8Nq4HO9poAVY4GGg5D3wACr8Reo Cc: Anton Smith , "aeon@ietf.org" , Ted Lemon , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [Aeon] Collaborative network proposal X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 19:19:50 -0000 --_000_CF55D20F23767eckelcuciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hui and Peng, Your draft fits very well with the problem statement and use cases discusse= d within AEON. It provides valuable insights into the ISP/ICP relationship = and how it can be improved. In addition to those mentioned previously in th= is thread, limitations AEON aims to address include: 1) Lack of ability for end user or application to express the relative prio= rity of this applications traffic or with respect to other applications or = other traffic within this same application (e.g. one video stream more impo= rtant 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 telli= ng the application the network conditions and enabling the application to a= dapt 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 w= ell? Cheers, Charles From: Anton Smith > Date: Friday, March 21, 2014 at 9:32 AM To: Charles Eckel > Cc: "Tirumaleswar Reddy (tireddy)" >, "Fan, Peng" = >, Hui Deng >, "aeon@ietf.o= rg" >, Ted Lemon = > Subject: Re: [Aeon] Collaborative network proposal Hi all, I've been lurking but another consideration of course is that DPI doesn't s= cale in terms of bps/forwarding. Regards Anton Sent from my iPhone On 21 mar 2014, at 17:19, "Charles Eckel (eckelcu)" > wrote: I agree. Network operators need ways to categorize and provide differentiat= ed 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 ar= e revealed than was actually needed by the network operator to achieve thei= r goals. By eliminating reliance on DPI we reduce the incentive and justifi= cation for such practices. Cheers, Charles From: "Tirumaleswar Reddy (tireddy)" > Date: Friday, March 21, 2014 at 5:06 AM To: "Fan, Peng" >, = 'Hui Deng' >, "aeon@ietf.or= g" >, 'Ted Lemon'= > Subject: Re: [Aeon] Collaborative network proposal Hi Peng, I think DPI should be retired. In addition to the below problems you had me= ntioned in the draft, it=92s the same problem with WebRTC where DPI would f= ail for signaling traffic. WebRTC framework allows any proprietary signalin= g 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 me= dia 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 c= onsider finding a way to retire or simplify DPI functions. Regards, Peng From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy (= tireddy) Sent: Thursday, March 20, 2014 3:03 PM To: Hui Deng; 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 fo= r privacy reasons, the current DPI mechanisms used by middle boxes will fai= l. You may want to look into http://tools.ietf.org/html/draft-eckel-aeon-use-c= ases-00#section-2.5.1 which discusses similar problems with CDN and possibl= e solutions. Thanks and Regards, -Tiru From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Hui Deng Sent: Thursday, March 20, 2014 7:09 AM To: aeon@ietf.org; Ted Lemon Subject: [Aeon] Collaborative network proposal Hello all. We just submitted a draft to propose the concept of the collaborative netwo= rk 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 pos= t 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 --_000_CF55D20F23767eckelcuciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <88B63EEF645F1E44A6640CF447DA1794@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hui and Peng,

Your draft fits very well with the problem statement and use cases dis= cussed within AEON. It provides valuable insights into the ISP/ICP relation= ship 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 applicati= on to express the relative priority of this applications traffic or with re= spect 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 ex= plicit feedback to application regarding network conditions such as congest= ion, 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 i= ts traffic accordingly.
Do you agree these limitations exist currently within ISP networks, an= d 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:3= 2 AM
To: Charles Eckel <eckelcu@cisco.com>
Cc: "Tirumaleswar Reddy (tired= dy)" <tireddy@cisco.com>= ;, "Fan, Peng" <fan= peng@chinamobile.com>, Hui Deng <denghui02@gmail.com>, "aeon@ietf.org" <aeon@ietf.org>, Ted Lemon <Ted.Lemon@nominum.com>
Subject: Re: [Aeon] Collaborative n= etwork proposal

Hi all,

I've been lurking but another consideration of course is that DPI does= n'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 differe= ntiated services for traffic, but relying on DPI is error prone, cumbersome= , and potentially done at the expense of user privacy and application secur= ity (e.g. shared keys made available to DPI enabled middle boxes or HTTP proxies ). In the end, much more infor= mation about the user and the application are revealed than was actually ne= eded by the network operator to achieve their goals. By eliminating relianc= e on DPI we reduce the incentive and justification for such practices.

Cheers,
Charles

From: "Tirumaleswar Reddy (tir= eddy)" <tireddy@cisco.com&= gt;
Date: Friday, March 21, 2014 at 5:0= 6 AM
To: "Fan, Peng" <fanpeng@chinamobile.com>, 'Hui= Deng' <denghui02@gmail.com&g= t;, "aeon@ietf.org" <aeon@ietf.org>, 'Ted Lemon' <Ted.Lemon@nominum= .com>
Subject: Re: [Aeon] Collaborative n= etwork proposal

Hi Peng,

 

I think DPI should be retired. In a= ddition to the below problems you had mentioned in the draft, it=92s the sa= me problem with WebRTC where DPI would fail for signaling traffic. WebRTC framework allows any proprietary signal= ing to be used, so DPI/ALG will not be able to understand the control traff= ic (Even if middle boxes somehow magically figure to act as TLS proxy).&nbs= p; 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 o= r simplify DPI functions.

 

Regards,

Peng

 

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

&nbs= p;

Hi Hui,

 

The other problem is that when cont= ent 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 which discusses similar problems with CDN and possible solutions.

 

Thanks and Regards,

-Tiru

 

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

&nbs= p;

Hello all= .

&nbs= p;

We just s= ubmitted a draft to propose the concept of the collaborative network as bel= ow link:

&nbs= p;

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

&nbs= p;

Here we c= c to Int Area AD Ted.

&nbs= p;

Thanks a = lot

&nbs= p;

-Hui=

_______________________________________________
Aeon mailing list
Aeon@ietf.org
https://www.ie= tf.org/mailman/listinfo/aeon
 --_000_CF55D20F23767eckelcuciscocom_-- From nobody Tue Mar 25 23:30:24 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCEA1A029D for ; Tue, 25 Mar 2014 23:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.763 X-Spam-Level: ** X-Spam-Status: No, score=2.763 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpEKRomtB401 for ; Tue, 25 Mar 2014 23:30:20 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id BFF291A029B for ; Tue, 25 Mar 2014 23:30:18 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.11]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee1533273e7aa1-34aa1; Wed, 26 Mar 2014 14:29:59 +0800 (CST) X-RM-TRANSID: 2ee1533273e7aa1-34aa1 Received: from adminPC (unknown[10.2.52.144]) by rmsmtp-oa_rmapp01-12001 (RichMail) with SMTP id 2ee1533273e2553-fb8b4; Wed, 26 Mar 2014 14:29:59 +0800 (CST) X-RM-TRANSID: 2ee1533273e2553-fb8b4 From: "Fan, Peng" To: "'Charles Eckel \(eckelcu\)'" , "'Hui Deng'" Date: Wed, 26 Mar 2014 14:30:03 +0800 Message-ID: <001b01cf48bc$d25f82c0$771e8840$@chinamobile.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01CF48FF.E087F2E0" X-Mailer: Microsoft Outlook 14.0 thread-index: Ac9It2jatVAr6dLkTVW1RT0FXyc8lQ== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/0G_8GUlhzfZ0cnC0dXonnb4nKKA Cc: 'Anton Smith' , aeon@ietf.org, 'Ted Lemon' , "'Tirumaleswar Reddy \(tireddy\)'" Subject: Re: [Aeon] Collaborative network proposal X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 06:30:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001C_01CF48FF.E087F2E0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Charles, =20 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. =20 Regards, Peng =20 =B7=A2=BC=FE=C8=CB: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA3=D4=C225=C8=D5 3:20 =CA=D5=BC=FE=C8=CB: Fan, Peng; Hui Deng =B3=AD=CB=CD: Tirumaleswar Reddy (tireddy); aeon@ietf.org; Ted Lemon; = Anton Smith =D6=F7=CC=E2: Re: [Aeon] Collaborative network proposal =20 Hui and Peng, =20 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? =20 Cheers, Charles =20 From: Anton Smith Date: Friday, March 21, 2014 at 9:32 AM To: Charles Eckel Cc: "Tirumaleswar Reddy (tireddy)" , "Fan, Peng" , Hui Deng , = "aeon@ietf.org" , Ted Lemon Subject: Re: [Aeon] Collaborative network proposal =20 Hi all, =20 I've been lurking but another consideration of course is that DPI = doesn't scale in terms of bps/forwarding. =20 Regards Anton Sent from my iPhone On 21 mar 2014, at 17:19, "Charles Eckel (eckelcu)" 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. =20 Cheers, Charles =20 From: "Tirumaleswar Reddy (tireddy)" Date: Friday, March 21, 2014 at 5:06 AM To: "Fan, Peng" , 'Hui Deng' = , "aeon@ietf.org" , 'Ted Lemon' Subject: Re: [Aeon] Collaborative network proposal =20 Hi Peng, =20 I think DPI should be retired. In addition to the below problems you had mentioned in the draft, it=A1=AFs 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. =20 Cheers, -Tiru =20 From: Fan, Peng [mailto:fanpeng@chinamobile.com]=20 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 =20 Hi Tiru, =20 Yes, encrypted traffic is another supporting point. I guess it is time = we consider finding a way to retire or simplify DPI functions. =20 Regards, Peng =20 From: Aeon [ = mailto:aeon-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy (tireddy) Sent: Thursday, March 20, 2014 3:03 PM To: Hui Deng; aeon@ietf.org; Ted Lemon Subject: Re: [Aeon] Collaborative network proposal =20 Hi Hui, =20 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.=20 You may want to look into http://tools.ietf.org/html/draft-eckel-aeon-use-cases-00#section-2.5.1 = which discusses similar problems with CDN and possible solutions. =20 Thanks and Regards, -Tiru =20 From: Aeon [ = mailto:aeon-bounces@ietf.org] On Behalf Of Hui Deng Sent: Thursday, March 20, 2014 7:09 AM To: aeon@ietf.org; Ted Lemon Subject: [Aeon] Collaborative network proposal =20 Hello all. =20 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 =20 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 =20 Here we cc to Int Area AD Ted. =20 Thanks a lot =20 -Hui _______________________________________________ Aeon mailing list Aeon@ietf.org https://www.ietf.org/mailman/listinfo/aeon ------=_NextPart_000_001C_01CF48FF.E087F2E0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

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

 

=B7=A2=BC=FE=C8=CB: Charles Eckel = (eckelcu) [mailto:eckelcu@cisco.com]
=B7=A2=CB=CD=CA=B1=BC= =E4: 2014=C4=EA3=D4=C225=C8=D5 3:20
=CA=D5=BC=FE=C8=CB: Fan, Peng; Hui = Deng
=B3=AD=CB=CD: Tirumaleswar Reddy (tireddy); aeon@ietf.org; Ted Lemon; = Anton Smith
=D6=F7=CC=E2: 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>, "Fan, = Peng" <fanpeng@chinamobile.com>, = Hui Deng <denghui02@gmail.com>, = "aeon@ietf.org" <aeon@ietf.org>, 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>, = 'Hui Deng' <denghui02@gmail.com>, = "aeon@ietf.org" <aeon@ietf.org>, '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=A1=AFs 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

 

 

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= ] On Behalf Of Tirumaleswar Reddy (tireddy)
Sent: = Thursday, March 20, 2014 3:03 PM
To: Hui Deng; aeon@ietf.or= g= ; 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://tool= s.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= ] On Behalf Of Hui Deng
Sent: Thursday, March 20, 2014 = 7:09 AM
To: aeon@ietf.or= g= ; 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:

 

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

<= /div>

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

<= /div>
------=_NextPart_000_001C_01CF48FF.E087F2E0-- From nobody Wed Mar 26 11:02:40 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140091A0364 for ; Wed, 26 Mar 2014 11:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.51 X-Spam-Level: X-Spam-Status: No, score=-9.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mf330TEdR-HR for ; Wed, 26 Mar 2014 11:02:32 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 917621A0354 for ; Wed, 26 Mar 2014 11:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7301; q=dns/txt; s=iport; t=1395856951; x=1397066551; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=To3jmV0a0+vjpvL+jIXVXXlVLasWwLkRgktnwxSRuIY=; b=DY54uMmaVhBQrYPjeKmrBergWfODUsKze7dnV3m9v9Ec0dBhm86TOUwd t3peLKu/Qp53ZQ1L8lktTdb/5nJ0NE1EM3p4lFHKNQQieZ3ewQzkRg88h Xi8zE/UW+Ec2hQ5ZgNE2DJ1+rIwZeklYYuyBD+hFkzcf+MZq0fFWV0EW7 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYGADQVM1OtJXG+/2dsb2JhbABZgkJEO1esP41CiHSBHRZ0giUBAQECAi07IQIBCA4DAwECKAcyFAkIAQEEARKHeQ3QWxeJRYRYQxiEOASYTYEzkQCBcIE+gis X-IronPort-AV: E=Sophos; i="4.97,736,1389744000"; d="scan'208,217"; a="30596858" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-8.cisco.com with ESMTP; 26 Mar 2014 18:02:30 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2QI2Ub1017989 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Mar 2014 18:02:30 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.148]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Wed, 26 Mar 2014 13:02:30 -0500 From: "Charles Eckel (eckelcu)" To: Jose Saldana , "aeon@ietf.org" Thread-Topic: [Aeon] A paper about Skype and Vidyo adaptation when network conditions change Thread-Index: Ac83BhjMJB36qkRjQ2KUUcf4Bdxw0QSBrBUA Date: Wed, 26 Mar 2014 18:02:29 +0000 Message-ID: References: <008601cf3706$65b3d710$311b8530$@unizar.es> In-Reply-To: <008601cf3706$65b3d710$311b8530$@unizar.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.124.61] Content-Type: multipart/alternative; boundary="_000_CF58626023AC4eckelcuciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/dMveDZqkODg08W70xYtAPWKUsKM Subject: Re: [Aeon] A paper about Skype and Vidyo adaptation when network conditions change X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 18:02:38 -0000 --_000_CF58626023AC4eckelcuciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jose, Thanks for sharing this. It illustrates the capabilities of limitation of a= pplication adaptation in the absence of communication with the network. One= of the primary goals of AEON is to remove the limitations highlighted in t= he paper. For example, the applications responded to loss by increasing or maintainin= g their bandwidth utilization. In some cases, this is appropriate, but in o= thers it is not. If the loss was due to congestion, sending more may hurt r= ather than help. If the network was able to inform the applications of the = congestion, the applications could have taken better corrective action. Similarly, the need to send redundant information at the start of the sessi= on could be removed, or at least minimized, in cases in which the applicati= on is able to receive some explicit information from the network. Cheers, Charles From: Jose Saldana > Date: Monday, March 3, 2014 at 10:31 AM To: "aeon@ietf.org" > Subject: [Aeon] A paper about Skype and Vidyo adaptation when network condi= tions change Hi all, During the discussion today in London we have talked about how applications= are able to self-adapt to network conditions. Perhaps you may find this paper interesting: http://downloads.hindawi.com/j= ournals/tswj/2014/860170.pdf We put a bandwidth limitation, additional delay and packet loss between the= two nodes making a video conference and we saw how the applications adapte= d their traffic. Best regards, Jose Saldana --_000_CF58626023AC4eckelcuciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9E23FD1F82832F4A8FCDD38FB2E4229E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Jose,

Thanks for sharing this. It illustrates the capabilities of limitation= of application adaptation in the absence of communication with the network= . One of the primary goals of AEON is to remove the limitations highlighted= in the paper. 
For example, the applications responded to loss by increasing or maint= aining their bandwidth utilization. In some cases, this is appropriate, but= in others it is not. If the loss was due to congestion, sending more may h= urt rather than help. If the network was able to inform the applications of the congestion, the applications co= uld have taken better corrective action. 
Similarly, the need to send redundant information at the start of the = session could be removed, or at least minimized, in cases in which the appl= ication is able to receive some explicit information from the network.

Cheers,
Charles

From: Jose Saldana <jsaldana@unizar.es>
Date: Monday, March 3, 2014 at 10:3= 1 AM
To: "aeon@ietf.org" <aeon@i= etf.org>
Subject: [Aeon] A paper about Skype= and Vidyo adaptation when network conditions change

Hi all,

 

During the discussion today in = London we have talked about how applications are able to self-adapt to netw= ork conditions.

 

Perhaps you may find this paper= interesting: http= ://downloads.hindawi.com/journals/tswj/2014/860170.pdf

 

We put a bandwidth limitation, = additional delay and packet loss between the two nodes making a video confe= rence and we saw how the applications adapted their traffic.

 

Best regards,=

 

Jose Saldana<= /p>

--_000_CF58626023AC4eckelcuciscocom_-- From nobody Mon Mar 31 07:24:01 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2F01A087B for ; Mon, 31 Mar 2014 07:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQvFu5i9cF88 for ; Mon, 31 Mar 2014 07:23:50 -0700 (PDT) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF4E1A0849 for ; Mon, 31 Mar 2014 07:23:48 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id s2VENaHK021288; Mon, 31 Mar 2014 16:23:37 +0200 From: "Jose Saldana" To: "'Charles Eckel \(eckelcu\)'" , References: <008601cf3706$65b3d710$311b8530$@unizar.es> In-Reply-To: Date: Mon, 31 Mar 2014 16:23:46 +0200 Message-ID: <013e01cf4cec$d3ad5a60$7b080f20$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_013F_01CF4CFD.97373BD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK0zjN82CEjAQuv0bh8J171UN2WFQEYbZ3dmSd5JBA= Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/EN8hnuVg2fMOHc8wr_7dsJDMJMs Subject: Re: [Aeon] A paper about Skype and Vidyo adaptation when network conditions change X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 14:23:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_013F_01CF4CFD.97373BD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You are right. The idea is that if the applications do not have to = =93survive in a hostile environment=94 (as the title of the paper says), they will = not need to use these aggressive policies. So let=92s share information = between network and applications. =20 Jose =20 De: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]=20 Enviado el: mi=E9rcoles, 26 de marzo de 2014 19:02 Para: Jose Saldana; aeon@ietf.org Asunto: Re: [Aeon] A paper about Skype and Vidyo adaptation when network conditions change =20 Hi Jose, =20 Thanks for sharing this. It illustrates the capabilities of limitation = of application adaptation in the absence of communication with the network. = One of the primary goals of AEON is to remove the limitations highlighted in = the paper.=20 For example, the applications responded to loss by increasing or = maintaining their bandwidth utilization. In some cases, this is appropriate, but in others it is not. If the loss was due to congestion, sending more may = hurt rather than help. If the network was able to inform the applications of = the congestion, the applications could have taken better corrective action.=20 Similarly, the need to send redundant information at the start of the session could be removed, or at least minimized, in cases in which the application is able to receive some explicit information from the = network. =20 Cheers, Charles =20 From: Jose Saldana Date: Monday, March 3, 2014 at 10:31 AM To: "aeon@ietf.org" Subject: [Aeon] A paper about Skype and Vidyo adaptation when network conditions change =20 Hi all, =20 During the discussion today in London we have talked about how = applications are able to self-adapt to network conditions. =20 Perhaps you may find this paper interesting: http://downloads.hindawi.com/journals/tswj/2014/860170.pdf =20 We put a bandwidth limitation, additional delay and packet loss between = the two nodes making a video conference and we saw how the applications = adapted their traffic. =20 Best regards, =20 Jose Saldana ------=_NextPart_000_013F_01CF4CFD.97373BD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

You are right. The idea is = that if the applications do not have to “survive in a hostile = environment” (as the title of the paper says), they will not need = to use these aggressive policies. So let’s share information = between network and applications.

 

Jose

<= p class=3DMsoNormal> 

De: Charles Eckel (eckelcu) = [mailto:eckelcu@cisco.com] =
Enviado el: mi=E9rcoles, 26 de marzo de 2014 = 19:02
Para: Jose Saldana; aeon@ietf.org
Asunto: Re: = [Aeon] A paper about Skype and Vidyo adaptation when network conditions = change

 

Hi Jose,

 

Thanks for sharing this. It illustrates the = capabilities of limitation of application adaptation in the absence of = communication with the network. One of the primary goals of AEON is to = remove the limitations highlighted in the = paper. 

For example, the applications responded to loss by = increasing or maintaining their bandwidth utilization. In some cases, = this is appropriate, but in others it is not. If the loss was due to = congestion, sending more may hurt rather than help. If the network was = able to inform the applications of the congestion, the applications = could have taken better corrective = action. 

Similarly, the need to send redundant information at = the start of the session could be removed, or at least minimized, in = cases in which the application is able to receive some explicit = information from the network.

 

Cheers,

Charles

 

From: = Jose Saldana <jsaldana@unizar.es>
Date:= Monday, March 3, 2014 at 10:31 AM
To: "aeon@ietf.org" <aeon@ietf.org>
Subject: = [Aeon] A paper about Skype and Vidyo adaptation when network = conditions change

 

Hi all,

 

During the = discussion today in London we have talked about how applications are = able to self-adapt to network conditions.

 

Perhaps you = may find this paper interesting: http:= //downloads.hindawi.com/journals/tswj/2014/860170.pdf

 

We put a = bandwidth limitation, additional delay and packet loss between the two = nodes making a video conference and we saw how the applications adapted = their traffic.

 

Best = regards,

 

Jose = Saldana

------=_NextPart_000_013F_01CF4CFD.97373BD0--