From nobody Sun Jun 1 15:03: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 06BF81A0097 for ; Sun, 1 Jun 2014 15:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 rXEZw4_SKFcK for ; Sun, 1 Jun 2014 15:03:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 121C71A00C2 for ; Sun, 1 Jun 2014 15:03:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BET53244; Sun, 01 Jun 2014 22:03:36 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 1 Jun 2014 23:02:55 +0100 Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 1 Jun 2014 23:03:35 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml703-chm.china.huawei.com ([169.254.5.144]) with mapi id 14.03.0158.001; Sun, 1 Jun 2014 15:03:24 -0700 From: Linda Dunbar To: "aeon@ietf.org" Thread-Topic: RE: Charter Proposal Thread-Index: Ac995U7YY6dlHKIhQ3Gxb/h+bu0byg== Date: Sun, 1 Jun 2014 22:03:24 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D2A013@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.148.47] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D2A013dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/gejDe-4TJaZW70oXl7a525Yt43Q Subject: Re: [Aeon] Charter 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: Sun, 01 Jun 2014 22:03:48 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645D2A013dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We really need to send the BOF request by Thurs (June 5) because June 6th i= s the BoF request deadline. The previously proposed charter only focuses on why operators wanting to kn= ow applications. Without applications wanting to send their characteristics= to network, the network has to depend on DPI (or nothing when the traffic = is encrypted). I think that we should change the angle to describe why today's application= s need to send their traffic characteristics to network for differentiated = services. With this in mind, I rewrote the charter proposal: Do people on the list agree if we can send this charter proposal to the Tr= ansport ADs (Spencer & Martin) to request a BoF in Toronto. Linda Description of Working Group: Today's traffic characteristics, such as bandwidth, delay, loss, jitter, et= c, are statically configured and managed by service providers on per client= or port basis. Even with edge devices or CPE (customer premises equipment)= being able to configure different QoS for differentiated network services,= the classification is usually coarse and fixed. For example, CPE can assig= n different QoS to differentiate video, voice and data traffic, but CPE can= 't differentiate the applications under data category even though more and = more data traffic are carrying video content. It is impossible for applications to get differentiated services from publi= c internet, such as hotspot WIFI. It is also not possible for applications = to change network behavior. For example it is not easy for AntiDoS applicat= ions to enforce certain traffic to a special scrubbing center when some thr= eat is detected. Today, more and more applications need differentiated services from network= . Some applications may need special services for a specific time span, whi= le other applications may need to indicate their unique characteristics to = the network for special treatment, especially when they send encrypted traf= fic. The working group will examine what network characteristics that applicatio= ns need to communicate with network, define general framework and architect= ure for enabling those communications, examine existing protocols for those= communications, and potentially identify new protocols. Specifically, the Working Group will: 1. Identify the applications (or use cases) that need differentiated servi= ces, and time based services. 2. identify typical workflows for which heuristic based approaches are used 2. identify limitations of existing solutions 3. create a set of requirements for a solution based on explicit communication between applications and the network that can be applied in a consistent fashion across a variety of signaling protocols 4. identify a set of use cases addressable by such a solution 5. identify the information that needs to be communicated between application and the network 6. create a framework for providing this communication between applications and the network and that addresses the use cases 7. specify how existing signaling protocols can be enhanced to support this framework The Working Group is expected to work closely with other Transport area groups. The following topics are out of scope of this Working Group: TBD Deliverables: TBD Milestones: TBD --_000_4A95BA014132FF49AE685FAB4B9F17F645D2A013dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We really need to send the BOF request by Thurs (Jun= e 5) because June 6th is the BoF request deadline.

The previously proposed charter only focuses on= why operators wanting to know applications. Without applications wanting t= o send their characteristics to network, the network has to depend on DPI (= or nothing when the traffic is encrypted).

I think that we should change the angle to desc= ribe why today’s applications need to send their traffic characterist= ics to network for differentiated services. With this in mind, I rewrote th= e charter proposal:

Do people on the list agree if we can send this= charter  proposal to the Transport ADs (Spencer & Martin) to requ= est a BoF in Toronto.

Linda

Description of Working Group:

 

Today’s traffic characteristics, such as bandwidth, = delay, loss, jitter, etc, are statically configured and managed by service = providers on per client or port basis. Even with edge devices or CPE (customer premises equipment) being able to configure diffe= rent QoS for differentiated network services, the classification is usually= coarse and fixed. For example, CPE can assign different QoS to differentia= te video, voice and data traffic, but CPE can’t differentiate the applications under data category eve= n though more and more data traffic are carrying video content. 

It is impossible for applications to get differentiated se= rvices from public internet, such as hotspot WIFI. It is also not possible = for applications to change network behavior. For example it is not easy for AntiDoS applications to enforce certain traffic= to a special scrubbing center when some threat is detected.

 

Today, more and more applications need differentiated serv= ices from network. Some applications may need special services for a specif= ic time span, while other applications may need to indicate their unique characteristics to the network for special treatm= ent, especially when they send encrypted traffic.

 

The working group will examine what network characteristics that appli= cations need to communicate with network, define general framework and arch= itecture for enabling those communications, examine existing protocols for those communications, and potentially identify new = protocols.

Specifically, the Working Group will:

1.  Identify the applications (or use cases) that need= differentiated services, and time based services.

&= nbsp;

2. identify typical workflows for which heuristic based ap= proaches are used

2. identify limitations of existing solutions

3. create a set of requirements for a solution based on ex= plicit

communication between applications and the network that ca= n be applied in

a consistent fashion across a variety of signaling protoco= ls

4. identify a set of use cases addressable by such a solut= ion

5. identify the information that needs to be communicated = between

application and the network

6. create a framework for providing this communication bet= ween

applications and the network and that addresses the use ca= ses

7. specify how existing signaling protocols can be enhance= d to support

this framework

 

The Working Group is expected to work closely with other T= ransport area

groups.

 

The following topics are out of scope of this Working Grou= p:

TBD

 

Deliverables:

TBD

 

Milestones:

TBD

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645D2A013dfweml701chmchi_-- From nobody Sun Jun 1 21:20:13 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 BA38E1A028D for ; Sun, 1 Jun 2014 21:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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.651, 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 4oUh3Vn-grBf for ; Sun, 1 Jun 2014 21:20:04 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF2241A0289 for ; Sun, 1 Jun 2014 21:20:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17760; q=dns/txt; s=iport; t=1401682799; x=1402892399; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=QbMiTJofn/WyByTy1NH7mFkb991z1TU65pHKdx6XiP0=; b=actUHJ69+5YRE89ijpwNI7w2w9YZMl6i2kg46XbxVOqmZ6ztiWmQjgxR JZTkKTGhqV2/J6/wdK4apAznBFvb3+V+KHpiBQb0IoK/M4XikZxXOQ447 CkjUJ1V6QCa5QVrWc/SJjIFM3qrZnT9e/XaZGBFdczdBpXxlvosz3zDFo 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAFAIf6i1OtJV2a/2dsb2JhbABPCoJCRVJYuViIewGBERZ0giUBAQEELVwCAQgRAQMBAQsdBzIUAwYIAQEEARIIE4gnDdQAF412KzcBgyuBFQSbPpFvgziCLw X-IronPort-AV: E=Sophos;i="4.98,954,1392163200"; d="scan'208,217";a="329791459" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 02 Jun 2014 04:19:57 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s524JvNf022380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Jun 2014 04:19:57 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Sun, 1 Jun 2014 23:19:57 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Linda Dunbar , "aeon@ietf.org" Thread-Topic: [Aeon] Charter Proposal Thread-Index: Ac995U7YY6dlHKIhQ3Gxb/h+bu0bygAM8fdA Date: Mon, 2 Jun 2014 04:19:56 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A282C5254@xmb-rcd-x10.cisco.com> References: <4A95BA014132FF49AE685FAB4B9F17F645D2A013@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D2A013@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.66.246] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A282C5254xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/LRxfYGKL4GfEzETMJiFZNKfXxf0 Subject: Re: [Aeon] Charter 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, 02 Jun 2014 04:20:08 -0000 --_000_913383AAA69FF945B8F946018B75898A282C5254xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think Peng has already sent the revised charter proposal to AD based on t= he updated problem statement draft http://tools.ietf.org/html/draft-conet-a= eon-problem-statement-00 -Tiru From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Monday, June 02, 2014 3:33 AM To: aeon@ietf.org Subject: Re: [Aeon] Charter Proposal We really need to send the BOF request by Thurs (June 5) because June 6th i= s the BoF request deadline. The previously proposed charter only focuses on why operators wanting to kn= ow applications. Without applications wanting to send their characteristics= to network, the network has to depend on DPI (or nothing when the traffic = is encrypted). I think that we should change the angle to describe why today's application= s need to send their traffic characteristics to network for differentiated = services. With this in mind, I rewrote the charter proposal: Do people on the list agree if we can send this charter proposal to the Tr= ansport ADs (Spencer & Martin) to request a BoF in Toronto. Linda Description of Working Group: Today's traffic characteristics, such as bandwidth, delay, loss, jitter, et= c, are statically configured and managed by service providers on per client= or port basis. Even with edge devices or CPE (customer premises equipment)= being able to configure different QoS for differentiated network services,= the classification is usually coarse and fixed. For example, CPE can assig= n different QoS to differentiate video, voice and data traffic, but CPE can= 't differentiate the applications under data category even though more and = more data traffic are carrying video content. It is impossible for applications to get differentiated services from publi= c internet, such as hotspot WIFI. It is also not possible for applications = to change network behavior. For example it is not easy for AntiDoS applicat= ions to enforce certain traffic to a special scrubbing center when some thr= eat is detected. Today, more and more applications need differentiated services from network= . Some applications may need special services for a specific time span, whi= le other applications may need to indicate their unique characteristics to = the network for special treatment, especially when they send encrypted traf= fic. The working group will examine what network characteristics that applicatio= ns need to communicate with network, define general framework and architect= ure for enabling those communications, examine existing protocols for those= communications, and potentially identify new protocols. Specifically, the Working Group will: 1. Identify the applications (or use cases) that need differentiated servi= ces, and time based services. 2. identify typical workflows for which heuristic based approaches are used 2. identify limitations of existing solutions 3. create a set of requirements for a solution based on explicit communication between applications and the network that can be applied in a consistent fashion across a variety of signaling protocols 4. identify a set of use cases addressable by such a solution 5. identify the information that needs to be communicated between application and the network 6. create a framework for providing this communication between applications and the network and that addresses the use cases 7. specify how existing signaling protocols can be enhanced to support this framework The Working Group is expected to work closely with other Transport area groups. The following topics are out of scope of this Working Group: TBD Deliverables: TBD Milestones: TBD --_000_913383AAA69FF945B8F946018B75898A282C5254xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think Peng= has already sent the revised charter proposal to AD based on the updated p= roblem statement draft http://tools.ietf.org/html/draft-conet-aeon-problem-statement-00=

 

-Tiru

 

From: Aeon [ma= ilto:aeon-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Monday, June 02, 2014 3:33 AM
To: aeon@ietf.org
Subject: Re: [Aeon] Charter Proposal

 

We really need to send the BOF request by Thurs (Jun= e 5) because June 6th is the BoF request deadline.

The previously proposed charter only focuses on= why operators wanting to know applications. Without applications wanting t= o send their characteristics to network, the network has to depend on DPI (= or nothing when the traffic is encrypted).

I think that we should change the angle to desc= ribe why today’s applications need to send their traffic characterist= ics to network for differentiated services. With this in mind, I rewrote th= e charter proposal:

Do people on the list agree if we can send this= charter  proposal to the Transport ADs (Spencer & Martin) to requ= est a BoF in Toronto.

Linda

Description of Working Group:

 

Today’s traffic characteristics, such as bandwidth, = delay, loss, jitter, etc, are statically configured and managed by service = providers on per client or port basis. Even with edge devices or CPE (customer premises equipment) being able to configure diffe= rent QoS for differentiated network services, the classification is usually= coarse and fixed. For example, CPE can assign different QoS to differentia= te video, voice and data traffic, but CPE can’t differentiate the applications under data category eve= n though more and more data traffic are carrying video content. 

It is impossible for applications to get differentiated se= rvices from public internet, such as hotspot WIFI. It is also not possible = for applications to change network behavior. For example it is not easy for AntiDoS applications to enforce certain traffic= to a special scrubbing center when some threat is detected.

 

Today, more and more applications need differentiated serv= ices from network. Some applications may need special services for a specif= ic time span, while other applications may need to indicate their unique characteristics to the network for special treatm= ent, especially when they send encrypted traffic.

 

The working group will examine what network characteristics that appli= cations need to communicate with network, define general framework and arch= itecture for enabling those communications, examine existing protocols for those communications, and potentially identify new = protocols.

Specifically, the Working Group will:

1.  Identify the applications (or use cases) that need= differentiated services, and time based services.

&= nbsp;

2. identify typical workflows for which heuristic based ap= proaches are used

2. identify limitations of existing solutions

3. create a set of requirements for a solution based on ex= plicit

communication between applications and the network that ca= n be applied in

a consistent fashion across a variety of signaling protoco= ls

4. identify a set of use cases addressable by such a solut= ion

5. identify the information that needs to be communicated = between

application and the network

6. create a framework for providing this communication bet= ween

applications and the network and that addresses the use ca= ses

7. specify how existing signaling protocols can be enhance= d to support

this framework

 

The Working Group is expected to work closely with other T= ransport area

groups.

 

The following topics are out of scope of this Working Grou= p:

TBD

 

Deliverables:

TBD

 

Milestones:

TBD

 

--_000_913383AAA69FF945B8F946018B75898A282C5254xmbrcdx10ciscoc_-- From nobody Mon Jun 2 05:01:16 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 B64E81A01C7 for ; Mon, 2 Jun 2014 05:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 r6Szi5aFsYGu for ; Mon, 2 Jun 2014 05:01:12 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A01C1A02B7 for ; Mon, 2 Jun 2014 05:01:12 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0M1Utl-1WXzC80dXl-00t36m; Mon, 02 Jun 2014 08:00:56 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_E86C75C5-4DB6-44F1-AEC5-80A8AF38D34B" From: Alper Yegin In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D2A013@dfweml701-chm.china.huawei.com> Date: Mon, 2 Jun 2014 15:00:52 +0300 Message-Id: <1C2C1D6D-43C8-42D9-ADED-ADA0D5DF6C7E@yegin.org> References: <4A95BA014132FF49AE685FAB4B9F17F645D2A013@dfweml701-chm.china.huawei.com> To: Linda Dunbar X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:f5klLpqCg1+5s9nA3sXSkkx/B2YObKtmZOD900tJD2P jjGEWZIFVK67RuhDVh3Bk4SHlZ7p0Mj7Yfrqmc9RcQXSCli3IU mmgZzy2nUmEH8ApAxkX57QObt4W2ge8H6LMytNjKazBUF8cvWP t0ExCzoui/+Y5AzKx5UcMDOFbpwpcQHGs6bZxyi3wVs5lSA4tT bnMyaXE+Fj+36XHZGDQxA/cn+fa6JReQgl1Ogq4LDZ6g0FgwZw BL69MMVgBdYD9UQxtHnHhpsvC4jWTiZUz9125zountq9BYO9ll TcvOj7uK9R2MCi8xywySJNS3vYj70Kd+SsSf+yHfV7o2xCXVsY uJGbNsL6kzEnk4unA8CEdwc3YgLDNDHZO/wPa+DVkioPsQnKzr JywUDZGpoxQ8Q== Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/43v3yHMaNk1EeLjkhrmAaD3Mnws Cc: "aeon@ietf.org" Subject: Re: [Aeon] Charter 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, 02 Jun 2014 12:01:14 -0000 --Apple-Mail=_E86C75C5-4DB6-44F1-AEC5-80A8AF38D34B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Linda, > 2. identify typical workflows for which heuristic based approaches are = used It is not clear what these "heuristic based approaches" are. There is no = mention of that prior to this sentence. Alper On Jun 2, 2014, at 1:03 AM, Linda Dunbar wrote: > We really need to send the BOF request by Thurs (June 5) because June = 6th is the BoF request deadline. > The previously proposed charter only focuses on why operators wanting = to know applications. Without applications wanting to send their = characteristics to network, the network has to depend on DPI (or nothing = when the traffic is encrypted). >=20 > I think that we should change the angle to describe why today=92s = applications need to send their traffic characteristics to network for = differentiated services. With this in mind, I rewrote the charter = proposal: >=20 > Do people on the list agree if we can send this charter proposal to = the Transport ADs (Spencer & Martin) to request a BoF in Toronto. >=20 > Linda >=20 > Description of Working Group: > =20 > Today=92s traffic characteristics, such as bandwidth, delay, loss, = jitter, etc, are statically configured and managed by service providers = on per client or port basis. Even with edge devices or CPE (customer = premises equipment) being able to configure different QoS for = differentiated network services, the classification is usually coarse = and fixed. For example, CPE can assign different QoS to differentiate = video, voice and data traffic, but CPE can=92t differentiate the = applications under data category even though more and more data traffic = are carrying video content.=20 > It is impossible for applications to get differentiated services from = public internet, such as hotspot WIFI. It is also not possible for = applications to change network behavior. For example it is not easy for = AntiDoS applications to enforce certain traffic to a special scrubbing = center when some threat is detected. > =20 > Today, more and more applications need differentiated services from = network. Some applications may need special services for a specific time = span, while other applications may need to indicate their unique = characteristics to the network for special treatment, especially when = they send encrypted traffic. > =20 > The working group will examine what network characteristics that = applications need to communicate with network, define general framework = and architecture for enabling those communications, examine existing = protocols for those communications, and potentially identify new = protocols. >=20 > Specifically, the Working Group will: > 1. Identify the applications (or use cases) that need differentiated = services, and time based services. > =20 > 2. identify typical workflows for which heuristic based approaches are = used > 2. identify limitations of existing solutions > 3. create a set of requirements for a solution based on explicit > communication between applications and the network that can be applied = in > a consistent fashion across a variety of signaling protocols > 4. identify a set of use cases addressable by such a solution > 5. identify the information that needs to be communicated between > application and the network > 6. create a framework for providing this communication between > applications and the network and that addresses the use cases > 7. specify how existing signaling protocols can be enhanced to support > this framework > =20 > The Working Group is expected to work closely with other Transport = area > groups. > =20 > The following topics are out of scope of this Working Group: > TBD > =20 > Deliverables: > TBD > =20 > Milestones: > TBD > =20 > _______________________________________________ > Aeon mailing list > Aeon@ietf.org > https://www.ietf.org/mailman/listinfo/aeon --Apple-Mail=_E86C75C5-4DB6-44F1-AEC5-80A8AF38D34B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hello Linda,

> 2. identify typical workflows for which heuristic based = approaches are used

It is not clear = what these "heuristic based approaches" are. There is no mention of that = prior to this sentence.



On Jun 2, 2014, = at 1:03 AM, Linda Dunbar wrote:

We really need to send the BOF = request by Thurs (June 5) because June 6th is the BoF request = deadline.

The previously = proposed charter only focuses on why operators wanting to know = applications. Without applications wanting to send their characteristics = to network, the network has to depend on DPI (or nothing when the = traffic is encrypted).

I = think that we should change the angle to describe why today=92s = applications need to send their traffic characteristics to network for = differentiated services. With this in mind, I rewrote the charter = proposal:

Do people on the = list agree if we can send this charter  proposal to the Transport = ADs (Spencer & Martin) to request a BoF in = Toronto.

Linda

Description of Working Group:
 
Today=92s traffic characteristics, = such as bandwidth, delay, loss, jitter, etc, are statically configured = and managed by service providers on per client or port basis. Even with = edge devices or CPE (customer premises equipment) being able to = configure different QoS for differentiated network services, the = classification is usually coarse and fixed. For example, CPE can assign = different QoS to differentiate video, voice and data traffic, but CPE = can=92t differentiate the applications under data category even though = more and more data traffic are carrying video = content. 
It is impossible for applications to = get differentiated services from public internet, such as hotspot WIFI. = It is also not possible for applications to change network behavior. For = example it is not easy for AntiDoS applications to enforce certain = traffic to a special scrubbing center when some threat is = detected.
 
Today, more and more applications need differentiated services = from network. Some applications may need special services for a specific = time span, while other applications may need to indicate their unique = characteristics to the network for special treatment, especially when = they send encrypted traffic.
 

The working group will = examine what network characteristics that applications need to = communicate with network, define general framework and architecture for = enabling those communications, examine existing protocols for those = communications, and potentially identify new = protocols.

Specifically, the Working Group = will:
1.  Identify the = applications (or use cases) that need differentiated services, and time = based services.
2. identify typical workflows for = which heuristic based approaches are used
2. identify limitations of existing = solutions
3. create a set of requirements for = a solution based on explicit
communication between applications and the network that can be = applied in
a consistent fashion across a = variety of signaling protocols
4. identify a set of use cases addressable by such a = solution
5. identify the information that = needs to be communicated between
application and the network
6. create a framework for providing this communication = between
applications and the network and = that addresses the use cases
7. specify how existing signaling protocols can be enhanced to = support
this = framework
 
The Working Group is expected to work closely with other = Transport area
groups.
 
The following topics are out of = scope of this Working Group:
TBD
 
Deliverables:
 
Milestones:
Subject: Re: [Aeon] Charter 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, 02 Jun 2014 22:26:17 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645D2B775dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "heuristic based approaches" as described in the problem statement is about= network provider's reliance on inspection and observation, e.g. using DPI,= to detect the traffic characteristics. Linda From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Monday, June 02, 2014 7:01 AM To: Linda Dunbar Cc: aeon@ietf.org Subject: Re: [Aeon] Charter Proposal Hello Linda, > 2. identify typical workflows for which heuristic based approaches are us= ed It is not clear what these "heuristic based approaches" are. There is no me= ntion of that prior to this sentence. Alper On Jun 2, 2014, at 1:03 AM, Linda Dunbar wrote: We really need to send the BOF request by Thurs (June 5) because June 6th i= s the BoF request deadline. The previously proposed charter only focuses on why operators wanting to kn= ow applications. Without applications wanting to send their characteristics= to network, the network has to depend on DPI (or nothing when the traffic = is encrypted). I think that we should change the angle to describe why today's application= s need to send their traffic characteristics to network for differentiated = services. With this in mind, I rewrote the charter proposal: Do people on the list agree if we can send this charter proposal to the Tr= ansport ADs (Spencer & Martin) to request a BoF in Toronto. Linda Description of Working Group: Today's traffic characteristics, such as bandwidth, delay, loss, jitter, et= c, are statically configured and managed by service providers on per client= or port basis. Even with edge devices or CPE (customer premises equipment)= being able to configure different QoS for differentiated network services,= the classification is usually coarse and fixed. For example, CPE can assig= n different QoS to differentiate video, voice and data traffic, but CPE can= 't differentiate the applications under data category even though more and = more data traffic are carrying video content. It is impossible for applications to get differentiated services from publi= c internet, such as hotspot WIFI. It is also not possible for applications = to change network behavior. For example it is not easy for AntiDoS applicat= ions to enforce certain traffic to a special scrubbing center when some thr= eat is detected. Today, more and more applications need differentiated services from network= . Some applications may need special services for a specific time span, whi= le other applications may need to indicate their unique characteristics to = the network for special treatment, especially when they send encrypted traf= fic. The working group will examine what network characteristics that applicatio= ns need to communicate with network, define general framework and architect= ure for enabling those communications, examine existing protocols for those= communications, and potentially identify new protocols. Specifically, the Working Group will: 1. Identify the applications (or use cases) that need differentiated servi= ces, and time based services. 2. identify typical workflows for which heuristic based approaches are used 2. identify limitations of existing solutions 3. create a set of requirements for a solution based on explicit communication between applications and the network that can be applied in a consistent fashion across a variety of signaling protocols 4. identify a set of use cases addressable by such a solution 5. identify the information that needs to be communicated between application and the network 6. create a framework for providing this communication between applications and the network and that addresses the use cases 7. specify how existing signaling protocols can be enhanced to support this framework The Working Group is expected to work closely with other Transport area groups. The following topics are out of scope of this Working Group: TBD Deliverables: TBD Milestones: TBD _______________________________________________ Aeon mailing list Aeon@ietf.org https://www.ietf.org/mailman/listinfo/aeon --_000_4A95BA014132FF49AE685FAB4B9F17F645D2B775dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

"heuristic based approa= ches" as described in the problem statement is about network provider&= #8217;s reliance on ins= pection and observation, e.g. using DPI,  to detect the traffic characteristics.

 

Linda

 <= /p>

From: Alper Ye= gin [mailto:alper.yegin@yegin.org]
Sent: Monday, June 02, 2014 7:01 AM
To: Linda Dunbar
Cc: aeon@ietf.org
Subject: Re: [Aeon] Charter Proposal

 

Hello Linda,

 

> 2. identify typical workflows for which heuristic bas= ed approaches are used

 

It is not clear what these "heuristic based approache= s" are. There is no mention of that prior to this sentence.

 

Alper

 

 

On Jun 2, 2014, at 1:03 AM, Linda Dunbar wrote:=



We really need to send the BOF request = by Thurs (June 5) because June 6th is the BoF request deadline.

The previously proposed charter only focuses on why operators = wanting to know applications. Without applications wanting to send their ch= aracteristics to network, the network has to depend on DPI (or nothing when the traffic is encrypted).

I think that we should change the angle to describe why today&= #8217;s applications need to send their traffic characteristics to network = for differentiated services. With this in mind, I rewrote the charter proposal:

Do people on the list agree if we can send this charter  = proposal to the Transport ADs (Spencer & Martin) to request a BoF in To= ronto.

Linda

Description of Working Group:

 

Today’s traffic characteristics, such as bandwidth, = delay, loss, jitter, etc, are statically configured and managed by service = providers on per client or port basis. Even with edge devices or CPE (customer premises equipment) being able to configure diffe= rent QoS for differentiated network services, the classification is usually= coarse and fixed. For example, CPE can assign different QoS to differentia= te video, voice and data traffic, but CPE can’t differentiate the applications under data category eve= n though more and more data traffic are carrying video content. 

It is impossible for applications to get differentiated se= rvices from public internet, such as hotspot WIFI. It is also not possible = for applications to change network behavior. For example it is not easy for AntiDoS applications to enforce certain traffic= to a special scrubbing center when some threat is detected.

 

Today, more and more applications need differentiated serv= ices from network. Some applications may need special services for a specif= ic time span, while other applications may need to indicate their unique characteristics to the network for special treatm= ent, especially when they send encrypted traffic.<= /o:p>

 

The wo= rking group will examine what network characteristics that applications nee= d to communicate with network, define general framework and architecture fo= r enabling those communications, examine existing protocols for those communications, and potentially identify new protocols= .

Specifically, the Working Group will:<= o:p>

1.  Iden= tify the applications (or use cases) that need differentiated services, and tim= e based services.

 

2. identify typical workflows for which heuristic based ap= proaches are used

2. identify limitations of existing solutions

3. create a set of requirements for a solution based on ex= plicit

communication between applications and the network that ca= n be applied in

a consistent fashion across a variety of signaling protoco= ls

4. identify a set of use cases addressable by such a solut= ion

5. identify the information that needs to be communicated = between

application and the network=

6. create a framework for providing this communication bet= ween

applications and the network and that addresses the use ca= ses

7. specify how existing signaling protocols can be enhance= d to support

this framework

 

The Working Group is expected to work closely with other T= ransport area

groups.

 

The following topics are out of scope of this Working Grou= p:

TBD

 

Deliverables:

TBD

 

Milestones:

TBD

 

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

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645D2B775dfweml701chmchi_-- From nobody Mon Jun 2 15:40: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 A9A381A03FB for ; Mon, 2 Jun 2014 15:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 B8wEpFCxvnhx for ; Mon, 2 Jun 2014 15:39:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFB251A03E7 for ; Mon, 2 Jun 2014 15:39:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEU50401; Mon, 02 Jun 2014 22:39:49 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Jun 2014 23:39:01 +0100 Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Jun 2014 23:39:48 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml706-chm.china.huawei.com ([169.254.8.4]) with mapi id 14.03.0158.001; Mon, 2 Jun 2014 15:39:36 -0700 From: Linda Dunbar To: "Paul E. Jones" , "Charles Eckel (eckelcu)" , "aeon@ietf.org" Thread-Topic: [Aeon] New Version Notification for draft-conet-aeon-problem-statement-00.txt Thread-Index: AQHPdtuQqD2ZBTVI7EKTZI/ZuDsHO5tOqYOAgAZaNRCAAICkgIAI8cBA Date: Mon, 2 Jun 2014 22:39:35 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D2B79D@dfweml701-chm.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645D265BF@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.76] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/x70P4KsvwTZRhGUvOoEnlcVofec Subject: Re: [Aeon] New Version Notification for draft-conet-aeon-problem-statement-00.txt 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, 02 Jun 2014 22:39:58 -0000 Q29tbWVudHMgaW5zZXJ0ZWQgYmVsb3c6DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBQYXVsIEUuIEpvbmVzIFttYWlsdG86cGF1bGVqQHBhY2tldGl6ZXIuY29tXSANClNlbnQ6 IFR1ZXNkYXksIE1heSAyNywgMjAxNCA1OjUzIFBNDQpUbzogTGluZGEgRHVuYmFyOyBDaGFybGVz IEVja2VsIChlY2tlbGN1KTsgYWVvbkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtBZW9uXSBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWNvbmV0LWFlb24tcHJvYmxlbS1zdGF0ZW1l bnQtMDAudHh0DQoNCkxpbmRhLA0KDQpJJ2QgYXNzdW1lIHRoaXMgaXMgb3BlbiBmb3IgZGlzY3Vz c2lvbiwgYnV0IEkgY2FuIGltYWdpbmUgaW5mb3JtYXRpb24gc3VjaCBhcyB0b2xlcmFuY2UgdG8g bG9zcywgZGVsYXksIGFuZCBqaXR0ZXIgYXJlIGltcG9ydGFudC4NCg0KT25lIHBpZWNlIG9mIGRh dGEgSSB0aGluayB3b3VsZCBiZSB1c2VmdWwgdG8gc2VuZCBpbnRvIHRoZSBuZXR3b3JrIGlzIHRo ZSBUcmFmZmljIENsYXNzIExhYmVsIChUQ0wpLCB3aGljaCBpZGVudGlmaWVzIHdpdGggc29tZSBw cmVjaXNpb24gd2hhdCB0aGUgZmxvdyBpcy4gIEZvciBleGFtcGxlLCBpcyB0aGlzIGEgcmVhbC10 aW1lIGdhbWluZyBzZXNzaW9uLCBhIGNvbnZlcnNhdGlvbmFsIHZvaWNlL3ZpZGVvIHNlc3Npb24s IGJ1bGsgZmlsZSB0cmFuc2Zlciwgb3Igb3RoZXI/ICBUaGUgVENMIHdvdWxkIHRlbGwgdXMgdGhp cy4NCg0KQW5vdGhlciBwaWVjZSBvZiBkYXRhIG1pZ2h0IGp1c3QgYmUgc29tZSBraW5kIG9mIGxv Y2FsbHktZGV0ZXJtaW5lZCBwcmlvcml0eSB2YWx1ZS4NCg0KW0xpbmRhXSBJIGNhbiBzZWUgdGhh dCBBcHBsaWNhdGlvbnMgY2FuIGJlIG1vdGl2YXRlZCB0byByZXF1ZXN0IHRob3NlIHRyYWZmaWMg Y2hhcmFjdGVyaXN0aWNzIGZyb20gdG8gbmV0d29yayB0byBhY2hpZXZlIGJldHRlciBzZXJ2aWNl cy4gDQoNClNlbmRpbmcgdGhvc2UgdHJhZmZpYyBjaGFyYWN0ZXJpc3RpY3MgdG8gbmV0d29yayBk ZXZpY2VzIGlzIHNvIG11Y2ggbGlrZSB0aGUgVXNlci1OZXR3b3JrIGludGVyZmFjZSAod2hpY2gg d2FzIGhvdCBkdXJpbmcgMjAwMSB0aW1lIGZyYW1lKS4gQWZ0ZXIgMTUgeWVhcnMsIGl0IHN0aWxs IGRpZG4ndCB0YWtlIG9mZi4gV2h5OiAgQmVjYXVzZSB0aGVyZSBhcmUgc28gbWFueSBhY2Nlc3Mg ZGV2aWNlcyBkZXBsb3llZC4gU2VydmljZSBwcm92aWRlcnMgY2FuJ3QgYWZmb3JkIHRvIHVwZ3Jh ZGUgc3VjaCBtYXNzaXZlbHkgZGVwbG95ZWQgYWNjZXNzIGRldmljZXMgdG8gdGFrZSBjYXJlIG9m IG5ldyBzaWduYWwsIGJpbGxpbmcsIGV0Yy4gDQoNCkEgbXVjaCBtb3JlIHJlYWxpc3RpYyB3YXkg aXMgZm9yIHRoZSBzaWduYWwgdG8gYmUgc2VudCB0byBhICJicm9rZXIiIChvciBjb250cm9sbGVy KSB0aGF0IGNhbiB0YWtlIHJlcXVlc3RzIGZyb20gQXBwbGljYXRpb25zIGFuZCBkaXNwYXRjaCB0 aGUgcmVsZXZhbnQgY29uZmlndXJhdGlvbiB0byB0aGUgbmV0d29yayBlbGVtZW50cy4gDQoNCkxp bmRhIA0KDQogDQoNCg0KWW91J3JlIGNvcnJlY3QgdGhhdCB0cmFmZmljIGlzIGFnZ3JlZ2F0ZWQs IGJ1dCBpdCBtaWdodCBiZSB1c2VmdWwgaWYgdGhpcyBpbmZvcm1hdGlvbiBjb3VsZCBzb21laG93 IGJlIGNvbnZleWVkIGVuZC10by1lbmQgZm9yIHRoZSBiZW5lZml0IG9mIG90aGVyIGNhcnJpZXIg b3IgZW50ZXJwcmlzZSBuZXR3b3Jrcy4NCg0KUGF1bA0KDQotLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLS0NCkZyb206ICJMaW5kYSBEdW5iYXIiIDxsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbT4N ClRvOiAiQ2hhcmxlcyBFY2tlbCAoZWNrZWxjdSkiIDxlY2tlbGN1QGNpc2NvLmNvbT47ICJhZW9u QGlldGYub3JnIiANCjxhZW9uQGlldGYub3JnPg0KU2VudDogNS8yNy8yMDE0IDY6MjI6MDEgUE0N ClN1YmplY3Q6IFJlOiBbQWVvbl0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1j b25ldC1hZW9uLXByb2JsZW0tc3RhdGVtZW50LTAwLnR4dA0KDQo+Q2hhcmxlcywgZXQgYWw6DQo+ DQo+WW91ciBSZXEtMSBzdGF0ZXMgImFsbG93IGFwcGxpY2F0aW9ucyB0byBleHBsaWNpdGx5IHNp Z25hbCB0aGVpciBmbG93IA0KPmNoYXJhY3RlcmlzdGljcyB0byB0aGUgbmV0d29ya3MiLg0KPg0K PkNhbiB5b3UgZ2l2ZSBhIGZldyBleGFtcGxlcyBvZiB3aGF0IHRob3NlICJmbG93IGNoYXJhY3Rl cmlzdGljcyIgYXJlPw0KPg0KPlRoZSBkcmFmdCBhbHNvIHN0YXRlcyB0aGF0IERQSSBjYW4ndCBi ZSBwZXJmb3JtZWQgd2hlbiB0aGUgdHJhZmZpYyBpcyANCj5lbmNyeXB0ZWQuIFdoYXQga2luZCBv ZiBzaWduYWxzIHdpbGwgdGhlIGFwcGxpY2F0aW9ucyB0aGF0IGVuY3J5cHQgDQo+dGhlaXIgdHJh ZmZpYyBzZW5kIHRvIG5ldHdvcms/DQo+DQo+DQo+QWxtb3N0IGFsbCBFbmQgdG8gRW5kIHRyYWZm aWMgYXJlIGFnZ3JlZ2F0ZWQgYnkgbmV0d29yayBvcGVyYXRvcnMgZWRnZSANCj5kZXZpY2VzICh0 aGVyZSBjb3VsZCBiZSBtYW55IGxheWVycyBvZiBvcGVyYXRvcnMpLiBBbGwgdGhlIHNpZ25hbHMg ZnJvbSANCj5lbmQgZGV2aWNlcyBhcmUgbG9zdCBvbmNlIGVudGVyaW5nIHByb3ZpZGVyIGRvbWFp bi4gSSB0aGluayBhIG1vcmUgDQo+cmVhbGlzdGljIGFwcHJvYWNoIGlzIHRvIGVzdGFibGlzaCBp bnRlcmZhY2UgYmV0d2VlbiBhcHBsaWNhdGlvbnMgdG8gDQo+bmV0d29yayBjb250cm9sbGVycy4N Cj4NCj4NCj5MaW5kYQ0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogQWVvbiBb bWFpbHRvOmFlb24tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENoYXJsZXMgRWNrZWwN Cj4oZWNrZWxjdSkNCj5TZW50OiBGcmlkYXksIE1heSAyMywgMjAxNCA2OjEyIFBNDQo+VG86IGFl b25AaWV0Zi5vcmcNCj5TdWJqZWN0OiBbQWVvbl0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgDQo+ZHJhZnQtY29uZXQtYWVvbi1wcm9ibGVtLXN0YXRlbWVudC0wMC50eHQNCj4NCj5U aGUgZm9sbG93aW5nIGRyYWZ0IGlzIHRoZSByZXN1bHQgb2YgbWVyZ2luZyB0aGUgQ29ORVQgYW5k IEFFT04gcHJvYmxlbSANCj5zdGF0ZW1lbnQgZHJhZnRzIGRpc2N1c3NlZCBwcmV2aW91c2x5IG9u IHRoaXMgbGlzdC4gSXQgaXMgaW50ZW5kZWQgYXMgYSANCj5yZXBsYWNlbWVudCBmb3IgYm90aCBv ZiB0aGVtLCBjb21iaW5pbmcgaW1wb3J0YW50IGFzcGVjdHMgb2YgYm90aCBhbmQgDQo+YWRkcmVz c2luZyByZXZpZXcgY29tbWVudHMgcmVjZWl2ZWQgdG8gZGF0ZS4gUGxlYXNlIHJldmlldyBhbmQg c2hhcmUgDQo+eW91ciBjb21tZW50cy4NCj4NCj5DaGVlcnMsDQo+Q2hhcmxlcw0KPg0KPk9uIDUv MjMvMTQsIDQ6MDUgUE0sICJpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIA0KPjxpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc+DQo+d3JvdGU6DQo+DQo+Pg0KPj5BIG5ldyB2ZXJzaW9uIG9mIEktRCwg ZHJhZnQtY29uZXQtYWVvbi1wcm9ibGVtLXN0YXRlbWVudC0wMC50eHQNCj4+aGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBDaGFybGVzIEVja2VsIGFuZCBwb3N0ZWQgdG8gdGhlIA0K Pj5JRVRGIHJlcG9zaXRvcnkuDQo+Pg0KPj5OYW1lOiBkcmFmdC1jb25ldC1hZW9uLXByb2JsZW0t c3RhdGVtZW50DQo+PlJldmlzaW9uOiAwMA0KPj5UaXRsZTogQXBwbGljYXRpb24gRW5hYmxlZCBD b2xsYWJvcmF0aXZlIE5ldHdvcmtpbmc6IFByb2JsZW0gU3RhdGVtZW50IA0KPj5hbmQgUmVxdWly ZW1lbnRzIERvY3VtZW50IGRhdGU6IDIwMTQtMDUtMjENCj4+R3JvdXA6IEluZGl2aWR1YWwgU3Vi bWlzc2lvbg0KPj5QYWdlczogMTENCj4+VVJMOg0KPj5odHRwOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1jb25ldC1hZW9uLXByb2JsZW0tc3RhdGVtZW50LTAwLg0KPj50eHQN Cj4+U3RhdHVzOg0KPj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jb25l dC1hZW9uLXByb2JsZW0tc3RhdGVtZW50Lw0KPj5IdG1saXplZDoNCj4+aHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtY29uZXQtYWVvbi1wcm9ibGVtLXN0YXRlbWVudC0wMA0KPj4NCj4+ DQo+PkFic3RyYWN0Og0KPj4gICAgSWRlbnRpZmljYXRpb24gYW5kIHRyZWF0bWVudCBvZiBhcHBs aWNhdGlvbiBmbG93cyBhcmUgaW1wb3J0YW50IHRvDQo+PiAgICBtYW55IGFwcGxpY2F0aW9uIHBy b3ZpZGVycyBhbmQgbmV0d29yayBvcGVyYXRvcnMuIFRoZXkgb2Z0ZW4gcmVseSANCj4+b24NCj4+ ICAgIHRoZXNlIGNhcGFiaWxpdGllcyB0byBkZXBsb3kgYW5kL29yIHN1cHBvcnQgYSB3aWRlIHJh bmdlIG9mDQo+PiAgICBhcHBsaWNhdGlvbnMuIFRoZXNlIGFwcGxpY2F0aW9ucywgYW5kIHRoZSBw YWNrZXQgZmxvd3MgdGhleSANCj4+Z2VuZXJhdGUNCj4+ICAgIGFuZCBjb25zdW1lLCBtYXkgaGF2 ZSBzcGVjaWZpYyBjb25uZWN0aXZpdHkgcmVxdWlyZW1lbnRzIHRoYXQgY2FuIA0KPj5iZQ0KPj4g ICAgbWV0IGlmIG1hZGUga25vd24gdG8gdGhlIG5ldHdvcmsuIEhpc3RvcmljYWxseSwgdGhpcyBm dW5jdGlvbmFsaXR5DQo+PiAgICBoYXMgYmVlbiBpbXBsZW1lbnRlZCB0byB0aGUgZXh0ZW50IHBv c3NpYmxlIHVzaW5nIGhldXJpc3RpY3MsIHdoaWNoDQo+PiAgICBpbnNwZWN0IGFuZCBpbmZlciBm bG93IGNoYXJhY3RlcmlzdGljcy4gSGV1cmlzdGljcyBtYXkgYmUgYmFzZWQgb24NCj4+ICAgIHBv cnQgcmFuZ2VzLCBuZXR3b3JrIHNlcGFyYXRpb24gKGUuZy4gc3VibmV0cyBvciBWTEFOcywgRGVl cCBGbG93DQo+PiAgICBJbnNwZWN0aW9uIChERkkpLCBvciBEZWVwIFBhY2tldCBJbnNwZWN0aW9u IChEUEkpLiBCdXQgbWFueQ0KPj4gICAgYXBwbGljYXRpb24gZmxvd3MgaW4gY3VycmVudCB1c2Fn ZXMgYXJlIGR5bmFtaWMsIGFkYXB0aXZlLCB0aW1lLQ0KPj4gICAgYm91bmQsIGVuY3J5cHRlZCwg cGVlci10by1wZWVyLCBhc3ltbWV0cmljLCB1c2VkIG9uIG11bHRpcHVycG9zZQ0KPj4gICAgZGV2 aWNlcywgYW5kIGhhdmUgZGlmZmVyZW50IHByaW9yaXRpZXMgZGVwZW5kaW5nIG9uIGRpcmVjdGlv biBvZg0KPj4gICAgZmxvdywgdXNlciBwcmVmZXJlbmNlcywgYW5kIG90aGVyIGZhY3RvcnMuIEFu eSBjb21iaW5hdGlvbiBvZiB0aGVzZQ0KPj4gICAgcHJvcGVydGllcyByZW5kZXJzIGhldXJpc3Rp YyBiYXNlZCB0ZWNobmlxdWVzIGxlc3MgZWZmZWN0aXZlIGFuZCANCj4+bWF5DQo+PiAgICByZXN1 bHQgaW4gY29tcHJvbWlzZXMgdG8gYXBwbGljYXRpb24gc2VjdXJpdHkgb3IgdXNlciBwcml2YWN5 Lg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+PlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIA0KPj5zdWJtaXNzaW9uIHVudGlsIHRo ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgDQo+PnRvb2xzLmll dGYub3JnLg0KPj4NCj4+VGhlIElFVEYgU2VjcmV0YXJpYXQNCj4+DQo+DQo+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5BZW9uIG1haWxpbmcgbGlzdA0K PkFlb25AaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Fl b24NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PkFlb24gbWFpbGluZyBsaXN0DQo+QWVvbkBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vYWVvbg0KDQo= From nobody Mon Jun 2 20:50:11 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 3C78A1A007C for ; Mon, 2 Jun 2014 20:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.328 X-Spam-Level: X-Spam-Status: No, score=-0.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.651] 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 VWA-3gmkM3MQ for ; Mon, 2 Jun 2014 20:50:06 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id A97B91A007A for ; Mon, 2 Jun 2014 20:50:05 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee2538d45c4613-ba613; Tue, 03 Jun 2014 11:49:24 +0800 (CST) X-RM-TRANSID: 2ee2538d45c4613-ba613 Received: from adminPC (unknown[10.2.52.208]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee3538d45c3e8c-0635c; Tue, 03 Jun 2014 11:49:24 +0800 (CST) X-RM-TRANSID: 2ee3538d45c3e8c-0635c From: "Fan, Peng" To: "'Tirumaleswar Reddy \(tireddy\)'" , "'Linda Dunbar'" , References: <4A95BA014132FF49AE685FAB4B9F17F645D2A013@dfweml701-chm.china.huawei.com> <913383AAA69FF945B8F946018B75898A282C5254@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A282C5254@xmb-rcd-x10.cisco.com> Date: Tue, 3 Jun 2014 11:49:44 +0800 Message-ID: <012d01cf7ede$dba2c1f0$92e845d0$@chinamobile.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_012E_01CF7F21.E9CF77D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKbWFxr+ZB151KKZrglIy5w1XDhygFM18Ewmbya86A= Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/MWiRywk5FJtLVQrSipoCxBX8iko Subject: Re: [Aeon] Charter 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: Tue, 03 Jun 2014 03:50:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_012E_01CF7F21.E9CF77D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yes Tiru I have sent the proposal request to both INT and TSV ADs last week. Thank you Linda for your contribution, I will try to incorporate the ideas into the draft charter. Hi all, The current BoF proposal can be found at http://wiki.tools.ietf.org/bof/trac/#Internet. It includes a revised draft charter based on the initial version before the last IETF meeting, and I would appreciate it if you all can share opinions about the current proposal and help revise the draft charter. Best regards, Peng From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy (tireddy) Sent: Monday, June 02, 2014 12:20 PM To: Linda Dunbar; aeon@ietf.org Subject: Re: [Aeon] Charter Proposal I think Peng has already sent the revised charter proposal to AD based on the updated problem statement draft http://tools.ietf.org/html/draft-conet-aeon-problem-statement-00 -Tiru From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Monday, June 02, 2014 3:33 AM To: aeon@ietf.org Subject: Re: [Aeon] Charter Proposal We really need to send the BOF request by Thurs (June 5) because June 6th is the BoF request deadline. The previously proposed charter only focuses on why operators wanting to know applications. Without applications wanting to send their characteristics to network, the network has to depend on DPI (or nothing when the traffic is encrypted). I think that we should change the angle to describe why today's applications need to send their traffic characteristics to network for differentiated services. With this in mind, I rewrote the charter proposal: Do people on the list agree if we can send this charter proposal to the Transport ADs (Spencer & Martin) to request a BoF in Toronto. Linda Description of Working Group: Today's traffic characteristics, such as bandwidth, delay, loss, jitter, etc, are statically configured and managed by service providers on per client or port basis. Even with edge devices or CPE (customer premises equipment) being able to configure different QoS for differentiated network services, the classification is usually coarse and fixed. For example, CPE can assign different QoS to differentiate video, voice and data traffic, but CPE can't differentiate the applications under data category even though more and more data traffic are carrying video content. It is impossible for applications to get differentiated services from public internet, such as hotspot WIFI. It is also not possible for applications to change network behavior. For example it is not easy for AntiDoS applications to enforce certain traffic to a special scrubbing center when some threat is detected. Today, more and more applications need differentiated services from network. Some applications may need special services for a specific time span, while other applications may need to indicate their unique characteristics to the network for special treatment, especially when they send encrypted traffic. The working group will examine what network characteristics that applications need to communicate with network, define general framework and architecture for enabling those communications, examine existing protocols for those communications, and potentially identify new protocols. Specifically, the Working Group will: 1. Identify the applications (or use cases) that need differentiated services, and time based services. 2. identify typical workflows for which heuristic based approaches are used 2. identify limitations of existing solutions 3. create a set of requirements for a solution based on explicit communication between applications and the network that can be applied in a consistent fashion across a variety of signaling protocols 4. identify a set of use cases addressable by such a solution 5. identify the information that needs to be communicated between application and the network 6. create a framework for providing this communication between applications and the network and that addresses the use cases 7. specify how existing signaling protocols can be enhanced to support this framework The Working Group is expected to work closely with other Transport area groups. The following topics are out of scope of this Working Group: TBD Deliverables: TBD Milestones: TBD ------=_NextPart_000_012E_01CF7F21.E9CF77D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes Tiru I have sent the proposal request to = both INT and TSV ADs last week. Thank you Linda for your contribution, I = will try to incorporate the ideas into the draft = charter.

 

Hi = all,

 

The current BoF proposal = can be found at http://wiki.tools.= ietf.org/bof/trac/#Internet. It includes a revised draft charter = based on the initial version before the last IETF meeting, and I would = appreciate it if you all can share opinions about the current proposal = and help revise the draft charter.

 

Best = regards,

Peng

 

From:= = Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Tirumaleswar = Reddy (tireddy)
Sent: Monday, June 02, 2014 12:20 = PM
To: Linda Dunbar; aeon@ietf.org
Subject: Re: = [Aeon] Charter Proposal

 

I think Peng has already sent the revised = charter proposal to AD based on the updated problem statement draft http://tools.ietf.org/html/draft-conet-aeon-problem-statement-00

 

-Tiru

 

From:= = Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Linda = Dunbar
Sent: Monday, June 02, 2014 3:33 AM
To: = aeon@ietf.org
Subject: Re: [Aeon] Charter = Proposal

 

We really = need to send the BOF request by Thurs (June 5) because June = 6th is the BoF request deadline.

The previously proposed charter only focuses on = why operators wanting to know applications. Without applications wanting = to send their characteristics to network, the network has to depend on = DPI (or nothing when the traffic is encrypted).

I think that we should change the angle to = describe why today’s applications need to send their traffic = characteristics to network for differentiated services. With this in = mind, I rewrote the charter proposal:

Do people on the list agree if we can send this = charter  proposal to the Transport ADs (Spencer & Martin) to = request a BoF in Toronto.

Linda

Description of Working Group:

 

Today’s = traffic characteristics, such as bandwidth, delay, loss, jitter, etc, = are statically configured and managed by service providers on per client = or port basis. Even with edge devices or CPE (customer premises = equipment) being able to configure different QoS for differentiated = network services, the classification is usually coarse and fixed. For = example, CPE can assign different QoS to differentiate video, voice and = data traffic, but CPE can’t differentiate the applications under = data category even though more and more data traffic are carrying video = content. 

It is impossible = for applications to get differentiated services from public internet, = such as hotspot WIFI. It is also not possible for applications to change = network behavior. For example it is not easy for AntiDoS applications to = enforce certain traffic to a special scrubbing center when some threat = is detected.

 

Today, more and = more applications need differentiated services from network. Some = applications may need special services for a specific time span, while = other applications may need to indicate their unique characteristics to = the network for special treatment, especially when they send encrypted = traffic.

 

The working group will examine what = network characteristics that applications need to communicate with = network, define general framework and architecture for enabling those = communications, examine existing protocols for those communications, and = potentially identify new protocols.

Specifically, the Working Group will:

1.  Identify the = applications (or use cases) that need differentiated services, and time = based services.

 

2. identify typical = workflows for which heuristic based approaches are = used

2. identify = limitations of existing solutions

3. create a set of requirements for a solution based on = explicit

communication = between applications and the network that can be applied = in

a consistent = fashion across a variety of signaling protocols

4. identify a set of use cases addressable by such a = solution

5. identify the = information that needs to be communicated = between

application and the = network

6. create a = framework for providing this communication = between

applications and = the network and that addresses the use cases

7. specify how existing signaling protocols can be enhanced to = support

this = framework

 

The Working Group = is expected to work closely with other Transport = area

groups.

 

The following = topics are out of scope of this Working Group:

TBD

 

Deliverables:

TBD

 

Milestones:

TBD

 

------=_NextPart_000_012E_01CF7F21.E9CF77D0-- From nobody Tue Jun 3 01:52:12 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 ED4931A0182 for ; Tue, 3 Jun 2014 01:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 3Ihry2LyEaHb for ; Tue, 3 Jun 2014 01:52:06 -0700 (PDT) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA2791A0172 for ; Tue, 3 Jun 2014 01:52:00 -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 s538paWf032633; Tue, 3 Jun 2014 10:51:36 +0200 From: "Jose Saldana" To: "'Linda Dunbar'" , References: <4A95BA014132FF49AE685FAB4B9F17F645D2A013@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D2A013@dfweml701-chm.china.huawei.com> Date: Tue, 3 Jun 2014 10:51:41 +0200 Message-ID: <004001cf7f09$09d37540$1d7a5fc0$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0041_01CF7F19.CD5E4110" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKbWFxr+ZB151KKZrglIy5w1XDhypnHXdcA Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/w2Fo6RZJo58d9MbDbRKgOFxdm-k Subject: Re: [Aeon] Charter 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: Tue, 03 Jun 2014 08:52:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0041_01CF7F19.CD5E4110 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, One question regarding the Charter Proposal. Would the identification of the requirements of each application be within the scope of the WG? I mean, is this WG going to write a document in which different applications and services are classified, and their delay (or jitter) requirements summarized? Perhaps this is out of scope. In that case, a sentence could be added after "The following topics are out of scope of this Working Group" stating that. If this could be within the scope, here is a draft with some delay requirements for small-packet flows: http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/ 6. Delay recommendations . . . . . . . . . . . . . . . . . . . . 8 6.1. VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Online games . . . . . . . . . . . . . . . . . . . . . . 12 6.3. Remote desktop access . . . . . . . . . . . . . . . . . . 13 6.4. Non real-time service . . . . . . . . . . . . . . . . . . 13 6.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 13 Best regards, Jose De: Aeon [mailto:aeon-bounces@ietf.org] En nombre de Linda Dunbar Enviado el: lunes, 02 de junio de 2014 0:03 Para: aeon@ietf.org Asunto: Re: [Aeon] Charter Proposal We really need to send the BOF request by Thurs (June 5) because June 6th is the BoF request deadline. The previously proposed charter only focuses on why operators wanting to know applications. Without applications wanting to send their characteristics to network, the network has to depend on DPI (or nothing when the traffic is encrypted). I think that we should change the angle to describe why today's applications need to send their traffic characteristics to network for differentiated services. With this in mind, I rewrote the charter proposal: Do people on the list agree if we can send this charter proposal to the Transport ADs (Spencer & Martin) to request a BoF in Toronto. Linda Description of Working Group: Today's traffic characteristics, such as bandwidth, delay, loss, jitter, etc, are statically configured and managed by service providers on per client or port basis. Even with edge devices or CPE (customer premises equipment) being able to configure different QoS for differentiated network services, the classification is usually coarse and fixed. For example, CPE can assign different QoS to differentiate video, voice and data traffic, but CPE can't differentiate the applications under data category even though more and more data traffic are carrying video content. It is impossible for applications to get differentiated services from public internet, such as hotspot WIFI. It is also not possible for applications to change network behavior. For example it is not easy for AntiDoS applications to enforce certain traffic to a special scrubbing center when some threat is detected. Today, more and more applications need differentiated services from network. Some applications may need special services for a specific time span, while other applications may need to indicate their unique characteristics to the network for special treatment, especially when they send encrypted traffic. The working group will examine what network characteristics that applications need to communicate with network, define general framework and architecture for enabling those communications, examine existing protocols for those communications, and potentially identify new protocols. Specifically, the Working Group will: 1. Identify the applications (or use cases) that need differentiated services, and time based services. 2. identify typical workflows for which heuristic based approaches are used 2. identify limitations of existing solutions 3. create a set of requirements for a solution based on explicit communication between applications and the network that can be applied in a consistent fashion across a variety of signaling protocols 4. identify a set of use cases addressable by such a solution 5. identify the information that needs to be communicated between application and the network 6. create a framework for providing this communication between applications and the network and that addresses the use cases 7. specify how existing signaling protocols can be enhanced to support this framework The Working Group is expected to work closely with other Transport area groups. The following topics are out of scope of this Working Group: TBD Deliverables: TBD Milestones: TBD ------=_NextPart_000_0041_01CF7F19.CD5E4110 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

One question regarding = the Charter Proposal.

 

Would the = identification of the requirements of each application be within the = scope of the WG? I mean, is this WG going to write a document in which = different applications and services are classified, and their delay (or = jitter) requirements summarized?

 

Perhaps this is out of = scope. In that case, a sentence could be added after “The following topics are out of scope of = this Working Group” stating = that.

 

If this could be = within the scope, here is a draft with some delay requirements for = small-packet flows: http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/

 

   6.  Delay recommendations . . . . . =
. . . . . . . . . . . . . . .   8
     6.1.  VoIP  . . . . . . . . . . . . . . . . =
. . . . . . . . . .  12
     6.2.  Online games  . . . . . . . . . . . . . . . . =
. . . . . .  12
     6.3.  Remote desktop access . . . . . =
. . . . . . . . . . . . .  =
13
     6.4.  Non real-time service . . . . . =
. . . . . . . . . . . . .  =
13
     6.5.  Summary . . . . . . . . . . . . =
. . . . . . . . . . . . .  =
13

 

<= p class=3DMsoNormal>Best = regards,

 

Jose<= /o:p>

 

De: Aeon = [mailto:aeon-bounces@ietf.org] En nombre de Linda = Dunbar
Enviado el: lunes, 02 de junio de 2014 = 0:03
Para: aeon@ietf.org
Asunto: Re: [Aeon] Charter = Proposal

 

We really need to send = the BOF request by Thurs (June 5) because June 6th is the BoF = request deadline.

The previously proposed = charter only focuses on why operators wanting to know applications. = Without applications wanting to send their characteristics to network, = the network has to depend on DPI (or nothing when the traffic is = encrypted).

I think that we should = change the angle to describe why today’s applications need to send = their traffic characteristics to network for differentiated services. = With this in mind, I rewrote the charter = proposal:

Do people on the list = agree if we can send this charter  proposal to the Transport ADs = (Spencer & Martin) to request a BoF in Toronto. =

Linda

Description of Working = Group:

 

Today’s traffic characteristics, = such as bandwidth, delay, loss, jitter, etc, are statically configured = and managed by service providers on per client or port basis. Even with = edge devices or CPE (customer premises equipment) being able to = configure different QoS for differentiated network services, the = classification is usually coarse and fixed. For example, CPE can assign = different QoS to differentiate video, voice and data traffic, but CPE = can’t differentiate the applications under data category even = though more and more data traffic are carrying video content.  =

It is impossible for applications to get = differentiated services from public internet, such as hotspot WIFI. It = is also not possible for applications to change network behavior. For = example it is not easy for AntiDoS applications to enforce certain = traffic to a special scrubbing center when some threat is detected. =

 

Today, more and more applications need = differentiated services from network. Some applications may need special = services for a specific time span, while other applications may need to = indicate their unique characteristics to the network for special = treatment, especially when they send encrypted traffic. =

 

The working group will examine what = network characteristics that applications need to communicate with = network, define general framework and architecture for enabling those = communications, examine existing protocols for those communications, and = potentially identify new protocols.

Specifically, the Working Group = will:

1.  = Identify the applications (or use cases) = that need differentiated services, and time based services. =

 

2. identify typical workflows for which = heuristic based approaches are used

2. identify limitations of existing = solutions

3. create a set of requirements for a = solution based on explicit

communication between applications and the = network that can be applied in

a consistent fashion across a variety of = signaling protocols

4. identify a set of use cases addressable = by such a solution

5. identify the information that needs to = be communicated between

application and the = network

6. create a framework for providing this = communication between

applications and the network and that = addresses the use cases

7. specify how existing signaling = protocols can be enhanced to support

this framework

 

The Working Group is expected to work = closely with other Transport area

groups.

 

The following topics are out of scope of = this Working Group:

TBD

 

Deliverables:

TBD

 

Milestones:

TBD

 

------=_NextPart_000_0041_01CF7F19.CD5E4110-- From nobody Tue Jun 3 08:10: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 7A1F11A02F5 for ; Tue, 3 Jun 2014 08:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.328 X-Spam-Level: X-Spam-Status: No, score=-0.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.651] 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 H4GitNcJMHX6 for ; Tue, 3 Jun 2014 08:09:36 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 005131A02DE for ; Tue, 3 Jun 2014 08:09:33 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.12]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee1538de4ffc87-67c87; Tue, 03 Jun 2014 23:08:48 +0800 (CST) X-RM-TRANSID: 2ee1538de4ffc87-67c87 Received: from adminPC (unknown[125.97.243.132]) by rmsmtp-oa_rmapp02-12002 (RichMail) with SMTP id 2ee2538de4fe26b-c8e4e; Tue, 03 Jun 2014 23:08:48 +0800 (CST) X-RM-TRANSID: 2ee2538de4fe26b-c8e4e From: "Fan, Peng" To: "'Jose Saldana'" , "'Linda Dunbar'" , References: <4A95BA014132FF49AE685FAB4B9F17F645D2A013@dfweml701-chm.china.huawei.com> <004001cf7f09$09d37540$1d7a5fc0$@unizar.es> In-Reply-To: <004001cf7f09$09d37540$1d7a5fc0$@unizar.es> Date: Tue, 3 Jun 2014 23:09:15 +0800 Message-ID: <01c501cf7f3d$c97e3d60$5c7ab820$@chinamobile.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C6_01CF7F80.D7AD3D30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKbWFxr+ZB151KKZrglIy5w1XDhygHK+MgumblamvA= Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/Qf4X9Cv0RysEnn55WyV2gwD-slg Subject: Re: [Aeon] Charter 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: Tue, 03 Jun 2014 15:09:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01C6_01CF7F80.D7AD3D30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Jose, Just to clarify. By "requirements" are you indicating network resources applications are requesting for (e.g. I am a VoIP app and I request for a 100-ms-delay service from the network), or a set of criteria that the network is supposed to meet for different types of applications (e.g. the network is recommended to provide 100 ms delay for VoIP app). I guess we have not considered the latter. The former one reminds me of the information exchanged between applications and network, though it is something in the solution scope which we have not reviewed so much at the current problem identifying stage. From the discussion and drafts till now, information can be something conveyed from application to network, referred to as "characteristics", which can be further divided into: (a) flow description that helps network identify the traffic; (b) network resource request made by applications. or can be something conveyed from network to application, that is (c) some feedback made by network indicating status or whether request can be met or not. This was also raised in Pal's message earlier. I guess we can agree that (a) is the basic information we need to focus on. (b) and (c) propose a good discussion point whether we will cover them as well. Best regards, Peng From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Jose Saldana Sent: Tuesday, June 03, 2014 4:52 PM To: 'Linda Dunbar'; aeon@ietf.org Subject: Re: [Aeon] Charter Proposal Hi, One question regarding the Charter Proposal. Would the identification of the requirements of each application be within the scope of the WG? I mean, is this WG going to write a document in which different applications and services are classified, and their delay (or jitter) requirements summarized? Perhaps this is out of scope. In that case, a sentence could be added after "The following topics are out of scope of this Working Group" stating that. If this could be within the scope, here is a draft with some delay requirements for small-packet flows: http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/ 6. Delay recommendations . . . . . . . . . . . . . . . . . . . . 8 6.1. VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Online games . . . . . . . . . . . . . . . . . . . . . . 12 6.3. Remote desktop access . . . . . . . . . . . . . . . . . . 13 6.4. Non real-time service . . . . . . . . . . . . . . . . . . 13 6.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 13 Best regards, Jose De: Aeon [mailto:aeon-bounces@ietf.org] En nombre de Linda Dunbar Enviado el: lunes, 02 de junio de 2014 0:03 Para: aeon@ietf.org Asunto: Re: [Aeon] Charter Proposal We really need to send the BOF request by Thurs (June 5) because June 6th is the BoF request deadline. The previously proposed charter only focuses on why operators wanting to know applications. Without applications wanting to send their characteristics to network, the network has to depend on DPI (or nothing when the traffic is encrypted). I think that we should change the angle to describe why today's applications need to send their traffic characteristics to network for differentiated services. With this in mind, I rewrote the charter proposal: Do people on the list agree if we can send this charter proposal to the Transport ADs (Spencer & Martin) to request a BoF in Toronto. Linda Description of Working Group: Today's traffic characteristics, such as bandwidth, delay, loss, jitter, etc, are statically configured and managed by service providers on per client or port basis. Even with edge devices or CPE (customer premises equipment) being able to configure different QoS for differentiated network services, the classification is usually coarse and fixed. For example, CPE can assign different QoS to differentiate video, voice and data traffic, but CPE can't differentiate the applications under data category even though more and more data traffic are carrying video content. It is impossible for applications to get differentiated services from public internet, such as hotspot WIFI. It is also not possible for applications to change network behavior. For example it is not easy for AntiDoS applications to enforce certain traffic to a special scrubbing center when some threat is detected. Today, more and more applications need differentiated services from network. Some applications may need special services for a specific time span, while other applications may need to indicate their unique characteristics to the network for special treatment, especially when they send encrypted traffic. The working group will examine what network characteristics that applications need to communicate with network, define general framework and architecture for enabling those communications, examine existing protocols for those communications, and potentially identify new protocols. Specifically, the Working Group will: 1. Identify the applications (or use cases) that need differentiated services, and time based services. 2. identify typical workflows for which heuristic based approaches are used 2. identify limitations of existing solutions 3. create a set of requirements for a solution based on explicit communication between applications and the network that can be applied in a consistent fashion across a variety of signaling protocols 4. identify a set of use cases addressable by such a solution 5. identify the information that needs to be communicated between application and the network 6. create a framework for providing this communication between applications and the network and that addresses the use cases 7. specify how existing signaling protocols can be enhanced to support this framework The Working Group is expected to work closely with other Transport area groups. The following topics are out of scope of this Working Group: TBD Deliverables: TBD Milestones: TBD ------=_NextPart_000_01C6_01CF7F80.D7AD3D30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jose,

 

Just to clarify. By = “requirements” are you indicating network resources = applications are requesting for (e.g. I am a VoIP app and I request for = a 100-ms-delay service from the network), or a set of criteria that the = network is supposed to meet for different types of applications (e.g. = the network is recommended to provide 100 ms delay for VoIP app). I = guess we have not considered the latter.

 

The former one reminds = me of the information exchanged between applications and network, though = it is something in the solution scope which we have not reviewed so much = at the current problem identifying stage. From the discussion and drafts = till now, information can be something conveyed from application to = network, referred to as “characteristics”, which can be = further divided into: (a) flow description that helps network identify = the traffic; (b) network resource request made by = applications.

 

or can be something = conveyed from network to application, that is (c) some feedback made by = network indicating status or whether request can be met or not. This was = also raised in Pal’s message earlier.

 

I guess we can agree = that (a) is the basic information we need to focus on. (b) and (c) = propose a good discussion point whether we will cover them as = well.

 

Best = regards,

Peng

 

From:= = Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Jose = Saldana
Sent: Tuesday, June 03, 2014 4:52 PM
To: = 'Linda Dunbar'; aeon@ietf.org
Subject: Re: [Aeon] Charter = Proposal

 

Hi,

 

One question = regarding the Charter Proposal.

 

Would the = identification of the requirements of each application be within the = scope of the WG? I mean, is this WG going to write a document in which = different applications and services are classified, and their delay (or = jitter) requirements summarized?

 

Perhaps this is = out of scope. In that case, a sentence could be added after = “The following topics are out of scope of this Working Group” = stating = that.

 

If this could = be within the scope, here is a draft with some delay requirements for = small-packet flows: http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/

 

   6.  Delay recommendations . . =
. . . . . . . . . . . . . . . . . .   8
     =
6.1.  VoIP  . . . . . . . =
. . . . . . . . . . . . . . . . . . .  12
     =
6.2.  Online games  . . . =
. . . . . . . . . . . . . . . . . . .  12
     =
6.3.  Remote desktop access . . =
. . . . . . . . . . . . . . . .  13
     =
6.4.  Non real-time service . . =
. . . . . . . . . . . . . . . .  13
     =
6.5.  Summary . . . . . . . . . =
. . . . . . . . . . . . . . . .  13

 

Best = regards,

 

Jose<= /span>

 

De: Aeon = [mailto:aeon-bounces@ietf.org] En nombre de Linda = Dunbar
Enviado el: lunes, 02 de junio de 2014 = 0:03
Para: aeon@ietf.org
Asunto: Re: [Aeon] Charter = Proposal

 

We really = need to send the BOF request by Thurs (June 5) because June = 6th is the BoF request deadline.

The previously proposed charter only focuses on = why operators wanting to know applications. Without applications wanting = to send their characteristics to network, the network has to depend on = DPI (or nothing when the traffic is encrypted).

I think that we should change the angle to = describe why today’s applications need to send their traffic = characteristics to network for differentiated services. With this in = mind, I rewrote the charter proposal:

Do people on the list agree if we can send this = charter  proposal to the Transport ADs (Spencer & Martin) to = request a BoF in Toronto.

Linda

Description of Working Group:

 

Today’s = traffic characteristics, such as bandwidth, delay, loss, jitter, etc, = are statically configured and managed by service providers on per client = or port basis. Even with edge devices or CPE (customer premises = equipment) being able to configure different QoS for differentiated = network services, the classification is usually coarse and fixed. For = example, CPE can assign different QoS to differentiate video, voice and = data traffic, but CPE can’t differentiate the applications under = data category even though more and more data traffic are carrying video = content. 

It is impossible = for applications to get differentiated services from public internet, = such as hotspot WIFI. It is also not possible for applications to change = network behavior. For example it is not easy for AntiDoS applications to = enforce certain traffic to a special scrubbing center when some threat = is detected.

 

Today, more and = more applications need differentiated services from network. Some = applications may need special services for a specific time span, while = other applications may need to indicate their unique characteristics to = the network for special treatment, especially when they send encrypted = traffic.

 

The working group will examine what = network characteristics that applications need to communicate with = network, define general framework and architecture for enabling those = communications, examine existing protocols for those communications, and = potentially identify new protocols.

Specifically, the Working Group will:

1.  Identify the = applications (or use cases) that need differentiated services, and time = based services.

 

2. identify typical = workflows for which heuristic based approaches are = used

2. identify = limitations of existing solutions

3. create a set of requirements for a solution based on = explicit

communication = between applications and the network that can be applied = in

a consistent = fashion across a variety of signaling protocols

4. identify a set of use cases addressable by such a = solution

5. identify the = information that needs to be communicated = between

application and the = network

6. create a = framework for providing this communication = between

applications and = the network and that addresses the use cases

7. specify how existing signaling protocols can be enhanced to = support

this = framework

 

The Working Group = is expected to work closely with other Transport = area

groups.

 

The following = topics are out of scope of this Working Group:

TBD

 

Deliverables:

TBD

 

Milestones:

TBD

 

------=_NextPart_000_01C6_01CF7F80.D7AD3D30-- From nobody Tue Jun 3 08:28: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 B75D01A02EE for ; Tue, 3 Jun 2014 08:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 CmdQk0CWlVqA for ; Tue, 3 Jun 2014 08:28:03 -0700 (PDT) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 224521A021E for ; Tue, 3 Jun 2014 08:28:01 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id s53FRbev032428; Tue, 3 Jun 2014 17:27:37 +0200 From: "Jose Saldana" To: "'Fan, Peng'" , "'Linda Dunbar'" , References: <4A95BA014132FF49AE685FAB4B9F17F645D2A013@dfweml701-chm.china.huawei.com> <004001cf7f09$09d37540$1d7a5fc0$@unizar.es> <01c501cf7f3d$c97e3d60$5c7ab820$@chinamobile.com> In-Reply-To: <01c501cf7f3d$c97e3d60$5c7ab820$@chinamobile.com> Date: Tue, 3 Jun 2014 17:27:40 +0200 Message-ID: <00fb01cf7f40$5c1358c0$143a0a40$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FC_01CF7F51.1F9E99C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKbWFxr+ZB151KKZrglIy5w1XDhygHK+MguAac4Y2GZrDxFQA== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/_oKIfRX_NlKtshFkukjVT8g0Lww Subject: Re: [Aeon] Charter 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: Tue, 03 Jun 2014 15:28:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00FC_01CF7F51.1F9E99C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, My idea is that "requirements" is something that an application requests from the network (the former example): "I am a VoIP app and I request for a 100-ms-delay service from the network". However, perhaps it is not necessary that the application says that. It may only say: "I am a VoIP application". Then the network has a table with types of services and delays, and decides to provide a maximum delay of 100 ms. This would cover (a) and (b). (c) can also be considered: if the network says to a video conference application "at this moment I can only give you 500kbps". Then the video conference application can adjust its codec and its video quality accordingly. And it avoids the need for measuring the available bandwidth continuously. Jose De: Fan, Peng [mailto:fanpeng@chinamobile.com] Enviado el: martes, 03 de junio de 2014 17:09 Para: 'Jose Saldana'; 'Linda Dunbar'; aeon@ietf.org Asunto: RE: [Aeon] Charter Proposal Hi Jose, Just to clarify. By "requirements" are you indicating network resources applications are requesting for (e.g. I am a VoIP app and I request for a 100-ms-delay service from the network), or a set of criteria that the network is supposed to meet for different types of applications (e.g. the network is recommended to provide 100 ms delay for VoIP app). I guess we have not considered the latter. The former one reminds me of the information exchanged between applications and network, though it is something in the solution scope which we have not reviewed so much at the current problem identifying stage. From the discussion and drafts till now, information can be something conveyed from application to network, referred to as "characteristics", which can be further divided into: (a) flow description that helps network identify the traffic; (b) network resource request made by applications. or can be something conveyed from network to application, that is (c) some feedback made by network indicating status or whether request can be met or not. This was also raised in Pal's message earlier. I guess we can agree that (a) is the basic information we need to focus on. (b) and (c) propose a good discussion point whether we will cover them as well. Best regards, Peng From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Jose Saldana Sent: Tuesday, June 03, 2014 4:52 PM To: 'Linda Dunbar'; aeon@ietf.org Subject: Re: [Aeon] Charter Proposal Hi, One question regarding the Charter Proposal. Would the identification of the requirements of each application be within the scope of the WG? I mean, is this WG going to write a document in which different applications and services are classified, and their delay (or jitter) requirements summarized? Perhaps this is out of scope. In that case, a sentence could be added after "The following topics are out of scope of this Working Group" stating that. If this could be within the scope, here is a draft with some delay requirements for small-packet flows: http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/ 6. Delay recommendations . . . . . . . . . . . . . . . . . . . . 8 6.1. VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Online games . . . . . . . . . . . . . . . . . . . . . . 12 6.3. Remote desktop access . . . . . . . . . . . . . . . . . . 13 6.4. Non real-time service . . . . . . . . . . . . . . . . . . 13 6.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 13 Best regards, Jose De: Aeon [mailto:aeon-bounces@ietf.org] En nombre de Linda Dunbar Enviado el: lunes, 02 de junio de 2014 0:03 Para: aeon@ietf.org Asunto: Re: [Aeon] Charter Proposal We really need to send the BOF request by Thurs (June 5) because June 6th is the BoF request deadline. The previously proposed charter only focuses on why operators wanting to know applications. Without applications wanting to send their characteristics to network, the network has to depend on DPI (or nothing when the traffic is encrypted). I think that we should change the angle to describe why today's applications need to send their traffic characteristics to network for differentiated services. With this in mind, I rewrote the charter proposal: Do people on the list agree if we can send this charter proposal to the Transport ADs (Spencer & Martin) to request a BoF in Toronto. Linda Description of Working Group: Today's traffic characteristics, such as bandwidth, delay, loss, jitter, etc, are statically configured and managed by service providers on per client or port basis. Even with edge devices or CPE (customer premises equipment) being able to configure different QoS for differentiated network services, the classification is usually coarse and fixed. For example, CPE can assign different QoS to differentiate video, voice and data traffic, but CPE can't differentiate the applications under data category even though more and more data traffic are carrying video content. It is impossible for applications to get differentiated services from public internet, such as hotspot WIFI. It is also not possible for applications to change network behavior. For example it is not easy for AntiDoS applications to enforce certain traffic to a special scrubbing center when some threat is detected. Today, more and more applications need differentiated services from network. Some applications may need special services for a specific time span, while other applications may need to indicate their unique characteristics to the network for special treatment, especially when they send encrypted traffic. The working group will examine what network characteristics that applications need to communicate with network, define general framework and architecture for enabling those communications, examine existing protocols for those communications, and potentially identify new protocols. Specifically, the Working Group will: 1. Identify the applications (or use cases) that need differentiated services, and time based services. 2. identify typical workflows for which heuristic based approaches are used 2. identify limitations of existing solutions 3. create a set of requirements for a solution based on explicit communication between applications and the network that can be applied in a consistent fashion across a variety of signaling protocols 4. identify a set of use cases addressable by such a solution 5. identify the information that needs to be communicated between application and the network 6. create a framework for providing this communication between applications and the network and that addresses the use cases 7. specify how existing signaling protocols can be enhanced to support this framework The Working Group is expected to work closely with other Transport area groups. The following topics are out of scope of this Working Group: TBD Deliverables: TBD Milestones: TBD ------=_NextPart_000_00FC_01CF7F51.1F9E99C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

My idea is that = “requirements” is something that an application requests = from the network (the former example): “I am a VoIP app and I = request for a 100-ms-delay service from the = network”.

 <= /p>

However, perhaps it is = not necessary that the application says that. It may only say: “I = am a VoIP application”. Then the network has a table with types of = services and delays, and decides to provide a maximum delay of 100 ms. This would cover (a) and = (b).

 <= /p>

(c) can also be = considered: if the network says to a video conference application = “at this moment I can only give you 500kbps”. Then the video = conference application can adjust its codec and its video quality = accordingly. And it avoids the need for measuring the available = bandwidth continuously.

 

Jose

 

De: Fan, Peng = [mailto:fanpeng@chinamobile.com]
Enviado el: martes, 03 de = junio de 2014 17:09
Para: 'Jose Saldana'; 'Linda Dunbar'; = aeon@ietf.org
Asunto: RE: [Aeon] Charter = Proposal

 

Hi = Jose,

 <= /p>

Just to clarify. By = “requirements” are you indicating network resources = applications are requesting for (e.g. I am a VoIP app and I request for = a 100-ms-delay service from the network), or a set of criteria that the = network is supposed to meet for different types of applications (e.g. = the network is recommended to provide 100 ms delay for VoIP app). I = guess we have not considered the latter.

 <= /p>

The former one reminds = me of the information exchanged between applications and network, though = it is something in the solution scope which we have not reviewed so much = at the current problem identifying stage. From the discussion and drafts = till now, information can be something conveyed from application to = network, referred to as “characteristics”, which can be = further divided into: (a) flow description that helps network identify = the traffic; (b) network resource request made by = applications.

 <= /p>

or can be something = conveyed from network to application, that is (c) some feedback made by = network indicating status or whether request can be met or not. This was = also raised in Pal’s message earlier.

 <= /p>

I guess we can agree = that (a) is the basic information we need to focus on. (b) and (c) = propose a good discussion point whether we will cover them as = well.

 <= /p>

Best = regards,

Peng

 <= /p>

From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of = Jose Saldana
Sent: Tuesday, June 03, 2014 4:52 = PM
To: 'Linda Dunbar'; aeon@ietf.org
Subject: Re: = [Aeon] Charter Proposal

 

Hi,

 

One question regarding the Charter = Proposal.

 

Would the identification of the requirements of each application = be within the scope of the WG? I mean, is this WG going to write a = document in which different applications and services are classified, = and their delay (or jitter) requirements = summarized?

 

Perhaps this is out of scope. In that case, a sentence could be = added after “The following topics are out of scope of = this Working Group” stating that.

 

If this could be within the scope, here is a draft with some = delay requirements for small-packet flows: http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/

 

   6.  Delay recommendations =
. . . . . . . . . . . . . . . . . . . .   8
     =
6.1.  VoIP  . . . . . . =
. . . . . . . . . . . . . . . . . . . .  12
     =
6.2.  Online games  . . =
. . . . . . . . . . . . . . . . . . . .  12
     =
6.3.  Remote desktop access =
. . . . . . . . . . . . . . . . . .  13
     =
6.4.  Non real-time service =
. . . . . . . . . . . . . . . . . .  13
     =
6.5.  Summary . . . . . . . =
. . . . . . . . . . . . . . . . . .  13

 

Best regards,

 

Jose

 

De: = Aeon [mailto:aeon-bounces@ietf.org] En nombre de Linda = Dunbar
Enviado el: lunes, 02 de junio de 2014 = 0:03
Para: aeon@ietf.org
Asunto: Re: [Aeon] Charter = Proposal

 

We really need to send = the BOF request by Thurs (June 5) because June 6th is the BoF = request deadline.

The previously = proposed charter only focuses on why operators wanting to know = applications. Without applications wanting to send their characteristics = to network, the network has to depend on DPI (or nothing when the = traffic is encrypted).

I think that we = should change the angle to describe why today’s applications need = to send their traffic characteristics to network for differentiated = services. With this in mind, I rewrote the charter = proposal:

Do people on the list = agree if we can send this charter  proposal to the Transport ADs = (Spencer & Martin) to request a BoF in Toronto. =

Linda =

Description of Working = Group:

 

Today’s traffic characteristics, = such as bandwidth, delay, loss, jitter, etc, are statically configured = and managed by service providers on per client or port basis. Even with = edge devices or CPE (customer premises equipment) being able to = configure different QoS for differentiated network services, the = classification is usually coarse and fixed. For example, CPE can assign = different QoS to differentiate video, voice and data traffic, but CPE = can’t differentiate the applications under data category even = though more and more data traffic are carrying video content.  =

It is impossible for applications to get = differentiated services from public internet, such as hotspot WIFI. It = is also not possible for applications to change network behavior. For = example it is not easy for AntiDoS applications to enforce certain = traffic to a special scrubbing center when some threat is detected. =

 

Today, more and more applications need = differentiated services from network. Some applications may need special = services for a specific time span, while other applications may need to = indicate their unique characteristics to the network for special = treatment, especially when they send encrypted traffic. =

 

The working group will examine what = network characteristics that applications need to communicate with = network, define general framework and architecture for enabling those = communications, examine existing protocols for those communications, and = potentially identify new protocols.

=

Specifically, the Working Group = will:

1.  = Identify the applications (or use cases) = that need differentiated services, and time based services. =

 

2. identify typical workflows for which = heuristic based approaches are used

2. identify limitations of existing = solutions

3. create a set of requirements for a = solution based on explicit

communication between applications and the = network that can be applied in

a consistent fashion across a variety of = signaling protocols

4. identify a set of use cases addressable = by such a solution

5. identify the information that needs to = be communicated between

application and the = network

6. create a framework for providing this = communication between

applications and the network and that = addresses the use cases

7. specify how existing signaling = protocols can be enhanced to support

this framework

 

The Working Group is expected to work = closely with other Transport area

groups.

 

The following topics are out of scope of = this Working Group:

TBD

 

Deliverables:

TBD

 

Milestones:

TBD

 

------=_NextPart_000_00FC_01CF7F51.1F9E99C0-- From nobody Tue Jun 3 08:50: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 C191A1A02B7 for ; Tue, 3 Jun 2014 08:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 cB90y69PJacR for ; Tue, 3 Jun 2014 08:50:48 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75BC61A02B8 for ; Tue, 3 Jun 2014 08:50:48 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MGzr0-1X5aEz00Pa-00DOhQ; Tue, 03 Jun 2014 11:50:40 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_E6119978-C597-4D9F-833D-4AA921B96D78" From: Alper Yegin In-Reply-To: <012d01cf7ede$dba2c1f0$92e845d0$@chinamobile.com> Date: Tue, 3 Jun 2014 18:50:33 +0300 Message-Id: <4848737B-6665-4FDB-B479-37FA0DBBEC54@yegin.org> References: <4A95BA014132FF49AE685FAB4B9F17F645D2A013@dfweml701-chm.china.huawei.com> <913383AAA69FF945B8F946018B75898A282C5254@xmb-rcd-x10.cisco.com> <012d01cf7ede$dba2c1f0$92e845d0$@chinamobile.com> To: "Fan, Peng" X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:um0+3LZPJQGNk861Y+hrRt85GRjcUrREPDMNDtdik/2 c8t/l2DtNdGo8ayjk8Jx9TSR0NFQoTLf7C3UoqXXJPUyeGZ0sc QpfctXr8SaWsgXtGHizVl+Xglv7f2WvnkMRoRjzg6aOLTLY7cJ +gPiSCitykQZqvjwTQNe6m97Jk9u80jg0Muca1kvkY/1aIKKoE Ul3fG/DdgNokGGkvurKPl2FS3+4f5/CHm+alDvydVlWAGM/wKR V9CxViaAq/Wr/46NlURqkoEK38eNqWVQbpqzpC96v0i/6ce/pj 8jChz392y8bTQyZi8+MvgSqt/ET4BBESi1/KljgOkkb/cLd8cy r42V76nKDkLSj/sf1UFZY5OHnm8I68nfo+kzm6IXDFNHzVyCOO SRCTayfjrA+mw== Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/FQ3uCmP1ZWK_Jf-vfZiRO0PGB88 Cc: aeon@ietf.org, "'Tirumaleswar Reddy \(tireddy\)'" , 'Linda Dunbar' Subject: Re: [Aeon] Charter 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: Tue, 03 Jun 2014 15:50:52 -0000 --Apple-Mail=_E6119978-C597-4D9F-833D-4AA921B96D78 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Peng, What are the target deliverables for the WG-to-be-formed?=20 They are not explicitly listed, but I gather "problem statement", "use = cases", "gap analysis", and "requirements" from the charter text. We better explicitly enumerate them. Cheers, Alper On Jun 3, 2014, at 6:49 AM, Fan, Peng wrote: > Yes Tiru I have sent the proposal request to both INT and TSV ADs last = week. Thank you Linda for your contribution, I will try to incorporate = the ideas into the draft charter. > =20 > Hi all, > =20 > The current BoF proposal can be found at = http://wiki.tools.ietf.org/bof/trac/#Internet. It includes a revised = draft charter based on the initial version before the last IETF meeting, = and I would appreciate it if you all can share opinions about the = current proposal and help revise the draft charter. > =20 > Best regards, > Peng > =20 > From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Tirumaleswar = Reddy (tireddy) > Sent: Monday, June 02, 2014 12:20 PM > To: Linda Dunbar; aeon@ietf.org > Subject: Re: [Aeon] Charter Proposal > =20 > I think Peng has already sent the revised charter proposal to AD based = on the updated problem statement = drafthttp://tools.ietf.org/html/draft-conet-aeon-problem-statement-00 > =20 > -Tiru > =20 > From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Linda Dunbar > Sent: Monday, June 02, 2014 3:33 AM > To: aeon@ietf.org > Subject: Re: [Aeon] Charter Proposal > =20 > We really need to send the BOF request by Thurs (June 5) because June = 6th is the BoF request deadline. > The previously proposed charter only focuses on why operators wanting = to know applications. Without applications wanting to send their = characteristics to network, the network has to depend on DPI (or nothing = when the traffic is encrypted). >=20 > I think that we should change the angle to describe why today=92s = applications need to send their traffic characteristics to network for = differentiated services. With this in mind, I rewrote the charter = proposal: >=20 > Do people on the list agree if we can send this charter proposal to = the Transport ADs (Spencer & Martin) to request a BoF in Toronto. >=20 > Linda >=20 > Description of Working Group: > =20 > Today=92s traffic characteristics, such as bandwidth, delay, loss, = jitter, etc, are statically configured and managed by service providers = on per client or port basis. Even with edge devices or CPE (customer = premises equipment) being able to configure different QoS for = differentiated network services, the classification is usually coarse = and fixed. For example, CPE can assign different QoS to differentiate = video, voice and data traffic, but CPE can=92t differentiate the = applications under data category even though more and more data traffic = are carrying video content.=20 > It is impossible for applications to get differentiated services from = public internet, such as hotspot WIFI. It is also not possible for = applications to change network behavior. For example it is not easy for = AntiDoS applications to enforce certain traffic to a special scrubbing = center when some threat is detected. > =20 > Today, more and more applications need differentiated services from = network. Some applications may need special services for a specific time = span, while other applications may need to indicate their unique = characteristics to the network for special treatment, especially when = they send encrypted traffic. > =20 > The working group will examine what network characteristics that = applications need to communicate with network, define general framework = and architecture for enabling those communications, examine existing = protocols for those communications, and potentially identify new = protocols. >=20 > Specifically, the Working Group will: > 1. Identify the applications (or use cases) that need differentiated = services, and time based services. > =20 > 2. identify typical workflows for which heuristic based approaches are = used > 2. identify limitations of existing solutions > 3. create a set of requirements for a solution based on explicit > communication between applications and the network that can be applied = in > a consistent fashion across a variety of signaling protocols > 4. identify a set of use cases addressable by such a solution > 5. identify the information that needs to be communicated between > application and the network > 6. create a framework for providing this communication between > applications and the network and that addresses the use cases > 7. specify how existing signaling protocols can be enhanced to support > this framework > =20 > The Working Group is expected to work closely with other Transport = area > groups. > =20 > The following topics are out of scope of this Working Group: > TBD > =20 > Deliverables: > TBD > =20 > Milestones: > TBD > =20 > _______________________________________________ > Aeon mailing list > Aeon@ietf.org > https://www.ietf.org/mailman/listinfo/aeon --Apple-Mail=_E6119978-C597-4D9F-833D-4AA921B96D78 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hello Peng,

What are the target = deliverables for the WG-to-be-formed? 
They are not = explicitly listed, but I gather "problem statement", "use cases", "gap = analysis", and "requirements" from the charter text.
We better = explicitly enumerate = them.

Cheers,

Alper





On Jun 3, 2014, at 6:49 AM, Fan, Peng wrote:

Yes Tiru I have sent the proposal request to both INT and = TSV ADs last week. Thank you Linda for your contribution, I will try to = incorporate the ideas into the draft = charter.
 
Hi all,
 
The current BoF = proposal can be found at  
I think Peng has already = sent the revised charter proposal to AD based on the updated problem = statement draft 
We really need to send the BOF = request by Thurs (June 5) because June 6th is the BoF request = deadline.

The previously = proposed charter only focuses on why operators wanting to know = applications. Without applications wanting to send their characteristics = to network, the network has to depend on DPI (or nothing when the = traffic is encrypted).

I = think that we should change the angle to describe why today=92s = applications need to send their traffic characteristics to network for = differentiated services. With this in mind, I rewrote the charter = proposal:

Do people on the = list agree if we can send this charter  proposal to the Transport = ADs (Spencer & Martin) to request a BoF in = Toronto.

Linda

Description of = Working Group:
 
Today=92s traffic characteristics, such as bandwidth, delay, = loss, jitter, etc, are statically configured and managed by service = providers on per client or port basis. Even with edge devices or CPE = (customer premises equipment) being able to configure different QoS for = differentiated network services, the classification is usually coarse = and fixed. For example, CPE can assign different QoS to differentiate = video, voice and data traffic, but CPE can=92t differentiate the = applications under data category even though more and more data traffic = are carrying video content. 
It is impossible for applications to get differentiated services = from public internet, such as hotspot WIFI. It is also not possible for = applications to change network behavior. For example it is not easy for = AntiDoS applications to enforce certain traffic to a special scrubbing = center when some threat is detected.
 
Today, more and more applications = need differentiated services from network. Some applications may need = special services for a specific time span, while other applications may = need to indicate their unique characteristics to the network for special = treatment, especially when they send encrypted = traffic.
 

The = working group will examine what network characteristics that = applications need to communicate with network, define general framework = and architecture for enabling those communications, examine existing = protocols for those communications, and potentially identify new = protocols.

Specifically, the Working Group = will:
1.  Identify the = applications (or use cases) that need differentiated services, and time = based services.
2. identify typical workflows for = which heuristic based approaches are used
2. identify limitations of existing = solutions
3. create a set of requirements for = a solution based on explicit
communication between applications and the network that can be = applied in
a consistent fashion across a = variety of signaling protocols
4. identify a set of use cases addressable by such a = solution
5. identify the information that = needs to be communicated between
application and the network
6. create a framework for providing this communication = between
applications and the network and = that addresses the use cases
7. specify how existing signaling protocols can be enhanced to = support
this = framework
 
The Working Group is expected to work closely with other = Transport area
groups.
 
The following topics are out of = scope of this Working Group:
TBD
 
Deliverables:
 
Milestones:
Aeon@ietf.org
https://www.ietf.org/ma= ilman/listinfo/aeon

= --Apple-Mail=_E6119978-C597-4D9F-833D-4AA921B96D78-- From nobody Tue Jun 3 08:57:18 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 23C8E1A02E6 for ; Tue, 3 Jun 2014 08:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 VsH9y8avUcJh for ; Tue, 3 Jun 2014 08:57:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEB611A02DB for ; Tue, 3 Jun 2014 08:57:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHU46437; Tue, 03 Jun 2014 15:57:04 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Jun 2014 16:56:18 +0100 Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Jun 2014 16:57:03 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml706-chm.china.huawei.com ([169.254.8.4]) with mapi id 14.03.0158.001; Tue, 3 Jun 2014 08:57:01 -0700 From: Linda Dunbar To: "Fan, Peng" , "'Tirumaleswar Reddy (tireddy)'" , "aeon@ietf.org" Thread-Topic: [Aeon] Charter Proposal Thread-Index: AQHPfhnw3Imxc3bm1U2GdVSmBEV9z5tfNtoAgABUNgA= Date: Tue, 3 Jun 2014 15:57:00 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D2BDA6@dfweml701-chm.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645D2A013@dfweml701-chm.china.huawei.com> <913383AAA69FF945B8F946018B75898A282C5254@xmb-rcd-x10.cisco.com> <012d01cf7ede$dba2c1f0$92e845d0$@chinamobile.com> In-Reply-To: <012d01cf7ede$dba2c1f0$92e845d0$@chinamobile.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.147.16] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D2BDA6dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/P7gXeM-ljpNIr0q7LhFuqn9xh68 Subject: Re: [Aeon] Charter 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: Tue, 03 Jun 2014 15:57:16 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645D2BDA6dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Peng, The current charter statement is all about applications exchanging informat= ion with network functions, such as DPI, FW, etc. This is the Metadata, which have been addressed by SFC WG. Why creating a = new WG simply for Metadata? Besides, all traffic will be aggregated by the = provider edge devices. The DPI/FW in the middle of the provider networks ca= n't even seen those metadata attached to Applications, unless using a new h= eader such as SFC header to carry those metadata. Linda From: Fan, Peng [mailto:fanpeng@chinamobile.com] Sent: Monday, June 02, 2014 10:50 PM To: 'Tirumaleswar Reddy (tireddy)'; Linda Dunbar; aeon@ietf.org Subject: RE: [Aeon] Charter Proposal Yes Tiru I have sent the proposal request to both INT and TSV ADs last week= . Thank you Linda for your contribution, I will try to incorporate the idea= s into the draft charter. Hi all, The current BoF proposal can be found at http://wiki.tools.ietf.org/bof/tra= c/#Internet. It includes a revised draft charter based on the initial versi= on before the last IETF meeting, and I would appreciate it if you all can s= hare opinions about the current proposal and help revise the draft charter. Best regards, Peng From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy (= tireddy) Sent: Monday, June 02, 2014 12:20 PM To: Linda Dunbar; aeon@ietf.org Subject: Re: [Aeon] Charter Proposal I think Peng has already sent the revised charter proposal to AD based on t= he updated problem statement draft http://tools.ietf.org/html/draft-conet-a= eon-problem-statement-00 -Tiru From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Monday, June 02, 2014 3:33 AM To: aeon@ietf.org Subject: Re: [Aeon] Charter Proposal We really need to send the BOF request by Thurs (June 5) because June 6th i= s the BoF request deadline. The previously proposed charter only focuses on why operators wanting to kn= ow applications. Without applications wanting to send their characteristics= to network, the network has to depend on DPI (or nothing when the traffic = is encrypted). I think that we should change the angle to describe why today's application= s need to send their traffic characteristics to network for differentiated = services. With this in mind, I rewrote the charter proposal: Do people on the list agree if we can send this charter proposal to the Tr= ansport ADs (Spencer & Martin) to request a BoF in Toronto. Linda Description of Working Group: Today's traffic characteristics, such as bandwidth, delay, loss, jitter, et= c, are statically configured and managed by service providers on per client= or port basis. Even with edge devices or CPE (customer premises equipment)= being able to configure different QoS for differentiated network services,= the classification is usually coarse and fixed. For example, CPE can assig= n different QoS to differentiate video, voice and data traffic, but CPE can= 't differentiate the applications under data category even though more and = more data traffic are carrying video content. It is impossible for applications to get differentiated services from publi= c internet, such as hotspot WIFI. It is also not possible for applications = to change network behavior. For example it is not easy for AntiDoS applicat= ions to enforce certain traffic to a special scrubbing center when some thr= eat is detected. Today, more and more applications need differentiated services from network= . Some applications may need special services for a specific time span, whi= le other applications may need to indicate their unique characteristics to = the network for special treatment, especially when they send encrypted traf= fic. The working group will examine what network characteristics that applicatio= ns need to communicate with network, define general framework and architect= ure for enabling those communications, examine existing protocols for those= communications, and potentially identify new protocols. Specifically, the Working Group will: 1. Identify the applications (or use cases) that need differentiated servi= ces, and time based services. 2. identify typical workflows for which heuristic based approaches are used 2. identify limitations of existing solutions 3. create a set of requirements for a solution based on explicit communication between applications and the network that can be applied in a consistent fashion across a variety of signaling protocols 4. identify a set of use cases addressable by such a solution 5. identify the information that needs to be communicated between application and the network 6. create a framework for providing this communication between applications and the network and that addresses the use cases 7. specify how existing signaling protocols can be enhanced to support this framework The Working Group is expected to work closely with other Transport area groups. The following topics are out of scope of this Working Group: TBD Deliverables: TBD Milestones: TBD --_000_4A95BA014132FF49AE685FAB4B9F17F645D2BDA6dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Peng,

 

The current charter st= atement is all about applications exchanging information with network funct= ions, such as DPI, FW, etc.

 

This is the Metadata, =  which have been addressed by SFC WG. Why creating a new WG simply for= Metadata? Besides, all traffic will be aggregated by the provider edge dev= ices. The DPI/FW in the middle of the provider networks can’t even seen those metadata attached to Applications, un= less using a new header such as SFC header to carry those metadata.

 

Linda

 

 

From: Fan, Pen= g [mailto:fanpeng@chinamobile.com]
Sent: Monday, June 02, 2014 10:50 PM
To: 'Tirumaleswar Reddy (tireddy)'; Linda Dunbar; aeon@ietf.org
Subject: RE: [Aeon] Charter Proposal

 

Yes Tiru I have sent t= he proposal request to both INT and TSV ADs last week. Thank you Linda for = your contribution, I will try to incorporate the ideas into the draft chart= er.

 

Hi all,

 

The current BoF propos= al can be found at http://wiki.tools= .ietf.org/bof/trac/#Internet. It includes a revised draft charter based= on the initial version before the last IETF meeting, and I would appreciat= e it if you all can share opinions about the current proposal and help revise the draft charter.

 

Best regards,

Peng=

 

From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy (tireddy)
Sent: Monday, June 02, 2014 12:20 PM
To: Linda Dunbar; aeon@ietf.org=
Subject: Re: [Aeon] Charter Proposal

 

I think Peng= has already sent the revised charter proposal to AD based on the updated p= roblem statement draft http://tools.ietf.org/html/draft-conet-aeon-problem-statement-00=

 

-Tiru

 

From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Monday, June 02, 2014 3:33 AM
To: aeon@ietf.org
Subject: Re: [Aeon] Charter Proposal

 

We really need to send the BOF request by Thurs (Jun= e 5) because June 6th is the BoF request deadline.

The previously proposed charter only focuses on why operat= ors wanting to know applications. Without applications wanting to send thei= r characteristics to network, the network has to depend on DPI (or nothing when the traffic is encrypted).

I think that we should change the angle to describe why to= day’s applications need to send their traffic characteristics to netw= ork for differentiated services. With this in mind, I rewrote the charter proposal:

Do people on the list agree if we can send this charter &n= bsp;proposal to the Transport ADs (Spencer & Martin) to request a BoF i= n Toronto.

Linda

Description of Working Group:

 

Today’s traffic characteristics, such as bandwidth, = delay, loss, jitter, etc, are statically configured and managed by service = providers on per client or port basis. Even with edge devices or CPE (customer premises equipment) being able to configure diffe= rent QoS for differentiated network services, the classification is usually= coarse and fixed. For example, CPE can assign different QoS to differentia= te video, voice and data traffic, but CPE can’t differentiate the applications under data category eve= n though more and more data traffic are carrying video content. 

It is impossible for applications to get differentiated se= rvices from public internet, such as hotspot WIFI. It is also not possible = for applications to change network behavior. For example it is not easy for AntiDoS applications to enforce certain traffic= to a special scrubbing center when some threat is detected.

 

Today, more and more applications need differentiated serv= ices from network. Some applications may need special services for a specif= ic time span, while other applications may need to indicate their unique characteristics to the network for special treatm= ent, especially when they send encrypted traffic.

 

The working group will= examine what network characteristics that applications need to communicate= with network, define general framework and architecture for enabling those communications, examine existing protocols for those co= mmunications, and potentially identify new protocols.

Specifically, the Working Group will:

1.  Identify the applications (or use cases) that need= differentiated services, and time based services.

&= nbsp;

2. identify typical workflows for which heuristic based ap= proaches are used

2. identify limitations of existing solutions

3. create a set of requirements for a solution based on ex= plicit

communication between applications and the network that ca= n be applied in

a consistent fashion across a variety of signaling protoco= ls

4. identify a set of use cases addressable by such a solut= ion

5. identify the information that needs to be communicated = between

application and the network

6. create a framework for providing this communication bet= ween

applications and the network and that addresses the use ca= ses

7. specify how existing signaling protocols can be enhance= d to support

this framework

 

The Working Group is expected to work closely with other T= ransport area

groups.

 

The following topics are out of scope of this Working Grou= p:

TBD

 

Deliverables:

TBD

 

Milestones:

TBD

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645D2BDA6dfweml701chmchi_-- From nobody Wed Jun 4 06:11:28 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 7A78F1A0230 for ; Wed, 4 Jun 2014 06:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.328 X-Spam-Level: X-Spam-Status: No, score=-0.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.651] 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 kQkoLnWci7Cu for ; Wed, 4 Jun 2014 06:11:21 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id BC70C1A020A for ; Wed, 4 Jun 2014 06:11:19 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee1538f1acc0da-7e0da; Wed, 04 Jun 2014 21:10:36 +0800 (CST) X-RM-TRANSID: 2ee1538f1acc0da-7e0da Received: from adminPC (unknown[125.97.44.175]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee3538f1aca6c0-22ffb; Wed, 04 Jun 2014 21:10:36 +0800 (CST) X-RM-TRANSID: 2ee3538f1aca6c0-22ffb From: "Fan, Peng" To: "'Alper Yegin'" References: <4A95BA014132FF49AE685FAB4B9F17F645D2A013@dfweml701-chm.china.huawei.com> <913383AAA69FF945B8F946018B75898A282C5254@xmb-rcd-x10.cisco.com> <012d01cf7ede$dba2c1f0$92e845d0$@chinamobile.com> <4848737B-6665-4FDB-B479-37FA0DBBEC54@yegin.org> In-Reply-To: <4848737B-6665-4FDB-B479-37FA0DBBEC54@yegin.org> Date: Wed, 4 Jun 2014 21:11:02 +0800 Message-ID: <005201cf7ff6$6fe625b0$4fb27110$@chinamobile.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0053_01CF8039.7E13C5F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKbWFxr+ZB151KKZrglIy5w1XDhygFM18EwAxJnrbQCdGYyYZmSiFkA Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/xHJ3UewQBiJqEDAGGqZULKWMkFg Cc: aeon@ietf.org, "'Tirumaleswar Reddy \(tireddy\)'" , 'Linda Dunbar' Subject: Re: [Aeon] Charter 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, 04 Jun 2014 13:11:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0053_01CF8039.7E13C5F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Alper, Thanks for the advice. I revised the proposal a little to make it clearer, you can find the latest version at http://tools.ietf.org/bof/trac/#Internet. We may still need to change the draft charter after further revision. My understanding is that the short term deliverables are those background items you gathered. Then we can re-charter to enter the solution space, e.g. information that needs to be communicated between applications and the network, framework for providing such communication, protocol extension to support this framework, etc. Best regards, Peng From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Alper Yegin Sent: Tuesday, June 03, 2014 11:51 PM To: Fan, Peng Cc: aeon@ietf.org; 'Tirumaleswar Reddy (tireddy)'; 'Linda Dunbar' Subject: Re: [Aeon] Charter Proposal Hello Peng, What are the target deliverables for the WG-to-be-formed? They are not explicitly listed, but I gather "problem statement", "use cases", "gap analysis", and "requirements" from the charter text. We better explicitly enumerate them. Cheers, Alper On Jun 3, 2014, at 6:49 AM, Fan, Peng wrote: Yes Tiru I have sent the proposal request to both INT and TSV ADs last week. Thank you Linda for your contribution, I will try to incorporate the ideas into the draft charter. Hi all, The current BoF proposal can be found at http://wiki.tools.ietf.org/bof/trac/#Internet. It includes a revised draft charter based on the initial version before the last IETF meeting, and I would appreciate it if you all can share opinions about the current proposal and help revise the draft charter. Best regards, Peng From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy (tireddy) Sent: Monday, June 02, 2014 12:20 PM To: Linda Dunbar; aeon@ietf.org Subject: Re: [Aeon] Charter Proposal I think Peng has already sent the revised charter proposal to AD based on the updated problem statement drafthttp://tools.ietf.org/html/draft-conet-aeon-problem-statement-00 -Tiru From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Monday, June 02, 2014 3:33 AM To: aeon@ietf.org Subject: Re: [Aeon] Charter Proposal We really need to send the BOF request by Thurs (June 5) because June 6th is the BoF request deadline. The previously proposed charter only focuses on why operators wanting to know applications. Without applications wanting to send their characteristics to network, the network has to depend on DPI (or nothing when the traffic is encrypted). I think that we should change the angle to describe why today's applications need to send their traffic characteristics to network for differentiated services. With this in mind, I rewrote the charter proposal: Do people on the list agree if we can send this charter proposal to the Transport ADs (Spencer & Martin) to request a BoF in Toronto. Linda Description of Working Group: Today's traffic characteristics, such as bandwidth, delay, loss, jitter, etc, are statically configured and managed by service providers on per client or port basis. Even with edge devices or CPE (customer premises equipment) being able to configure different QoS for differentiated network services, the classification is usually coarse and fixed. For example, CPE can assign different QoS to differentiate video, voice and data traffic, but CPE can't differentiate the applications under data category even though more and more data traffic are carrying video content. It is impossible for applications to get differentiated services from public internet, such as hotspot WIFI. It is also not possible for applications to change network behavior. For example it is not easy for AntiDoS applications to enforce certain traffic to a special scrubbing center when some threat is detected. Today, more and more applications need differentiated services from network. Some applications may need special services for a specific time span, while other applications may need to indicate their unique characteristics to the network for special treatment, especially when they send encrypted traffic. The working group will examine what network characteristics that applications need to communicate with network, define general framework and architecture for enabling those communications, examine existing protocols for those communications, and potentially identify new protocols. Specifically, the Working Group will: 1. Identify the applications (or use cases) that need differentiated services, and time based services. 2. identify typical workflows for which heuristic based approaches are used 2. identify limitations of existing solutions 3. create a set of requirements for a solution based on explicit communication between applications and the network that can be applied in a consistent fashion across a variety of signaling protocols 4. identify a set of use cases addressable by such a solution 5. identify the information that needs to be communicated between application and the network 6. create a framework for providing this communication between applications and the network and that addresses the use cases 7. specify how existing signaling protocols can be enhanced to support this framework The Working Group is expected to work closely with other Transport area groups. The following topics are out of scope of this Working Group: TBD Deliverables: TBD Milestones: TBD _______________________________________________ Aeon mailing list Aeon@ietf.org https://www.ietf.org/mailman/listinfo/aeon ------=_NextPart_000_0053_01CF8039.7E13C5F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alper,

 

Thanks for the advice. I revised the proposal a little to make it = clearer, you can find the latest version at http://tools.ietf.org/b= of/trac/#Internet. We may still need to change the draft charter = after further revision.

 

My understanding is that the short term deliverables are those = background items you gathered. Then we can re-charter to enter the = solution space, e.g. information that needs to be communicated between = applications and the network, framework for providing such = communication, protocol extension to support this framework, = etc.

 

Best regards,

Peng

 

From:= = Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Alper = Yegin
Sent: Tuesday, June 03, 2014 11:51 PM
To: Fan, = Peng
Cc: aeon@ietf.org; 'Tirumaleswar Reddy (tireddy)'; 'Linda = Dunbar'
Subject: Re: [Aeon] Charter = Proposal

 

Hello = Peng,

 

What are the target deliverables for the = WG-to-be-formed? 

They are not explicitly listed, but I gather = "problem statement", "use cases", "gap = analysis", and "requirements" from the charter = text.

We better explicitly = enumerate them.

 

Cheers,

 

Alper

 

 

 

 

 

On = Jun 3, 2014, at 6:49 AM, Fan, Peng wrote:



Yes Tiru I have sent the proposal request to both INT and TSV ADs = last week. Thank you Linda for your contribution, I will try to = incorporate the ideas into the draft charter.=

 =

Hi all,=

 =

The current BoF proposal can be found at http://wiki.tools.= ietf.org/bof/trac/#Internet. It includes a revised draft charter = based on the initial version before the last IETF meeting, and I would = appreciate it if you all can share opinions about the current proposal = and help revise the draft charter.=

 =

Best regards,=

Peng=

 =

From:=  Aeon = [mailto:aeon-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy = (tireddy)
Sent: Monday, June 02, 2014 12:20 = PM
To: Linda = Dunbar; aeon@ietf.org
Subject: Re: [Aeon] Charter = Proposal=

 =

I think Peng has = already sent the revised charter proposal to AD based on the updated = problem statement drafthttp://tools.ietf.org/html/draft-conet-aeon-problem-statement-00

 =

-Tiru<= /o:p>

 =

From:=  Aeon = [mailto:aeon-bounces@ietf.org] On Behalf Of Linda = Dunbar
Sent: Monday, June 02, 2014 3:33 = AM
To: aeon@ietf.org
Subject: Re: [Aeon] Charter = Proposal=

 =

We really = need to send the BOF request by Thurs (June 5) because June = 6th is the = BoF request deadline.

The = previously proposed charter only focuses on why operators wanting to = know applications. Without applications wanting to send their = characteristics to network, the network has to depend on DPI (or nothing = when the traffic is encrypted).

I think = that we should change the angle to describe why today’s = applications need to send their traffic characteristics to network for = differentiated services. With this in mind, I rewrote the charter = proposal:

Do people = on the list agree if we can send this charter  proposal to the = Transport ADs (Spencer & Martin) to request a BoF in = Toronto.

Linda<= /o:p>

Description of = Working Group:=

 =

Today’s = traffic characteristics, such as bandwidth, delay, loss, jitter, etc, = are statically configured and managed by service providers on per client = or port basis. Even with edge devices or CPE (customer premises = equipment) being able to configure different QoS for differentiated = network services, the classification is usually coarse and fixed. For = example, CPE can assign different QoS to differentiate video, voice and = data traffic, but CPE can’t differentiate the applications under = data category even though more and more data traffic are carrying video = content. =

It is impossible = for applications to get differentiated services from public internet, = such as hotspot WIFI. It is also not possible for applications to change = network behavior. For example it is not easy for AntiDoS applications to = enforce certain traffic to a special scrubbing center when some threat = is detected.=

 =

Today, more and = more applications need differentiated services from network. Some = applications may need special services for a specific time span, while = other applications may need to indicate their unique characteristics to = the network for special treatment, especially when they send encrypted = traffic.=

 =

The working group will examine what network characteristics that = applications need to communicate with network, define general framework = and architecture for enabling those communications, examine existing = protocols for those communications, and potentially identify new = protocols.=

Specifically, the = Working Group will:=

1.  Identify the = applications (or use cases) that need differentiated services, and time = based services.=

 =

2. identify typical = workflows for which heuristic based approaches are used=

2. identify = limitations of existing solutions=

3. create a set of = requirements for a solution based on explicit=

communication = between applications and the network that can be applied in=

a consistent = fashion across a variety of signaling protocols=

4. identify a set = of use cases addressable by such a solution=

5. identify the = information that needs to be communicated between=

application and the = network=

6. create a = framework for providing this communication between=

applications and = the network and that addresses the use cases=

7. specify how = existing signaling protocols can be enhanced to support=

this = framework=

 =

The Working Group = is expected to work closely with other Transport area=

groups.=

 =

The following = topics are out of scope of this Working Group:=

TBD=

 =

Deliverables:=

TBD=

 =

Milestones:=

TBD=

 =

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

 

------=_NextPart_000_0053_01CF8039.7E13C5F0-- From nobody Wed Jun 4 06:16: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 9153D1A0238 for ; Wed, 4 Jun 2014 06:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.328 X-Spam-Level: X-Spam-Status: No, score=-0.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.651] 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 fLaX82M4aA0j for ; Wed, 4 Jun 2014 06:16:32 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id A4C9C1A0236 for ; Wed, 4 Jun 2014 06:16:29 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.12]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee2538f1c093e3-dc3e3; Wed, 04 Jun 2014 21:15:53 +0800 (CST) X-RM-TRANSID: 2ee2538f1c093e3-dc3e3 Received: from adminPC (unknown[125.97.44.175]) by rmsmtp-oa_rmapp02-12002 (RichMail) with SMTP id 2ee2538f1c0791e-d7a6a; Wed, 04 Jun 2014 21:15:53 +0800 (CST) X-RM-TRANSID: 2ee2538f1c0791e-d7a6a From: "Fan, Peng" To: "'Linda Dunbar'" , "'Tirumaleswar Reddy \(tireddy\)'" , References: <4A95BA014132FF49AE685FAB4B9F17F645D2A013@dfweml701-chm.china.huawei.com> <913383AAA69FF945B8F946018B75898A282C5254@xmb-rcd-x10.cisco.com> <012d01cf7ede$dba2c1f0$92e845d0$@chinamobile.com> <4A95BA014132FF49AE685FAB4B9F17F645D2BDA6@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D2BDA6@dfweml701-chm.china.huawei.com> Date: Wed, 4 Jun 2014 21:16:19 +0800 Message-ID: <005d01cf7ff7$2cdcc7f0$869657d0$@chinamobile.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005E_01CF803A.3B058630" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKbWFxr+ZB151KKZrglIy5w1XDhygFM18EwAxJnrbQCHMa3QpmVSbHQ Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/8qf3fxULuwSa0MBpOe1xyCdlQyU Subject: Re: [Aeon] Charter 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, 04 Jun 2014 13:16:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_005E_01CF803A.3B058630 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Linda, I am trying to understand why the metadata is not visible to network. Flow characteristics, or metadata, are conveyed to network nodes which can be a gateway, a router, or other elements that need visibility into the traffic. These nodes are not necessarily a DPI element, and are not necessarily located at the edge or center of a network. Speaking of SFC metadata I would like to know how is it related with flow characteristics we are now working on. We have not gone that far in discussing how the characteristics are encoded and carried, though at the very early age of this work there were some drafts on this. Also I remember this minutes of the barbof at London IETF which I think is helpful in showing some of the concepts of this work http://www.ietf.org/mail-archive/web/aeon/current/msg00025.html. Best regards, Peng From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Tuesday, June 03, 2014 11:57 PM To: Fan, Peng; 'Tirumaleswar Reddy (tireddy)'; aeon@ietf.org Subject: Re: [Aeon] Charter Proposal Peng, The current charter statement is all about applications exchanging information with network functions, such as DPI, FW, etc. This is the Metadata, which have been addressed by SFC WG. Why creating a new WG simply for Metadata? Besides, all traffic will be aggregated by the provider edge devices. The DPI/FW in the middle of the provider networks can't even seen those metadata attached to Applications, unless using a new header such as SFC header to carry those metadata. Linda From: Fan, Peng [mailto:fanpeng@chinamobile.com] Sent: Monday, June 02, 2014 10:50 PM To: 'Tirumaleswar Reddy (tireddy)'; Linda Dunbar; aeon@ietf.org Subject: RE: [Aeon] Charter Proposal Yes Tiru I have sent the proposal request to both INT and TSV ADs last week. Thank you Linda for your contribution, I will try to incorporate the ideas into the draft charter. Hi all, The current BoF proposal can be found at http://wiki.tools.ietf.org/bof/trac/#Internet. It includes a revised draft charter based on the initial version before the last IETF meeting, and I would appreciate it if you all can share opinions about the current proposal and help revise the draft charter. Best regards, Peng From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy (tireddy) Sent: Monday, June 02, 2014 12:20 PM To: Linda Dunbar; aeon@ietf.org Subject: Re: [Aeon] Charter Proposal I think Peng has already sent the revised charter proposal to AD based on the updated problem statement draft http://tools.ietf.org/html/draft-conet-aeon-problem-statement-00 -Tiru From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Monday, June 02, 2014 3:33 AM To: aeon@ietf.org Subject: Re: [Aeon] Charter Proposal We really need to send the BOF request by Thurs (June 5) because June 6th is the BoF request deadline. The previously proposed charter only focuses on why operators wanting to know applications. Without applications wanting to send their characteristics to network, the network has to depend on DPI (or nothing when the traffic is encrypted). I think that we should change the angle to describe why today's applications need to send their traffic characteristics to network for differentiated services. With this in mind, I rewrote the charter proposal: Do people on the list agree if we can send this charter proposal to the Transport ADs (Spencer & Martin) to request a BoF in Toronto. Linda Description of Working Group: Today's traffic characteristics, such as bandwidth, delay, loss, jitter, etc, are statically configured and managed by service providers on per client or port basis. Even with edge devices or CPE (customer premises equipment) being able to configure different QoS for differentiated network services, the classification is usually coarse and fixed. For example, CPE can assign different QoS to differentiate video, voice and data traffic, but CPE can't differentiate the applications under data category even though more and more data traffic are carrying video content. It is impossible for applications to get differentiated services from public internet, such as hotspot WIFI. It is also not possible for applications to change network behavior. For example it is not easy for AntiDoS applications to enforce certain traffic to a special scrubbing center when some threat is detected. Today, more and more applications need differentiated services from network. Some applications may need special services for a specific time span, while other applications may need to indicate their unique characteristics to the network for special treatment, especially when they send encrypted traffic. The working group will examine what network characteristics that applications need to communicate with network, define general framework and architecture for enabling those communications, examine existing protocols for those communications, and potentially identify new protocols. Specifically, the Working Group will: 1. Identify the applications (or use cases) that need differentiated services, and time based services. 2. identify typical workflows for which heuristic based approaches are used 2. identify limitations of existing solutions 3. create a set of requirements for a solution based on explicit communication between applications and the network that can be applied in a consistent fashion across a variety of signaling protocols 4. identify a set of use cases addressable by such a solution 5. identify the information that needs to be communicated between application and the network 6. create a framework for providing this communication between applications and the network and that addresses the use cases 7. specify how existing signaling protocols can be enhanced to support this framework The Working Group is expected to work closely with other Transport area groups. The following topics are out of scope of this Working Group: TBD Deliverables: TBD Milestones: TBD ------=_NextPart_000_005E_01CF803A.3B058630 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Linda,

 

I am trying to = understand why the metadata is not visible to network. Flow = characteristics, or metadata, are conveyed to network nodes which can be = a gateway, a router, or other elements that need visibility into the = traffic. These nodes are not necessarily a DPI element, and are not = necessarily located at the edge or center of a network. Speaking of SFC = metadata I would like to know how is it related with flow = characteristics we are now working on.

 

We have not gone that = far in discussing how the characteristics are encoded and carried, = though at the very early age of this work there were some drafts on = this. Also I remember this minutes of the barbof at London IETF which I = think is helpful in showing some of the concepts of this work = http://www.ietf.org/mail-archive/web/aeon/current/msg00025.html.=

 

Best = regards,

Peng

 

From:= = Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Linda = Dunbar
Sent: Tuesday, June 03, 2014 11:57 PM
To: = Fan, Peng; 'Tirumaleswar Reddy (tireddy)'; = aeon@ietf.org
Subject: Re: [Aeon] Charter = Proposal

 

Peng,

 

The current charter = statement is all about applications exchanging information with network = functions, such as DPI, FW, etc.

 

This is the Metadata, =  which have been addressed by SFC WG. Why creating a new WG simply = for Metadata? Besides, all traffic will be aggregated by the provider = edge devices. The DPI/FW in the middle of the provider networks = can’t even seen those metadata attached to Applications, unless = using a new header such as SFC header to carry those metadata. =

 

Linda

 

 

From:= = Fan, Peng [mailto:fanpeng@chinamobile.com]
Sent: Monday, June = 02, 2014 10:50 PM
To: 'Tirumaleswar Reddy (tireddy)'; Linda = Dunbar; aeon@ietf.org
Subject: RE: [Aeon] Charter = Proposal

 

Yes Tiru I have sent the proposal request to = both INT and TSV ADs last week. Thank you Linda for your contribution, I = will try to incorporate the ideas into the draft = charter.

 

Hi = all,

 

The current BoF proposal = can be found at http://wiki.tools.= ietf.org/bof/trac/#Internet. It includes a revised draft charter = based on the initial version before the last IETF meeting, and I would = appreciate it if you all can share opinions about the current proposal = and help revise the draft charter.

 

Best = regards,

Peng

 

From:= = Aeon [mailto:aeon-bounces@ietf.org] = On Behalf Of Tirumaleswar Reddy (tireddy)
Sent: Monday, = June 02, 2014 12:20 PM
To: Linda Dunbar; aeon@ietf.org
Subject: Re: = [Aeon] Charter Proposal

 

I think Peng has already sent the revised = charter proposal to AD based on the updated problem statement draft http://tools.ietf.org/html/draft-conet-aeon-problem-statement-00

 

-Tiru

 

From:= = Aeon [mailto:aeon-bounces@ietf.org] = On Behalf Of Linda Dunbar
Sent: Monday, June 02, 2014 = 3:33 AM
To: aeon@ietf.org
Subject: Re: = [Aeon] Charter Proposal

 

We really = need to send the BOF request by Thurs (June 5) because June = 6th is the BoF request deadline.

The previously proposed charter only focuses = on why operators wanting to know applications. Without applications = wanting to send their characteristics to network, the network has to = depend on DPI (or nothing when the traffic is encrypted). =

I think = that we should change the angle to describe why today’s = applications need to send their traffic characteristics to network for = differentiated services. With this in mind, I rewrote the charter = proposal:

Do = people on the list agree if we can send this charter  proposal to = the Transport ADs (Spencer & Martin) to request a BoF in Toronto. =

Linda =

Description of = Working Group:

 

Today’s = traffic characteristics, such as bandwidth, delay, loss, jitter, etc, = are statically configured and managed by service providers on per client = or port basis. Even with edge devices or CPE (customer premises = equipment) being able to configure different QoS for differentiated = network services, the classification is usually coarse and fixed. For = example, CPE can assign different QoS to differentiate video, voice and = data traffic, but CPE can’t differentiate the applications under = data category even though more and more data traffic are carrying video = content. 

It is impossible = for applications to get differentiated services from public internet, = such as hotspot WIFI. It is also not possible for applications to change = network behavior. For example it is not easy for AntiDoS applications to = enforce certain traffic to a special scrubbing center when some threat = is detected.

 

Today, more and = more applications need differentiated services from network. Some = applications may need special services for a specific time span, while = other applications may need to indicate their unique characteristics to = the network for special treatment, especially when they send encrypted = traffic.

 

The working group = will examine what network characteristics that applications need to = communicate with network, define general framework and architecture for = enabling those communications, examine existing protocols for those = communications, and potentially identify new protocols.

Specifically, the Working Group will:

1.  Identify the = applications (or use cases) that need differentiated services, and time = based services.

 

2. identify typical = workflows for which heuristic based approaches are = used

2. identify = limitations of existing solutions

3. create a set of requirements for a solution based on = explicit

communication = between applications and the network that can be applied = in

a consistent = fashion across a variety of signaling protocols

4. identify a set of use cases addressable by such a = solution

5. identify the = information that needs to be communicated = between

application and the = network

6. create a = framework for providing this communication = between

applications and = the network and that addresses the use cases

7. specify how existing signaling protocols can be enhanced to = support

this = framework

 

The Working Group = is expected to work closely with other Transport = area

groups.

 

The following = topics are out of scope of this Working Group:

TBD

 

Deliverables:

TBD

 

Milestones:

TBD

 

------=_NextPart_000_005E_01CF803A.3B058630-- From nobody Wed Jun 4 09:23:16 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 06C4A1A02D9 for ; Wed, 4 Jun 2014 09:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 WILeipiDAu8P for ; Wed, 4 Jun 2014 09:23:11 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA52A1A021E for ; Wed, 4 Jun 2014 09:23:10 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MYQ4v-1XMjFF1Ps1-00VKm6; Wed, 04 Jun 2014 12:22:51 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_DD7AB49A-E6DB-4C38-88D7-3875918E731A" From: Alper Yegin In-Reply-To: <005201cf7ff6$6fe625b0$4fb27110$@chinamobile.com> Date: Wed, 4 Jun 2014 19:22:42 +0300 Message-Id: <5F193F94-A927-43CC-A3A6-39068406F305@yegin.org> References: <4A95BA014132FF49AE685FAB4B9F17F645D2A013@dfweml701-chm.china.huawei.com> <913383AAA69FF945B8F946018B75898A282C5254@xmb-rcd-x10.cisco.com> <012d01cf7ede$dba2c1f0$92e845d0$@chinamobile.com> <4848737B-6665-4FDB-B479-37FA0DBBEC54@yegin.org> <005201cf7ff6$6fe625b0$4fb27110$@chinamobile.com> To: "Fan, Peng" X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:PgJAKVqVcOqf4p/GJnjiUtZ10eEpEfOam1vBy6yABQE /DxA5C54gn+GObvjsV5HhFUvzB6oOECBbOF5hVSi7bC7hbBbaq dDuG15CQtROZWI/aMlNbrGDDkEnkYzlovPoMzhXmsvqHDIQ8iK PeqiskunV4HhlnFS1urECQj6h3HbZsSbsXOHoz1duWg1Fun5Vk r9EBPUdSQcW32KyYN5kSmsCT8vOkVf3rNmGQIWDwZDytBg/fYg neMQlePjAfMwh9YKPL7e85nX54g058zFy/PzwopAK84qyekYfW czWp9ff81HGLtTwrkpkc9LjONd3/5QmaHQEXD/7uoKnm4p2WiL H6fLob2BPYl/mORzyklGv6webJrU3WSamZs4rmvqa4JUJBjFfZ F7mm/iRQRcqQA== Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/m-FaPrkYgupH4mE2_tmhUYV9kEc Cc: aeon@ietf.org, "'Tirumaleswar Reddy \(tireddy\)'" , 'Linda Dunbar' Subject: Re: [Aeon] Charter 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, 04 Jun 2014 16:23:14 -0000 --Apple-Mail=_DD7AB49A-E6DB-4C38-88D7-3875918E731A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Peng, Looks good, thank you. Alper On Jun 4, 2014, at 4:11 PM, Fan, Peng wrote: > Hi Alper, > =20 > Thanks for the advice. I revised the proposal a little to make it = clearer, you can find the latest version = athttp://tools.ietf.org/bof/trac/#Internet. We may still need to change = the draft charter after further revision. > =20 > My understanding is that the short term deliverables are those = background items you gathered. Then we can re-charter to enter the = solution space, e.g. information that needs to be communicated between = applications and the network, framework for providing such = communication, protocol extension to support this framework, etc. > =20 > Best regards, > Peng > =20 > From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Alper Yegin > Sent: Tuesday, June 03, 2014 11:51 PM > To: Fan, Peng > Cc: aeon@ietf.org; 'Tirumaleswar Reddy (tireddy)'; 'Linda Dunbar' > Subject: Re: [Aeon] Charter Proposal > =20 > Hello Peng, > =20 > What are the target deliverables for the WG-to-be-formed?=20 > They are not explicitly listed, but I gather "problem statement", "use = cases", "gap analysis", and "requirements" from the charter text. > We better explicitly enumerate them. > =20 > Cheers, > =20 > Alper > =20 > =20 > =20 > =20 > =20 > On Jun 3, 2014, at 6:49 AM, Fan, Peng wrote: >=20 >=20 > Yes Tiru I have sent the proposal request to both INT and TSV ADs last = week. Thank you Linda for your contribution, I will try to incorporate = the ideas into the draft charter. > =20 > Hi all, > =20 > The current BoF proposal can be found at = http://wiki.tools.ietf.org/bof/trac/#Internet. It includes a revised = draft charter based on the initial version before the last IETF meeting, = and I would appreciate it if you all can share opinions about the = current proposal and help revise the draft charter. > =20 > Best regards, > Peng > =20 > From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Tirumaleswar = Reddy (tireddy) > Sent: Monday, June 02, 2014 12:20 PM > To: Linda Dunbar; aeon@ietf.org > Subject: Re: [Aeon] Charter Proposal > =20 > I think Peng has already sent the revised charter proposal to AD based = on the updated problem statement = drafthttp://tools.ietf.org/html/draft-conet-aeon-problem-statement-00 > =20 > -Tiru > =20 > From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Linda Dunbar > Sent: Monday, June 02, 2014 3:33 AM > To: aeon@ietf.org > Subject: Re: [Aeon] Charter Proposal > =20 > We really need to send the BOF request by Thurs (June 5) because June = 6th is the BoF request deadline. > The previously proposed charter only focuses on why operators wanting = to know applications. Without applications wanting to send their = characteristics to network, the network has to depend on DPI (or nothing = when the traffic is encrypted). >=20 > I think that we should change the angle to describe why today=92s = applications need to send their traffic characteristics to network for = differentiated services. With this in mind, I rewrote the charter = proposal: >=20 > Do people on the list agree if we can send this charter proposal to = the Transport ADs (Spencer & Martin) to request a BoF in Toronto. >=20 > Linda >=20 > Description of Working Group: > =20 > Today=92s traffic characteristics, such as bandwidth, delay, loss, = jitter, etc, are statically configured and managed by service providers = on per client or port basis. Even with edge devices or CPE (customer = premises equipment) being able to configure different QoS for = differentiated network services, the classification is usually coarse = and fixed. For example, CPE can assign different QoS to differentiate = video, voice and data traffic, but CPE can=92t differentiate the = applications under data category even though more and more data traffic = are carrying video content.=20 > It is impossible for applications to get differentiated services from = public internet, such as hotspot WIFI. It is also not possible for = applications to change network behavior. For example it is not easy for = AntiDoS applications to enforce certain traffic to a special scrubbing = center when some threat is detected. > =20 > Today, more and more applications need differentiated services from = network. Some applications may need special services for a specific time = span, while other applications may need to indicate their unique = characteristics to the network for special treatment, especially when = they send encrypted traffic. > =20 > The working group will examine what network characteristics that = applications need to communicate with network, define general framework = and architecture for enabling those communications, examine existing = protocols for those communications, and potentially identify new = protocols. >=20 > Specifically, the Working Group will: > 1. Identify the applications (or use cases) that need differentiated = services, and time based services. > =20 > 2. identify typical workflows for which heuristic based approaches are = used > 2. identify limitations of existing solutions > 3. create a set of requirements for a solution based on explicit > communication between applications and the network that can be applied = in > a consistent fashion across a variety of signaling protocols > 4. identify a set of use cases addressable by such a solution > 5. identify the information that needs to be communicated between > application and the network > 6. create a framework for providing this communication between > applications and the network and that addresses the use cases > 7. specify how existing signaling protocols can be enhanced to support > this framework > =20 > The Working Group is expected to work closely with other Transport = area > groups. > =20 > The following topics are out of scope of this Working Group: > TBD > =20 > Deliverables: > TBD > =20 > Milestones: > TBD > =20 > _______________________________________________ > Aeon mailing list > Aeon@ietf.org > https://www.ietf.org/mailman/listinfo/aeon > =20 > _______________________________________________ > Aeon mailing list > Aeon@ietf.org > https://www.ietf.org/mailman/listinfo/aeon --Apple-Mail=_DD7AB49A-E6DB-4C38-88D7-3875918E731A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Peng,

Looks good, thank = you.

Alper

On Jun 4, = 2014, at 4:11 PM, Fan, Peng wrote:

Hi = Alper,
My = understanding is that the short term deliverables are those background = items you gathered. Then we can re-charter to enter the solution space, = e.g. information that needs to be communicated between applications and = the network, framework for providing such communication, protocol = extension to support this framework, etc.
Best = regards,
From: Aeon = [mailto:aeon-bounces@ietf.org] On Behalf Of Alper = Yegin
Sent: Tuesday, June 03, 2014 = 11:51 PM
To: Fan, = Peng
Cc: aeon@ietf.org; 'Tirumaleswar Reddy = (tireddy)'; 'Linda Dunbar'
Subject: Re: [Aeon] Charter = Proposal
Hello = Peng,
What are the target = deliverables for the = WG-to-be-formed? 
They are not explicitly listed, but I gather "problem = statement", "use cases", "gap analysis", and "requirements" from the = charter text.
We better explicitly = enumerate them.
On Jun 3, 2014, at 6:49 = AM, Fan, Peng wrote:
Yes = Tiru I have sent the proposal request to both INT and TSV ADs last week. = Thank you Linda for your contribution, I will try to incorporate the = ideas into the draft charter.
Hi all,
The current BoF proposal can be found at 
 
I think Peng has = already sent the revised charter proposal to AD based on the updated = problem statement draft
 
We really need to send the BOF request by Thurs (June 5) = because June 6th is the BoF request = deadline.

The = previously proposed charter only focuses on why operators wanting to = know applications. Without applications wanting to send their = characteristics to network, the network has to depend on DPI (or nothing = when the traffic is encrypted).

I think that we should change the angle to describe why = today=92s applications need to send their traffic characteristics to = network for differentiated services. With this in mind, I rewrote the = charter proposal:

Do people = on the list agree if we can send this charter  proposal to the = Transport ADs (Spencer & Martin) to request a BoF in = Toronto.

Linda

Description of Working Group: Today=92s traffic characteristics, = such as bandwidth, delay, loss, jitter, etc, are statically configured = and managed by service providers on per client or port basis. Even with = edge devices or CPE (customer premises equipment) being able to = configure different QoS for differentiated network services, the = classification is usually coarse and fixed. For example, CPE can assign = different QoS to differentiate video, voice and data traffic, but CPE = can=92t differentiate the applications under data category even though = more and more data traffic are carrying video content. It is impossible for applications to = get differentiated services from public internet, such as hotspot WIFI. = It is also not possible for applications to change network behavior. For = example it is not easy for AntiDoS applications to enforce certain = traffic to a special scrubbing center when some threat is = detected.
Today, more and = more applications need differentiated services from network. Some = applications may need special services for a specific time span, while = other applications may need to indicate their unique characteristics to = the network for special treatment, especially when they send encrypted = traffic.

The working = group will examine what network characteristics that applications need = to communicate with network, define general framework and architecture = for enabling those communications, examine existing protocols for those = communications, and potentially identify new protocols.Specifically, the Working Group = will:

1. Identify the = applications (or use cases) that need differentiated services, and time = based services.
 2. identify typical workflows for = which heuristic based approaches are used2. identify limitations of existing = solutions
3. create a set = of requirements for a solution based on explicitcommunication between applications = and the network that can be applied ina consistent fashion across a = variety of signaling protocols4. identify a set of use cases = addressable by such a solution5. identify the information that = needs to be communicated betweenapplication and the = network
6. create a = framework for providing this communication betweenapplications and the network and = that addresses the use cases7. specify how existing signaling = protocols can be enhanced to supportthis framework The Working Group is expected to = work closely with other Transport areagroups. The following topics are out of = scope of this Working Group:TBD Deliverables:TBD Milestones:TBDAeon@ietf.org
, "'Tirumaleswar Reddy (tireddy)'" , "aeon@ietf.org" Thread-Topic: [Aeon] Charter Proposal Thread-Index: AQHPfhnw3Imxc3bm1U2GdVSmBEV9z5tfNtoAgABUNgCAAdxsgP//wl1g Date: Wed, 4 Jun 2014 17:31:38 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D2DFDC@dfweml701-chm.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645D2A013@dfweml701-chm.china.huawei.com> <913383AAA69FF945B8F946018B75898A282C5254@xmb-rcd-x10.cisco.com> <012d01cf7ede$dba2c1f0$92e845d0$@chinamobile.com> <4A95BA014132FF49AE685FAB4B9F17F645D2BDA6@dfweml701-chm.china.huawei.com> <005d01cf7ff7$2cdcc7f0$869657d0$@chinamobile.com> In-Reply-To: <005d01cf7ff7$2cdcc7f0$869657d0$@chinamobile.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.155.225] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D2DFDCdfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/-w-HRk2z3CwMlcUwVJsHsmBHkvQ Subject: Re: [Aeon] Charter 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, 04 Jun 2014 17:32:08 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645D2DFDCdfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Peng, For metadata to be visible to the network, the metadata have to be carried = in a header such as SFC header. Is AEON also defining this Metadata header? Should the Metadata Header defi= ned by AEON consistent with the Metadata defined by SFC? I am just concerned if AEON only focus on the metadata between applications= and service functions, then AEON would become a subset of SFC WG deliverab= les. Linda From: Fan, Peng [mailto:fanpeng@chinamobile.com] Sent: Wednesday, June 04, 2014 8:16 AM To: Linda Dunbar; 'Tirumaleswar Reddy (tireddy)'; aeon@ietf.org Subject: RE: [Aeon] Charter Proposal Hi Linda, I am trying to understand why the metadata is not visible to network. Flow = characteristics, or metadata, are conveyed to network nodes which can be a = gateway, a router, or other elements that need visibility into the traffic.= These nodes are not necessarily a DPI element, and are not necessarily loc= ated at the edge or center of a network. Speaking of SFC metadata I would l= ike to know how is it related with flow characteristics we are now working = on. We have not gone that far in discussing how the characteristics are encoded= and carried, though at the very early age of this work there were some dra= fts on this. Also I remember this minutes of the barbof at London IETF whic= h I think is helpful in showing some of the concepts of this work http://ww= w.ietf.org/mail-archive/web/aeon/current/msg00025.html. Best regards, Peng From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Tuesday, June 03, 2014 11:57 PM To: Fan, Peng; 'Tirumaleswar Reddy (tireddy)'; aeon@ietf.org Subject: Re: [Aeon] Charter Proposal Peng, The current charter statement is all about applications exchanging informat= ion with network functions, such as DPI, FW, etc. This is the Metadata, which have been addressed by SFC WG. Why creating a = new WG simply for Metadata? Besides, all traffic will be aggregated by the = provider edge devices. The DPI/FW in the middle of the provider networks ca= n't even seen those metadata attached to Applications, unless using a new h= eader such as SFC header to carry those metadata. Linda From: Fan, Peng [mailto:fanpeng@chinamobile.com] Sent: Monday, June 02, 2014 10:50 PM To: 'Tirumaleswar Reddy (tireddy)'; Linda Dunbar; aeon@ietf.org Subject: RE: [Aeon] Charter Proposal Yes Tiru I have sent the proposal request to both INT and TSV ADs last week= . Thank you Linda for your contribution, I will try to incorporate the idea= s into the draft charter. Hi all, The current BoF proposal can be found at http://wiki.tools.ietf.org/bof/tra= c/#Internet. It includes a revised draft charter based on the initial versi= on before the last IETF meeting, and I would appreciate it if you all can s= hare opinions about the current proposal and help revise the draft charter. Best regards, Peng From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy (= tireddy) Sent: Monday, June 02, 2014 12:20 PM To: Linda Dunbar; aeon@ietf.org Subject: Re: [Aeon] Charter Proposal I think Peng has already sent the revised charter proposal to AD based on t= he updated problem statement draft http://tools.ietf.org/html/draft-conet-a= eon-problem-statement-00 -Tiru From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Monday, June 02, 2014 3:33 AM To: aeon@ietf.org Subject: Re: [Aeon] Charter Proposal We really need to send the BOF request by Thurs (June 5) because June 6th i= s the BoF request deadline. The previously proposed charter only focuses on why operators wanting to kn= ow applications. Without applications wanting to send their characteristics= to network, the network has to depend on DPI (or nothing when the traffic = is encrypted). I think that we should change the angle to describe why today's application= s need to send their traffic characteristics to network for differentiated = services. With this in mind, I rewrote the charter proposal: Do people on the list agree if we can send this charter proposal to the Tr= ansport ADs (Spencer & Martin) to request a BoF in Toronto. Linda Description of Working Group: Today's traffic characteristics, such as bandwidth, delay, loss, jitter, et= c, are statically configured and managed by service providers on per client= or port basis. Even with edge devices or CPE (customer premises equipment)= being able to configure different QoS for differentiated network services,= the classification is usually coarse and fixed. For example, CPE can assig= n different QoS to differentiate video, voice and data traffic, but CPE can= 't differentiate the applications under data category even though more and = more data traffic are carrying video content. It is impossible for applications to get differentiated services from publi= c internet, such as hotspot WIFI. It is also not possible for applications = to change network behavior. For example it is not easy for AntiDoS applicat= ions to enforce certain traffic to a special scrubbing center when some thr= eat is detected. Today, more and more applications need differentiated services from network= . Some applications may need special services for a specific time span, whi= le other applications may need to indicate their unique characteristics to = the network for special treatment, especially when they send encrypted traf= fic. The working group will examine what network characteristics that applicatio= ns need to communicate with network, define general framework and architect= ure for enabling those communications, examine existing protocols for those= communications, and potentially identify new protocols. Specifically, the Working Group will: 1. Identify the applications (or use cases) that need differentiated servi= ces, and time based services. 2. identify typical workflows for which heuristic based approaches are used 2. identify limitations of existing solutions 3. create a set of requirements for a solution based on explicit communication between applications and the network that can be applied in a consistent fashion across a variety of signaling protocols 4. identify a set of use cases addressable by such a solution 5. identify the information that needs to be communicated between application and the network 6. create a framework for providing this communication between applications and the network and that addresses the use cases 7. specify how existing signaling protocols can be enhanced to support this framework The Working Group is expected to work closely with other Transport area groups. The following topics are out of scope of this Working Group: TBD Deliverables: TBD Milestones: TBD --_000_4A95BA014132FF49AE685FAB4B9F17F645D2DFDCdfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Peng,

 

For metadata to be vis= ible to the network, the metadata have to be carried in a header such as SFC header.

Is AEON also defining = this Metadata header? Should the Metadata Header defined by AEON consistent= with the Metadata defined by SFC?

 

I am just concerned if= AEON only focus on the metadata between applications and service functions= , then AEON would become a subset of SFC WG deliverables.

 

Linda

 

 

From: Fan, Pen= g [mailto:fanpeng@chinamobile.com]
Sent: Wednesday, June 04, 2014 8:16 AM
To: Linda Dunbar; 'Tirumaleswar Reddy (tireddy)'; aeon@ietf.org
Subject: RE: [Aeon] Charter Proposal

 

Hi Linda,

 

I am trying to underst= and why the metadata is not visible to network. Flow characteristics, or me= tadata, are conveyed to network nodes which can be a gateway, a router, or = other elements that need visibility into the traffic. These nodes are not necessarily a DPI element, and are n= ot necessarily located at the edge or center of a network. Speaking of SFC = metadata I would like to know how is it related with flow characteristics w= e are now working on.

 

We have not gone that = far in discussing how the characteristics are encoded and carried, though a= t the very early age of this work there were some drafts on this. Also I re= member this minutes of the barbof at London IETF which I think is helpful in showing some of the concepts of th= is work http://www.ietf.org/mail-archive/web/aeon/current/msg00025.html.<= /o:p>

 

Best regards,

Peng=

 

From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Tuesday, June 03, 2014 11:57 PM
To: Fan, Peng; 'Tirumaleswar Reddy (tireddy)'; aeon@ietf.org
Subject: Re: [Aeon] Charter Proposal

 

Peng,

 

The current charter st= atement is all about applications exchanging information with network funct= ions, such as DPI, FW, etc.

 

This is the Metadata, =  which have been addressed by SFC WG. Why creating a new WG simply for= Metadata? Besides, all traffic will be aggregated by the provider edge dev= ices. The DPI/FW in the middle of the provider networks can’t even seen those metadata attached to Applications, un= less using a new header such as SFC header to carry those metadata.

 

Linda

 

 

From: Fan, Pen= g [mailto:fanpeng@chinamobile.co= m]
Sent: Monday, June 02, 2014 10:50 PM
To: 'Tirumaleswar Reddy (tireddy)'; Linda Dunbar; aeon@ietf.org
Subject: RE: [Aeon] Charter Proposal

 

Yes Tiru I have sent t= he proposal request to both INT and TSV ADs last week. Thank you Linda for = your contribution, I will try to incorporate the ideas into the draft chart= er.

 

Hi all,

 

The current BoF propos= al can be found at http://wiki.tools= .ietf.org/bof/trac/#Internet. It includes a revised draft charter based= on the initial version before the last IETF meeting, and I would appreciat= e it if you all can share opinions about the current proposal and help revise the draft charter.

 

Best regards,

Peng=

 

From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy (tireddy)
Sent: Monday, June 02, 2014 12:20 PM
To: Linda Dunbar; aeon@ietf.org=
Subject: Re: [Aeon] Charter Proposal

 

I think Peng= has already sent the revised charter proposal to AD based on the updated p= roblem statement draft http://tools.ietf.org/html/draft-conet-aeon-problem-statement-00=

 

-Tiru

 

From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Monday, June 02, 2014 3:33 AM
To: aeon@ietf.org
Subject: Re: [Aeon] Charter Proposal

 

We really need to send the BOF request by Thurs (Jun= e 5) because June 6th is the BoF request deadline.

The previously proposed charter only focuses on why operat= ors wanting to know applications. Without applications wanting to send thei= r characteristics to network, the network has to depend on DPI (or nothing when the traffic is encrypted).

I think that we should change the angle to describe why to= day’s applications need to send their traffic characteristics to netw= ork for differentiated services. With this in mind, I rewrote the charter proposal:

Do people on the list agree if we can send this charter &n= bsp;proposal to the Transport ADs (Spencer & Martin) to request a BoF i= n Toronto.

Linda

Description of Working Group:

 

Today’s traffic characteristics, such as bandwidth, = delay, loss, jitter, etc, are statically configured and managed by service = providers on per client or port basis. Even with edge devices or CPE (customer premises equipment) being able to configure diffe= rent QoS for differentiated network services, the classification is usually= coarse and fixed. For example, CPE can assign different QoS to differentia= te video, voice and data traffic, but CPE can’t differentiate the applications under data category eve= n though more and more data traffic are carrying video content. 

It is impossible for applications to get differentiated se= rvices from public internet, such as hotspot WIFI. It is also not possible = for applications to change network behavior. For example it is not easy for AntiDoS applications to enforce certain traffic= to a special scrubbing center when some threat is detected.

 

Today, more and more applications need differentiated serv= ices from network. Some applications may need special services for a specif= ic time span, while other applications may need to indicate their unique characteristics to the network for special treatm= ent, especially when they send encrypted traffic.

 

The working group will= examine what network characteristics that applications need to communicate= with network, define general framework and architecture for enabling those communications, examine existing protocols for those co= mmunications, and potentially identify new protocols.

Specifically, the Working Group will:

1.  Identify the applications (or use cases) that need= differentiated services, and time based services.

&= nbsp;

2. identify typical workflows for which heuristic based ap= proaches are used

2. identify limitations of existing solutions

3. create a set of requirements for a solution based on ex= plicit

communication between applications and the network that ca= n be applied in

a consistent fashion across a variety of signaling protoco= ls

4. identify a set of use cases addressable by such a solut= ion

5. identify the information that needs to be communicated = between

application and the network

6. create a framework for providing this communication bet= ween

applications and the network and that addresses the use ca= ses

7. specify how existing signaling protocols can be enhance= d to support

this framework

 

The Working Group is expected to work closely with other T= ransport area

groups.

 

The following topics are out of scope of this Working Grou= p:

TBD

 

Deliverables:

TBD

 

Milestones:

TBD

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645D2DFDCdfweml701chmchi_-- From nobody Wed Jun 4 16:31: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 78CA81A03D0 for ; Wed, 4 Jun 2014 16:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=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 dYWHXFB1-4Mq for ; Wed, 4 Jun 2014 16:31:18 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C421A03A1 for ; Wed, 4 Jun 2014 16:31:18 -0700 (PDT) Received: from dyn-225.arid.us (cpe-024-211-197-136.nc.res.rr.com [24.211.197.136]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s54NSuGD017935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jun 2014 19:28:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1401924540; bh=gLfdO9Ysm418fxYDCffRFRBFHNpdEf14YEdowIBGb1M=; h=In-Reply-To:References:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=MQIVytfGAeBvz77RG2Yx/ql6ZS8MYf+Soya9SKi0jky1S9PKY0PaS9tbf2S7x3vg8 h/qm48iGEMpVxosssVXjsM62pW54pTMeUxxylcy6EP+VpSBV6eoQ4cZ2cFRISCfmGz 5+ySTYWGeDBUeVbobIxAADjsBW8+pRGTcnIgIvSs= User-Agent: K-9 Mail for Android In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D2DFDC@dfweml701-chm.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645D2A013@dfweml701-chm.china.huawei.com> <913383AAA69FF945B8F946018B75898A282C5254@xmb-rcd-x10.cisco.com> <012d01cf7ede$dba2c1f0$92e845d0$@chinamobile.com> <4A95BA014132FF49AE685FAB4B9F17F645D2BDA6@dfweml701-chm.china.huawei.com> <005d01cf7ff7$2cdcc7f0$869657d0$@chinamobile.com> <4A95BA014132FF49AE685FAB4B9F17F645D2DFDC@dfweml701-chm.china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----WJSCISG089LZFE9TQ66939XR9KTFBW" Content-Transfer-Encoding: 8bit From: "Paul E. Jones" Date: Wed, 04 Jun 2014 19:28:55 -0400 To: Linda Dunbar , "Fan, Peng" , "'Tirumaleswar Reddy (tireddy)'" , "aeon@ietf.org" Message-ID: Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/DJLT2X7evZ26eSKK7W-sE7SDw3E Subject: Re: [Aeon] Charter 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, 04 Jun 2014 23:31:23 -0000 ------WJSCISG089LZFE9TQ66939XR9KTFBW Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Linda, What does the metadata header look from SFC? What kind of header is this? Is this specific to a certain protocol, a special metadata protocol, or is this a transport independent data blob that is carried inside other protocols? Paul -------- Original Message -------- From: Linda Dunbar Sent: June 4, 2014 1:31:38 PM EDT To: "Fan, Peng" , "'Tirumaleswar Reddy (tireddy)'" , "aeon@ietf.org" Subject: Re: [Aeon] Charter Proposal Peng, For metadata to be visible to the network, the metadata have to be carried in a header such as SFC header. Is AEON also defining this Metadata header? Should the Metadata Header defined by AEON consistent with the Metadata defined by SFC? I am just concerned if AEON only focus on the metadata between applications and service functions, then AEON would become a subset of SFC WG deliverables. Linda From: Fan, Peng [mailto:fanpeng@chinamobile.com] Sent: Wednesday, June 04, 2014 8:16 AM To: Linda Dunbar; 'Tirumaleswar Reddy (tireddy)'; aeon@ietf.org Subject: RE: [Aeon] Charter Proposal Hi Linda, I am trying to understand why the metadata is not visible to network. Flow characteristics, or metadata, are conveyed to network nodes which can be a gateway, a router, or other elements that need visibility into the traffic. These nodes are not necessarily a DPI element, and are not necessarily located at the edge or center of a network. Speaking of SFC metadata I would like to know how is it related with flow characteristics we are now working on. We have not gone that far in discussing how the characteristics are encoded and carried, though at the very early age of this work there were some drafts on this. Also I remember this minutes of the barbof at London IETF which I think is helpful in showing some of the concepts of this work http://www.ietf.org/mail-archive/web/aeon/current/msg00025.html. Best regards, Peng From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Tuesday, June 03, 2014 11:57 PM To: Fan, Peng; 'Tirumaleswar Reddy (tireddy)'; aeon@ietf.org Subject: Re: [Aeon] Charter Proposal Peng, The current charter statement is all about applications exchanging information with network functions, such as DPI, FW, etc. This is the Metadata, which have been addressed by SFC WG. Why creating a new WG simply for Metadata? Besides, all traffic will be aggregated by the provider edge devices. The DPI/FW in the middle of the provider networks can't even seen those metadata attached to Applications, unless using a new header such as SFC header to carry those metadata. Linda From: Fan, Peng [mailto:fanpeng@chinamobile.com] Sent: Monday, June 02, 2014 10:50 PM To: 'Tirumaleswar Reddy (tireddy)'; Linda Dunbar; aeon@ietf.org Subject: RE: [Aeon] Charter Proposal Yes Tiru I have sent the proposal request to both INT and TSV ADs last week. Thank you Linda for your contribution, I will try to incorporate the ideas into the draft charter. Hi all, The current BoF proposal can be found at http://wiki.tools.ietf.org/bof/trac/#Internet. It includes a revised draft charter based on the initial version before the last IETF meeting, and I would appreciate it if you all can share opinions about the current proposal and help revise the draft charter. Best regards, Peng From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy (tireddy) Sent: Monday, June 02, 2014 12:20 PM To: Linda Dunbar; aeon@ietf.org Subject: Re: [Aeon] Charter Proposal I think Peng has already sent the revised charter proposal to AD based on the updated problem statement draft http://tools.ietf.org/html/draft-conet-aeon-problem-statement-00 -Tiru From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Monday, June 02, 2014 3:33 AM To: aeon@ietf.org Subject: Re: [Aeon] Charter Proposal We really need to send the BOF request by Thurs (June 5) because June 6th is the BoF request deadline. The previously proposed charter only focuses on why operators wanting to know applications. Without applications wanting to send their characteristics to network, the network has to depend on DPI (or nothing when the traffic is encrypted). I think that we should change the angle to describe why today's applications need to send their traffic characteristics to network for differentiated services. With this in mind, I rewrote the charter proposal: Do people on the list agree if we can send this charter proposal to the Transport ADs (Spencer & Martin) to request a BoF in Toronto. Linda Description of Working Group: Today's traffic characteristics, such as bandwidth, delay, loss, jitter, etc, are statically configured and managed by service providers on per client or port basis. Even with edge devices or CPE (customer premises equipment) being able to configure different QoS for differentiated network services, the classification is usually coarse and fixed. For example, CPE can assign different QoS to differentiate video, voice and data traffic, but CPE can't differentiate the applications under data category even though more and more data traffic are carrying video content. It is impossible for applications to get differentiated services from public internet, such as hotspot WIFI. It is also not possible for applications to change network behavior. For example it is not easy for AntiDoS applications to enforce certain traffic to a special scrubbing center when some threat is detected. Today, more and more applications need differentiated services from network. Some applications may need special services for a specific time span, while other applications may need to indicate their unique characteristics to the network for special treatment, especially when they send encrypted traffic. The working group will examine what network characteristics that applications need to communicate with network, define general framework and architecture for enabling those communications, examine existing protocols for those communications, and potentially identify new protocols. Specifically, the Working Group will: 1. Identify the applications (or use cases) that need differentiated services, and time based services. 2. identify typical workflows for which heuristic based approaches are used 2. identify limitations of existing solutions 3. create a set of requirements for a solution based on explicit communication between applications and the network that can be applied in a consistent fashion across a variety of signaling protocols 4. identify a set of use cases addressable by such a solution 5. identify the information that needs to be communicated between application and the network 6. create a framework for providing this communication between applications and the network and that addresses the use cases 7. specify how existing signaling protocols can be enhanced to support this framework The Working Group is expected to work closely with other Transport area groups. The following topics are out of scope of this Working Group: TBD Deliverables: TBD Milestones: TBD ------------------------------------------------------------------------ _______________________________________________ Aeon mailing list Aeon@ietf.org https://www.ietf.org/mailman/listinfo/aeon ------WJSCISG089LZFE9TQ66939XR9KTFBW Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Linda,

What does the metadata header look from SFC? What kind of header is this? Is this specific to a certain protocol, a special metadata protocol, or is this a transport independent data blob that is carried inside other protocols?

Paul

From: Linda Dunbar <linda.dunbar@huawei.com>
Sent: June 4, 2014 1:31:38 PM EDT
To: "Fan, Peng" <fanpeng@chinamobile.com>, "'Tirumaleswar Reddy (tireddy)'" <tireddy@cisco.com>, "aeon@ietf.org" <aeon@ietf.org>
Subject: Re: [Aeon] Charter Proposal

Peng,

 

For metadata to be visible to the network, the metadata have to be carried in a header such as SFC header.

Is AEON also defining this Metadata header? Should the Metadata Header defined by AEON consistent with the Metadata defined by SFC?

 

I am just concerned if AEON only focus on the metadata between applications and service functions, then AEON would become a subset of SFC WG deliverables.

 

Linda

 

 

From: Fan, Peng [mailto:fanpeng@chinamobile.com]
Sent: Wednesday, June 04, 2014 8:16 AM
To: Linda Dunbar; 'Tirumaleswar Reddy (tireddy)'; aeon@ietf.org
Subject: RE: [Aeon] Charter Proposal

 

Hi Linda,

 

I am trying to understand why the metadata is not visible to network. Flow characteristics, or metadata, are conveyed to network nodes which can be a gateway, a router, or other elements that need visibility into the traffic. These nodes are not necessarily a DPI element, and are not necessarily located at the edge or center of a network. Speaking of SFC metadata I would like to know how is it related with flow characteristics we are now working on.

 

We have not gone that far in discussing how the characteristics are encoded and carried, though at the very early age of this work there were some drafts on this. Also I remember this minutes of the barbof at London IETF which I think is helpful in showing some of the concepts of this work http://www.ietf.org/mail-archive/web/aeon/current/msg00025.html.

 

Best regards,

Peng

 

From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Tuesday, June 03, 2014 11:57 PM
To: Fan, Peng; 'Tirumaleswar Reddy (tireddy)'; aeon@ietf.org
Subject: Re: [Aeon] Charter Proposal

 

Peng,

 

The current charter statement is all about applications exchanging information with network functions, such as DPI, FW, etc.

 

This is the Metadata,  which have been addressed by SFC WG. Why creating a new WG simply for Metadata? Besides, all traffic will be aggregated by the provider edge devices. The DPI/FW in the middle of the provider networks can’t even seen those metadata attached to Applications, unless using a new header such as SFC header to carry those metadata.

 

Linda

 

 

From: Fan, Peng [mailto:fanpeng@chinamobile.com]
Sent: Monday, June 02, 2014 10:50 PM
To: 'Tirumaleswar Reddy (tireddy)'; Linda Dunbar; aeon@ietf.org
Subject: RE: [Aeon] Charter Proposal

 

Yes Tiru I have sent the proposal request to both INT and TSV ADs last week. Thank you Linda for your contribution, I will try to incorporate the ideas into the draft charter.

 

Hi all,

 

The current BoF proposal can be found at http://wiki.tools.ietf.org/bof/trac/#Internet. It includes a revised draft charter based on the initial version before the last IETF meeting, and I would appreciate it if you all can share opinions about the current proposal and help revise the draft charter.

 

Best regards,

Peng

 

From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy (tireddy)
Sent: Monday, June 02, 2014 12:20 PM
To: Linda Dunbar; aeon@ietf.org
Subject: Re: [Aeon] Charter Proposal

 

I think Peng has already sent the revised charter proposal to AD based on the updated problem statement draft http://tools.ietf.org/html/draft-conet-aeon-problem-statement-00

 

-Tiru

 

From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Monday, June 02, 2014 3:33 AM
To: aeon@ietf.org
Subject: Re: [Aeon] Charter Proposal

 

We really need to send the BOF request by Thurs (June 5) because June 6th is the BoF request deadline.

The previously proposed charter only focuses on why operators wanting to know applications. Without applications wanting to send their characteristics to network, the network has to depend on DPI (or nothing when the traffic is encrypted).

I think that we should change the angle to describe why today’s applications need to send their traffic characteristics to network for differentiated services. With this in mind, I rewrote the charter proposal:

Do people on the list agree if we can send this charter  proposal to the Transport ADs (Spencer & Martin) to request a BoF in Toronto.

Linda

Description of Working Group:

 

Today’s traffic characteristics, such as bandwidth, delay, loss, jitter, etc, are statically configured and managed by service providers on per client or port basis. Even with edge devices or CPE (customer premises equipment) being able to configure different QoS for differentiated network services, the classification is usually coarse and fixed. For example, CPE can assign different QoS to differentiate video, voice and data traffic, but CPE can’t differentiate the applications under data category even though more and more data traffic are carrying video content. 

It is impossible for applications to get differentiated services from public internet, such as hotspot WIFI. It is also not possible for applications to change network behavior. For example it is not easy for AntiDoS applications to enforce certain traffic to a special scrubbing center when some threat is detected.

 

Today, more and more applications need differentiated services from network. Some applications may need special services for a specific time span, while other applications may need to indicate their unique characteristics to the network for special treatment, especially when they send encrypted traffic.

 

The working group will examine what network characteristics that applications need to communicate with network, define general framework and architecture for enabling those communications, examine existing protocols for those communications, and potentially identify new protocols.

Specifically, the Working Group will:

1.  Identify the applications (or use cases) that need differentiated services, and time based services.

 

2. identify typical workflows for which heuristic based approaches are used

2. identify limitations of existing solutions

3. create a set of requirements for a solution based on explicit

communication between applications and the network that can be applied in

a consistent fashion across a variety of signaling protocols

4. identify a set of use cases addressable by such a solution

5. identify the information that needs to be communicated between

application and the network

6. create a framework for providing this communication between

applications and the network and that addresses the use cases

7. specify how existing signaling protocols can be enhanced to support

this framework

 

The Working Group is expected to work closely with other Transport area

groups.

 

The following topics are out of scope of this Working Group:

TBD

 

Deliverables:

TBD

 

Milestones:

TBD

 


Aeon mailing list
Aeon@ietf.org
https://www.ietf.org/mailman/listinfo/aeon
------WJSCISG089LZFE9TQ66939XR9KTFBW-- From nobody Thu Jun 5 01:30:56 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 604D91A02C1 for ; Thu, 5 Jun 2014 01:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 OIgKhBnXfv32 for ; Thu, 5 Jun 2014 01:30:52 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB2C21A00F8 for ; Thu, 5 Jun 2014 01:30:52 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LZzGf-1WVk9y11yf-00mBHW; Thu, 05 Jun 2014 04:30:37 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_037A06D7-BA3B-43DC-A043-CDA4990567B1" From: Alper Yegin In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D2DFDC@dfweml701-chm.china.huawei.com> Date: Thu, 5 Jun 2014 11:30:29 +0300 Message-Id: <0E465B5F-73D3-4813-9CFA-21D3A730D8F0@yegin.org> References: <4A95BA014132FF49AE685FAB4B9F17F645D2A013@dfweml701-chm.china.huawei.com> <913383AAA69FF945B8F946018B75898A282C5254@xmb-rcd-x10.cisco.com> <012d01cf7ede$dba2c1f0$92e845d0$@chinamobile.com> <4A95BA014132FF49AE685FAB4B9F17F645D2BDA6@dfweml701-chm.china.huawei.com> <005d01cf7ff7$2cdcc7f0$869657d0$@chinamobile.com> <4A95BA014132FF49AE685FAB4B9F17F645D2DFDC@dfweml701-chm.china.huawei.com> To: Linda Dunbar X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:bJJ3vqyuOlFiziJhB8ScZAXtfOarslWb2HiMPqvqqWR qtQlFJslf+D2o2enqq+vsOFTHJClWdvjEZ9VYtipiFokQn5XTF 5v+7/OM6yA1UvXJvPDq12fgl8j6VEUWRNgMY297FJFdWHbcpWW GWZZle0jkdLksaa1wjVw5wIO79vP1O84iHCfk22/gY8Hi3Rt4X C/Yjnkgvw+s2mlhGFBX19pDjRcSerH3eXkLjfaM3vMoFCAKfZq FhvPT9tpOru5R/y3Lq+r4HoNy2oLk4+8Gd75zEttaSaQSulJQu mv7aXyXko8p8kSrbir1MJQQu8/6ynuQOz9BSfDSi96Sq9Jclr/ 9RQU3ToOMakMOwkcGP10qTZlcxtmqb1SFLhNzRoTO3uq11PnFf KqbVHYBYa/jqg== Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/AFVDnTCr9SpMZ2_6RE0jKppB4yc Cc: "aeon@ietf.org" , "'Tirumaleswar Reddy \(tireddy\)'" , "Fan, Peng" Subject: Re: [Aeon] Charter 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, 05 Jun 2014 08:30:55 -0000 --Apple-Mail=_037A06D7-BA3B-43DC-A043-CDA4990567B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Linda, The metadata "may" also be communicated at the beginning of the IP flow. = In other words, it does not have to be communicated on each IP packet. So, AEON may not be just about extending SFC all the way to the = terminal. Alper On Jun 4, 2014, at 8:31 PM, Linda Dunbar wrote: > Peng, > =20 > For metadata to be visible to the network, the metadata have to be = carried in a header such as SFC header. > Is AEON also defining this Metadata header? Should the Metadata Header = defined by AEON consistent with the Metadata defined by SFC? > =20 > I am just concerned if AEON only focus on the metadata between = applications and service functions, then AEON would become a subset of = SFC WG deliverables. > =20 > Linda > =20 > =20 > From: Fan, Peng [mailto:fanpeng@chinamobile.com]=20 > Sent: Wednesday, June 04, 2014 8:16 AM > To: Linda Dunbar; 'Tirumaleswar Reddy (tireddy)'; aeon@ietf.org > Subject: RE: [Aeon] Charter Proposal > =20 > Hi Linda, > =20 > I am trying to understand why the metadata is not visible to network. = Flow characteristics, or metadata, are conveyed to network nodes which = can be a gateway, a router, or other elements that need visibility into = the traffic. These nodes are not necessarily a DPI element, and are not = necessarily located at the edge or center of a network. Speaking of SFC = metadata I would like to know how is it related with flow = characteristics we are now working on. > =20 > We have not gone that far in discussing how the characteristics are = encoded and carried, though at the very early age of this work there = were some drafts on this. Also I remember this minutes of the barbof at = London IETF which I think is helpful in showing some of the concepts of = this work = http://www.ietf.org/mail-archive/web/aeon/current/msg00025.html. > =20 > Best regards, > Peng > =20 > From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Linda Dunbar > Sent: Tuesday, June 03, 2014 11:57 PM > To: Fan, Peng; 'Tirumaleswar Reddy (tireddy)'; aeon@ietf.org > Subject: Re: [Aeon] Charter Proposal > =20 > Peng, > =20 > The current charter statement is all about applications exchanging = information with network functions, such as DPI, FW, etc. > =20 > This is the Metadata, which have been addressed by SFC WG. Why = creating a new WG simply for Metadata? Besides, all traffic will be = aggregated by the provider edge devices. The DPI/FW in the middle of the = provider networks can=92t even seen those metadata attached to = Applications, unless using a new header such as SFC header to carry = those metadata. > =20 > Linda > =20 > =20 > From: Fan, Peng [mailto:fanpeng@chinamobile.com]=20 > Sent: Monday, June 02, 2014 10:50 PM > To: 'Tirumaleswar Reddy (tireddy)'; Linda Dunbar; aeon@ietf.org > Subject: RE: [Aeon] Charter Proposal > =20 > Yes Tiru I have sent the proposal request to both INT and TSV ADs last = week. Thank you Linda for your contribution, I will try to incorporate = the ideas into the draft charter. > =20 > Hi all, > =20 > The current BoF proposal can be found at = http://wiki.tools.ietf.org/bof/trac/#Internet. It includes a revised = draft charter based on the initial version before the last IETF meeting, = and I would appreciate it if you all can share opinions about the = current proposal and help revise the draft charter. > =20 > Best regards, > Peng > =20 > From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Tirumaleswar = Reddy (tireddy) > Sent: Monday, June 02, 2014 12:20 PM > To: Linda Dunbar; aeon@ietf.org > Subject: Re: [Aeon] Charter Proposal > =20 > I think Peng has already sent the revised charter proposal to AD based = on the updated problem statement = drafthttp://tools.ietf.org/html/draft-conet-aeon-problem-statement-00 > =20 > -Tiru > =20 > From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Linda Dunbar > Sent: Monday, June 02, 2014 3:33 AM > To: aeon@ietf.org > Subject: Re: [Aeon] Charter Proposal > =20 > We really need to send the BOF request by Thurs (June 5) because June = 6th is the BoF request deadline. > The previously proposed charter only focuses on why operators wanting = to know applications. Without applications wanting to send their = characteristics to network, the network has to depend on DPI (or nothing = when the traffic is encrypted). >=20 > I think that we should change the angle to describe why today=92s = applications need to send their traffic characteristics to network for = differentiated services. With this in mind, I rewrote the charter = proposal: >=20 > Do people on the list agree if we can send this charter proposal to = the Transport ADs (Spencer & Martin) to request a BoF in Toronto. >=20 > Linda >=20 > Description of Working Group: > =20 > Today=92s traffic characteristics, such as bandwidth, delay, loss, = jitter, etc, are statically configured and managed by service providers = on per client or port basis. Even with edge devices or CPE (customer = premises equipment) being able to configure different QoS for = differentiated network services, the classification is usually coarse = and fixed. For example, CPE can assign different QoS to differentiate = video, voice and data traffic, but CPE can=92t differentiate the = applications under data category even though more and more data traffic = are carrying video content.=20 > It is impossible for applications to get differentiated services from = public internet, such as hotspot WIFI. It is also not possible for = applications to change network behavior. For example it is not easy for = AntiDoS applications to enforce certain traffic to a special scrubbing = center when some threat is detected. > =20 > Today, more and more applications need differentiated services from = network. Some applications may need special services for a specific time = span, while other applications may need to indicate their unique = characteristics to the network for special treatment, especially when = they send encrypted traffic. > =20 > The working group will examine what network characteristics that = applications need to communicate with network, define general framework = and architecture for enabling those communications, examine existing = protocols for those communications, and potentially identify new = protocols. >=20 > Specifically, the Working Group will: > 1. Identify the applications (or use cases) that need differentiated = services, and time based services. > =20 > 2. identify typical workflows for which heuristic based approaches are = used > 2. identify limitations of existing solutions > 3. create a set of requirements for a solution based on explicit > communication between applications and the network that can be applied = in > a consistent fashion across a variety of signaling protocols > 4. identify a set of use cases addressable by such a solution > 5. identify the information that needs to be communicated between > application and the network > 6. create a framework for providing this communication between > applications and the network and that addresses the use cases > 7. specify how existing signaling protocols can be enhanced to support > this framework > =20 > The Working Group is expected to work closely with other Transport = area > groups. > =20 > The following topics are out of scope of this Working Group: > TBD > =20 > Deliverables: > TBD > =20 > Milestones: > TBD > =20 > _______________________________________________ > Aeon mailing list > Aeon@ietf.org > https://www.ietf.org/mailman/listinfo/aeon --Apple-Mail=_037A06D7-BA3B-43DC-A043-CDA4990567B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Linda,

The metadata "may" = also be communicated at the beginning of the IP flow. In other words, it = does not have to be communicated on each IP packet.
So, AEON = may not be just about extending SFC all the way to the = terminal.

Alper


On Jun 4, 2014, at 8:31 PM, Linda Dunbar wrote:

Peng,
 
For metadata to be visible to the network, the metadata have = to be carried in a header such as SFC = header.
Is AEON also defining this Metadata header? Should the = Metadata Header defined by AEON consistent with the Metadata defined by = SFC?
 
I am just concerned if AEON only focus on the metadata = between applications and service functions, then AEON would become a = subset of SFC WG deliverables.
Linda
 
 
From: Fan, Peng = [mailto:fanpeng@chinamobile.com] 
Sent: Wednesday, June 04, 2014 = 8:16 AM
To: Linda Dunbar; 'Tirumaleswar = Reddy (tireddy)'; aeon@ietf.org
Subject: RE: [Aeon] Charter = Proposal
Hi Linda,
 
I am trying to understand why the metadata is not visible to = network. Flow characteristics, or metadata, are conveyed to network = nodes which can be a gateway, a router, or other elements that need = visibility into the traffic. These nodes are not necessarily a DPI = element, and are not necessarily located at the edge or center of a = network. Speaking of SFC metadata I would like to know how is it related = with flow characteristics we are now working = on.
 
We have not gone that far in discussing how the = characteristics are encoded and carried, though at the very early age of = this work there were some drafts on this. Also I remember this minutes = of the barbof at London IETF which I think is helpful in showing some of = the concepts of this work Best regards,
From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Linda = Dunbar
Sent: Tuesday, June 03, 2014 = 11:57 PM
To: Fan, Peng; 'Tirumaleswar = Reddy (tireddy)'; aeon@ietf.org
Subject: Re: [Aeon] Charter = Proposal
Peng,
 
The current charter statement is all about applications = exchanging information with network functions, such as DPI, FW, = etc.
 
This is the Metadata,  which have been addressed by SFC = WG. Why creating a new WG simply for Metadata? Besides, all traffic will = be aggregated by the provider edge devices. The DPI/FW in the middle of = the provider networks can=92t even seen those metadata attached to = Applications, unless using a new header such as SFC header to carry = those metadata.
 
Linda
 
 
From: Fan, Peng [mailto:fanpeng@chinamobile.com] 
Sent: Monday, June 02, 2014 10:50 = PM
To: 'Tirumaleswar Reddy = (tireddy)'; Linda Dunbar; aeon@ietf.org
Subject: RE: [Aeon] Charter = Proposal
Yes Tiru I have sent the proposal request to both INT and TSV = ADs last week. Thank you Linda for your contribution, I will try to = incorporate the ideas into the draft = charter.
 
Hi all,
 
The current BoF = proposal can be found at  
From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy = (tireddy)
Sent: Monday, June 02, 2014 12:20 = PM
To: Linda = Dunbar; aeon@ietf.org
Subject: Re: [Aeon] Charter = Proposal
I think Peng has already = sent the revised charter proposal to AD based on the updated problem = statement draft 
From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Linda = Dunbar
Sent: Monday, June 02, 2014 3:33 = AM
To: aeon@ietf.org
Subject: Re: [Aeon] Charter = Proposal
We really need to send the BOF = request by Thurs (June 5) because June 6th is the BoF request = deadline.

The previously proposed charter only focuses = on why operators wanting to know applications. Without applications = wanting to send their characteristics to network, the network has to = depend on DPI (or nothing when the traffic is = encrypted).

I think that we should change the = angle to describe why today=92s applications need to send their traffic = characteristics to network for differentiated services. With this in = mind, I rewrote the charter proposal:

Do people on = the list agree if we can send this charter  proposal to the = Transport ADs (Spencer & Martin) to request a BoF in = Toronto.

Description of Working = Group:

 
Today=92s traffic characteristics, such as bandwidth, delay, = loss, jitter, etc, are statically configured and managed by service = providers on per client or port basis. Even with edge devices or CPE = (customer premises equipment) being able to configure different QoS for = differentiated network services, the classification is usually coarse = and fixed. For example, CPE can assign different QoS to differentiate = video, voice and data traffic, but CPE can=92t differentiate the = applications under data category even though more and more data traffic = are carrying video content. 
It is impossible for applications to get differentiated services = from public internet, such as hotspot WIFI. It is also not possible for = applications to change network behavior. For example it is not easy for = AntiDoS applications to enforce certain traffic to a special scrubbing = center when some threat is detected.
 
Today, more and more applications = need differentiated services from network. Some applications may need = special services for a specific time span, while other applications may = need to indicate their unique characteristics to the network for special = treatment, especially when they send encrypted = traffic.
 

The working group will examine what network = characteristics that applications need to communicate with network, = define general framework and architecture for enabling those = communications, examine existing protocols for those communications, and = potentially identify new protocols.

Specifically, the Working Group = will:
1.  Identify the = applications (or use cases) that need differentiated services, and time = based services.
2. identify typical workflows for = which heuristic based approaches are used
2. identify limitations of existing = solutions
3. create a set of requirements for = a solution based on explicit
communication between applications and the network that can be = applied in
a consistent fashion across a = variety of signaling protocols
4. identify a set of use cases addressable by such a = solution
5. identify the information that = needs to be communicated between
application and the network
6. create a framework for providing this communication = between
applications and the network and = that addresses the use cases
7. specify how existing signaling protocols can be enhanced to = support
this = framework
 
The Working Group is expected to work closely with other = Transport area
groups.
 
The following topics are out of = scope of this Working Group:
TBD
 
Deliverables:
 
Milestones:
Aeon@ietf.org
https://www.ietf.org/ma= ilman/listinfo/aeon

= --Apple-Mail=_037A06D7-BA3B-43DC-A043-CDA4990567B1-- From nobody Thu Jun 5 01:36:58 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 6C6541A02C1 for ; Thu, 5 Jun 2014 01:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.122 X-Spam-Level: ** X-Spam-Status: No, score=2.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.651] 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 6zhK-CF7mXIA for ; Thu, 5 Jun 2014 01:36:55 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 6607E1A00A9 for ; Thu, 5 Jun 2014 01:36:53 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.12]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee153902bf6213-91213; Thu, 05 Jun 2014 16:36:06 +0800 (CST) X-RM-TRANSID: 2ee153902bf6213-91213 Received: from adminPC (unknown[10.2.52.208]) by rmsmtp-oa_rmapp02-12002 (RichMail) with SMTP id 2ee253902bf5dbd-e1f99; Thu, 05 Jun 2014 16:36:06 +0800 (CST) X-RM-TRANSID: 2ee253902bf5dbd-e1f99 From: "Fan, Peng" To: Date: Thu, 5 Jun 2014 16:36:32 +0800 Message-ID: <00b601cf8099$41243fc0$c36cbf40$@chinamobile.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B7_01CF80DC.4F4C3AB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+AjCs1H3aIl7QQQKWZv7AZp57rZg== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/zpvPb293eLeOlOzzWAFfaPmNYAk Cc: aeon@ietf.org Subject: Re: [Aeon] FW: New Version Notification for draft-conet-aeon-use-cases-00.txt 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, 05 Jun 2014 08:36:57 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B7_01CF80DC.4F4C3AB0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Junyi, It is great we have people from application side on the list. please see = my reply inline [FP]. From: junyihan [mailto:junyihan@tencent.com]=20 Sent: Thursday, June 05, 2014 10:47 AM To: fanpeng Subject: FW: [Aeon] FW: New Version Notification for draft-conet-aeon-use-cases-00.txt =20 Hi Peng, =20 Maybe my reply didn't arrive at aeon list, so I think either my tencent = mail box or the list is having some problem, since I have already subscribed = to the list. =20 Junyi =20 =B7=A2=BC=FE=C8=CB=A3=BA junyihan =20 =B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2014-06-04 18:37 =CA=D5=BC=FE=C8=CB=A3=BA aeon =20 =D6=F7=CC=E2=A3=BA RE: [Aeon] FW: New Version Notification for draft-conet-aeon-use-cases-00.txt Hi Peng, =20 Thanks for introducing this work to me. It will be great if there is a standard way for applications to interact with network. Some comments = below: =20 1. is there any definition how the information is signaled? [FP] It is up to us to define. There is a brief description of = relationship between signaling and media: http://tools.ietf.org/html/draft-conet-aeon-problem-statement-00#section-= 2.1 =20 2. I think applications should be able to decide when and how to = interact with network, right? [FP] Yes that is also one of the reasons of doing this work - to enable information signaling yet protect applications from unwanted information leakage. =20 3. an authentication mechanism may be needed, we need to consider that = when designing a solution. [FP] Agree, in many scenarios authentication is an important function. =20 Best regards, Peng =20 Regards, Junyi ------=_NextPart_000_00B7_01CF80DC.4F4C3AB0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable FW: [Aeon] FW: New Version Notification for = draft-conet-aeon-use-cases-00.txt(Internet mail)

Hi Junyi,

It is great we have people from application side on the list. please = see my reply inline [FP].

From:= = junyihan [mailto:junyihan@tencent.com]
Sent: Thursday, June = 05, 2014 10:47 AM
To: fanpeng
Subject: FW: [Aeon] = FW: New Version Notification for = draft-conet-aeon-use-cases-00.txt

 

Hi Peng,

 

Maybe my reply didn't arrive at aeon list, so I think = either my tencent mail box or the list is having some problem, since I = have already subscribed to the list.

 

Junyi

  

=B7=A2=BC=FE=C8=CB=A3=BA&= nbsp;junyihan

=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA&= nbsp;2014-06-04 18:37

=CA=D5=BC=FE=C8=CB=A3=BA&= nbsp;aeon

=D6=F7=CC=E2=A3=BA&= nbsp;RE: [Aeon] FW: New Version Notification for = draft-conet-aeon-use-cases-00.txt

=

Hi Peng,

 

Thanks for introducing this work to me. It will be = great if there is a standard way for applications to interact with = network. Some comments below:

 

1. is there any definition how the information is = signaled?

[FP] It is up to us to define. There is a brief description of = relationship between signaling and media: http://tools.ietf.org/html/draft-conet-aeon-problem-statemen= t-00#section-2.1

 

2. I think applications should be able to decide when = and how to interact with network, = right?

[FP] Yes that is also one of the reasons of doing this work - to = enable information signaling yet protect applications from unwanted = information leakage.

 

3. an authentication mechanism may be needed, we need = to consider that when designing a = solution.

[FP] Agree, in many scenarios authentication is an important = function.

 

Best regards,

Peng

 

Regards,

Junyi

------=_NextPart_000_00B7_01CF80DC.4F4C3AB0-- From sunjiannan@feinno.com Thu Jun 5 03:04:23 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 4C0121A014D for ; Thu, 5 Jun 2014 03:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.649 X-Spam-Level: *** X-Spam-Status: No, score=3.649 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] 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 WrrtJQzpcEq5 for ; Thu, 5 Jun 2014 03:04:21 -0700 (PDT) Received: from mailhub.feinno.com (mail.feinno.com [60.194.14.168]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03DAF1A0151 for ; Thu, 5 Jun 2014 03:04:20 -0700 (PDT) Received: from sunjiannan (10.10.130.84) by mailhub.feinno.com (192.168.130.221) with Microsoft SMTP Server id 8.2.255.0; Thu, 5 Jun 2014 18:04:08 +0800 From: =?gb2312?B?y++9o+mq?= To: References: <00c101cf809e$063098f0$1291cad0$@chinamobile.com> In-Reply-To: <00c101cf809e$063098f0$1291cad0$@chinamobile.com> Date: Thu, 5 Jun 2014 18:04:08 +0800 Message-ID: <006701cf80a5$7dfa2b60$79ee8220$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+AnPdYnjhZvnrVRpWLy8dHTpbwSAACEXpA Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/CiyQXfRPgbCPrDyHF4gRnsvqAk0 Subject: Re: [Aeon] FW: New Version Notification for draft-conet-aeon-use-cases-00.txt 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, 05 Jun 2014 10:09:40 -0000 It is technically feasible. For application providers, if it is compatible with the old version should be taken into account when put into use. It is related to version distribution and operation & maintanaince other than technical matters. From nobody Thu Jun 5 08:50:36 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 54B251A025E for ; Thu, 5 Jun 2014 08:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 3jOQVDcKdnkk for ; Thu, 5 Jun 2014 08:50:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5056A1A023B for ; Thu, 5 Jun 2014 08:50:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHW52509; Thu, 05 Jun 2014 15:50:09 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Jun 2014 16:49:13 +0100 Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Jun 2014 16:50:08 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml702-chm.china.huawei.com ([169.254.4.56]) with mapi id 14.03.0158.001; Thu, 5 Jun 2014 08:49:59 -0700 From: Linda Dunbar To: Alper Yegin Thread-Topic: [Aeon] Charter Proposal Thread-Index: AQHPfhnw3Imxc3bm1U2GdVSmBEV9z5tfNtoAgABUNgCAAdxsgP//wl1ggAGAHICAAAUp8A== Date: Thu, 5 Jun 2014 15:49:58 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D2E909@dfweml701-chm.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645D2A013@dfweml701-chm.china.huawei.com> <913383AAA69FF945B8F946018B75898A282C5254@xmb-rcd-x10.cisco.com> <012d01cf7ede$dba2c1f0$92e845d0$@chinamobile.com> <4A95BA014132FF49AE685FAB4B9F17F645D2BDA6@dfweml701-chm.china.huawei.com> <005d01cf7ff7$2cdcc7f0$869657d0$@chinamobile.com> <4A95BA014132FF49AE685FAB4B9F17F645D2DFDC@dfweml701-chm.china.huawei.com> <0E465B5F-73D3-4813-9CFA-21D3A730D8F0@yegin.org> In-Reply-To: <0E465B5F-73D3-4813-9CFA-21D3A730D8F0@yegin.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.104] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D2E909dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/wc66e4V_kiN20jYnLkSmJXeizVc Cc: "aeon@ietf.org" , "'Tirumaleswar Reddy \(tireddy\)'" , "Fan, Peng" Subject: Re: [Aeon] Charter 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, 05 Jun 2014 15:50:30 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645D2E909dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alper, Do you mean exchange Metadata via control plane or out-of-band signal? Such= as today's Mobile network using Diameter to pass metadata to service funct= ions? Linda From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Thursday, June 05, 2014 3:30 AM To: Linda Dunbar Cc: Fan, Peng; 'Tirumaleswar Reddy (tireddy)'; aeon@ietf.org Subject: Re: [Aeon] Charter Proposal Hi Linda, The metadata "may" also be communicated at the beginning of the IP flow. In= other words, it does not have to be communicated on each IP packet. So, AEON may not be just about extending SFC all the way to the terminal. Alper On Jun 4, 2014, at 8:31 PM, Linda Dunbar wrote: Peng, For metadata to be visible to the network, the metadata have to be carried = in a header such as SFC header. Is AEON also defining this Metadata header? Should the Metadata Header defi= ned by AEON consistent with the Metadata defined by SFC? I am just concerned if AEON only focus on the metadata between applications= and service functions, then AEON would become a subset of SFC WG deliverab= les. Linda From: Fan, Peng [mailto:fanpeng@chinamobile.com] Sent: Wednesday, June 04, 2014 8:16 AM To: Linda Dunbar; 'Tirumaleswar Reddy (tireddy)'; aeon@ietf.org Subject: RE: [Aeon] Charter Proposal Hi Linda, I am trying to understand why the metadata is not visible to network. Flow = characteristics, or metadata, are conveyed to network nodes which can be a = gateway, a router, or other elements that need visibility into the traffic.= These nodes are not necessarily a DPI element, and are not necessarily loc= ated at the edge or center of a network. Speaking of SFC metadata I would l= ike to know how is it related with flow characteristics we are now working = on. We have not gone that far in discussing how the characteristics are encoded= and carried, though at the very early age of this work there were some dra= fts on this. Also I remember this minutes of the barbof at London IETF whic= h I think is helpful in showing some of the concepts of this work http://ww= w.ietf.org/mail-archive/web/aeon/current/msg00025.html. Best regards, Peng From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Tuesday, June 03, 2014 11:57 PM To: Fan, Peng; 'Tirumaleswar Reddy (tireddy)'; aeon@ietf.org Subject: Re: [Aeon] Charter Proposal Peng, The current charter statement is all about applications exchanging informat= ion with network functions, such as DPI, FW, etc. This is the Metadata, which have been addressed by SFC WG. Why creating a = new WG simply for Metadata? Besides, all traffic will be aggregated by the = provider edge devices. The DPI/FW in the middle of the provider networks ca= n't even seen those metadata attached to Applications, unless using a new h= eader such as SFC header to carry those metadata. Linda From: Fan, Peng [mailto:fanpeng@chinamobile.com] Sent: Monday, June 02, 2014 10:50 PM To: 'Tirumaleswar Reddy (tireddy)'; Linda Dunbar; aeon@ietf.org Subject: RE: [Aeon] Charter Proposal Yes Tiru I have sent the proposal request to both INT and TSV ADs last week= . Thank you Linda for your contribution, I will try to incorporate the idea= s into the draft charter. Hi all, The current BoF proposal can be found at http://wiki.tools.ietf.org/bof/tra= c/#Internet. It includes a revised draft charter based on the initial versi= on before the last IETF meeting, and I would appreciate it if you all can s= hare opinions about the current proposal and help revise the draft charter. Best regards, Peng From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy (= tireddy) Sent: Monday, June 02, 2014 12:20 PM To: Linda Dunbar; aeon@ietf.org Subject: Re: [Aeon] Charter Proposal I think Peng has already sent the revised charter proposal to AD based on t= he updated problem statement drafthttp://tools.ietf.org/html/draft-conet-ae= on-problem-statement-00 -Tiru From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Monday, June 02, 2014 3:33 AM To: aeon@ietf.org Subject: Re: [Aeon] Charter Proposal We really need to send the BOF request by Thurs (June 5) because June 6th i= s the BoF request deadline. The previously proposed charter only focuses on why operators wanting to kn= ow applications. Without applications wanting to send their characteristics= to network, the network has to depend on DPI (or nothing when the traffic = is encrypted). I think that we should change the angle to describe why today's application= s need to send their traffic characteristics to network for differentiated = services. With this in mind, I rewrote the charter proposal: Do people on the list agree if we can send this charter proposal to the Tr= ansport ADs (Spencer & Martin) to request a BoF in Toronto. Linda Description of Working Group: Today's traffic characteristics, such as bandwidth, delay, loss, jitter, et= c, are statically configured and managed by service providers on per client= or port basis. Even with edge devices or CPE (customer premises equipment)= being able to configure different QoS for differentiated network services,= the classification is usually coarse and fixed. For example, CPE can assig= n different QoS to differentiate video, voice and data traffic, but CPE can= 't differentiate the applications under data category even though more and = more data traffic are carrying video content. It is impossible for applications to get differentiated services from publi= c internet, such as hotspot WIFI. It is also not possible for applications = to change network behavior. For example it is not easy for AntiDoS applicat= ions to enforce certain traffic to a special scrubbing center when some thr= eat is detected. Today, more and more applications need differentiated services from network= . Some applications may need special services for a specific time span, whi= le other applications may need to indicate their unique characteristics to = the network for special treatment, especially when they send encrypted traf= fic. The working group will examine what network characteristics that applicatio= ns need to communicate with network, define general framework and architect= ure for enabling those communications, examine existing protocols for those= communications, and potentially identify new protocols. Specifically, the Working Group will: 1. Identify the applications (or use cases) that need differentiated servi= ces, and time based services. 2. identify typical workflows for which heuristic based approaches are used 2. identify limitations of existing solutions 3. create a set of requirements for a solution based on explicit communication between applications and the network that can be applied in a consistent fashion across a variety of signaling protocols 4. identify a set of use cases addressable by such a solution 5. identify the information that needs to be communicated between application and the network 6. create a framework for providing this communication between applications and the network and that addresses the use cases 7. specify how existing signaling protocols can be enhanced to support this framework The Working Group is expected to work closely with other Transport area groups. The following topics are out of scope of this Working Group: TBD Deliverables: TBD Milestones: TBD _______________________________________________ Aeon mailing list Aeon@ietf.org https://www.ietf.org/mailman/listinfo/aeon --_000_4A95BA014132FF49AE685FAB4B9F17F645D2E909dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Alper,

 <= /p>

Do you mean exchange Meta= data via control plane or out-of-band signal? Such as today’s Mobile = network using Diameter to pass metadata to service functions?

 <= /p>

Linda

 <= /p>

From: Alper Ye= gin [mailto:alper.yegin@yegin.org]
Sent: Thursday, June 05, 2014 3:30 AM
To: Linda Dunbar
Cc: Fan, Peng; 'Tirumaleswar Reddy (tireddy)'; aeon@ietf.org
Subject: Re: [Aeon] Charter Proposal

 

Hi Linda,

 

The metadata "may" also be communicated at= the beginning of the IP flow. In other words, it does not have to be commu= nicated on each IP packet.

So, AEON may not be just about extending SFC all the= way to the terminal.

 

Alper

 

 

On Jun 4, 2014, at 8:31 PM, Linda Dunbar wrote:=



Peng,

 

For metadata to be visibl= e to the network, the metadata have to be carried in a header such as SFC header.

Is AEON also defining thi= s Metadata header? Should the Metadata Header defined by AEON consistent wi= th the Metadata defined by SFC?

 

I am just concerned if AE= ON only focus on the metadata between applications and service functions, t= hen AEON would become a subset of SFC WG deliverables.<= o:p>

 

Linda

 

 

From: Fan, Peng [mailto:fanpeng@chinamobil= e.com] 
Sent: Wednesday, J= une 04, 2014 8:16 AM
To: Linda Dunbar; = 'Tirumaleswar Reddy (tireddy)'; aeon@ietf.org
Subject: RE: [Aeon= ] Charter Proposal

 

Hi Linda,

 

I am trying to understand= why the metadata is not visible to network. Flow characteristics, or metad= ata, are conveyed to network nodes which can be a gateway, a router, or other elements that need visibility into the traffic. These n= odes are not necessarily a DPI element, and are not necessarily located at = the edge or center of a network. Speaking of SFC metadata I would like to k= now how is it related with flow characteristics we are now working on.

 

We have not gone that far= in discussing how the characteristics are encoded and carried, though at t= he very early age of this work there were some drafts on this. Also I remember this minutes of the barbof at London IETF which I th= ink is helpful in showing some of the concepts of this work http://www.ietf.org/mail-archive/web/ae= on/current/msg00025.html.

 

Best regards,

Peng<= o:p>

 

From: Aeon [mailto:aeon-bounces@ietf.org= ] On Behalf Of Linda Dunbar
Sent: Tuesday, Jun= e 03, 2014 11:57 PM
To: Fan, Peng; 'Ti= rumaleswar Reddy (tireddy)'; aeon@ietf.org
Subject: Re: [Aeon= ] Charter Proposal

 

Peng,

 

The current charter state= ment is all about applications exchanging information with network function= s, such as DPI, FW, etc.

 

This is the Metadata, &nb= sp;which have been addressed by SFC WG. Why creating a new WG simply for Me= tadata? Besides, all traffic will be aggregated by the provider edge devices. The DPI/FW in the middle of the provider networks can’= t even seen those metadata attached to Applications, unless using a new hea= der such as SFC header to carry those metadata.

 

Linda

 

 

From: Fan, Peng [mailto:fanpeng@chinamobil= e.com] 
Sent: Monday, June= 02, 2014 10:50 PM
To: 'Tirumaleswar = Reddy (tireddy)'; Linda Dunbar; = aeon@ietf.org
Subject: RE: [Aeon= ] Charter Proposal

 

Yes Tiru I have sent the = proposal request to both INT and TSV ADs last week. Thank you Linda for you= r contribution, I will try to incorporate the ideas into the draft charter.

 

Hi all,

 

The current BoF proposal = can be found at http://wiki.tools.ietf.o= rg/bof/trac/#Internet. It includes a revised draft charter based on the initial version before th= e last IETF meeting, and I would appreciate it if you all can share opinion= s about the current proposal and help revise the draft charter.

 

Best regards,

Peng<= o:p>

 

From: Aeon [mailto:aeon-bounces@ietf.org= ] On Behalf Of Tirumaleswar Reddy (tireddy)=
Sent: Monday, June= 02, 2014 12:20 PM
To: Linda Dunbar;<= span class=3D"apple-converted-space"> aeon@ietf.org
Subject: Re: [Aeon= ] Charter Proposal

 

I think Peng has already sent = the revised charter proposal to AD based on the updated problem statement drafthttp:= //tools.ietf.org/html/draft-conet-aeon-problem-statement-00<= /span>

 

-Tiru

 

From: Aeon [mailto:aeon-bounces@ietf.org= ] On Behalf Of Linda Dunbar
Sent: Monday, June= 02, 2014 3:33 AM
To: aeon@ietf.org
Subject: Re: [Aeon= ] Charter Proposal

 

We really need to send the BOF request = by Thurs (June 5) because June 6th is the BoF request deadline.

The previously proposed charter only focuses on why operators = wanting to know applications. Without applications wanting to send their ch= aracteristics to network, the network has to depend on DPI (or nothing when the traffic is encrypted).

I think that we should change the angle to describe why today&= #8217;s applications need to send their traffic characteristics to network = for differentiated services. With this in mind, I rewrote the charter proposal:

Do people on the list agree if we can send this charter  = proposal to the Transport ADs (Spencer & Martin) to request a BoF in To= ronto.

Linda

Description of Working Group:

 

Today’s traffic characteristics, such as bandwidth, = delay, loss, jitter, etc, are statically configured and managed by service = providers on per client or port basis. Even with edge devices or CPE (customer premises equipment) being able to configure diffe= rent QoS for differentiated network services, the classification is usually= coarse and fixed. For example, CPE can assign different QoS to differentia= te video, voice and data traffic, but CPE can’t differentiate the applications under data category eve= n though more and more data traffic are carrying video content. 

It is impossible for applications to get differentiated se= rvices from public internet, such as hotspot WIFI. It is also not possible = for applications to change network behavior. For example it is not easy for AntiDoS applications to enforce certain traffic= to a special scrubbing center when some threat is detected.

 

Today, more and more applications need differentiated serv= ices from network. Some applications may need special services for a specif= ic time span, while other applications may need to indicate their unique characteristics to the network for special treatm= ent, especially when they send encrypted traffic.<= /o:p>

 

The wo= rking group will examine what network characteristics that applications nee= d to communicate with network, define general framework and architecture fo= r enabling those communications, examine existing protocols for those communications, and potentially identify new protocols= .

Specifically, the Working Group will:<= o:p>

1.  Iden= tify the applications (or use cases) that need differentiated services, and tim= e based services.

 

2. identify typical workflows for which heuristic based ap= proaches are used

2. identify limitations of existing solutions

3. create a set of requirements for a solution based on ex= plicit

communication between applications and the network that ca= n be applied in

a consistent fashion across a variety of signaling protoco= ls

4. identify a set of use cases addressable by such a solut= ion

5. identify the information that needs to be communicated = between

application and the network=

6. create a framework for providing this communication bet= ween

applications and the network and that addresses the use ca= ses

7. specify how existing signaling protocols can be enhance= d to support

this framework

 

The Working Group is expected to work closely with other T= ransport area

groups.

 

The following topics are out of scope of this Working Grou= p:

TBD

 

Deliverables:

TBD

 

Milestones:

TBD

 

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

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645D2E909dfweml701chmchi_-- From nobody Thu Jun 5 14:00:57 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 8D6941A0278 for ; Thu, 5 Jun 2014 14:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 4QMAQltQPDiN for ; Thu, 5 Jun 2014 14:00:50 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C50E71A0273 for ; Thu, 5 Jun 2014 14:00:49 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MAhGN-1X4VOa45sZ-00BSAW; Thu, 05 Jun 2014 17:00:35 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_2B08547B-B30B-4E34-845B-40B4722B6F16" From: Alper Yegin In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D2E909@dfweml701-chm.china.huawei.com> Date: Fri, 6 Jun 2014 00:00:27 +0300 Message-Id: <502E9670-4A1A-484C-8E13-B7052B71454B@yegin.org> References: <4A95BA014132FF49AE685FAB4B9F17F645D2A013@dfweml701-chm.china.huawei.com> <913383AAA69FF945B8F946018B75898A282C5254@xmb-rcd-x10.cisco.com> <012d01cf7ede$dba2c1f0$92e845d0$@chinamobile.com> <4A95BA014132FF49AE685FAB4B9F17F645D2BDA6@dfweml701-chm.china.huawei.com> <005d01cf7ff7$2cdcc7f0$869657d0$@chinamobile.com> <4A95BA014132FF49AE685FAB4B9F17F645D2DFDC@dfweml701-chm.china.huawei.com> <0E465B5F-73D3-4813-9CFA-21D3A730D8F0@yegin.org> <4A95BA014132FF49AE685FAB4B9F17F645D2E909@dfweml701-chm.china.huawei.com> To: Linda Dunbar X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:Yh9AUtUe+jzNVMOZL08kXRQSpq19L3UkiT+KqmL6qbS ZRsHky2UJrVw6sMOSc0R5uZz4xs8rBj1dXPQap4M1pbX3te4er hRE21Xlx4mw7L7Zq26iaYRVkxuwfLD06i+AXlgIAHK+BTSURCu xo51vKD/b0ZOTlnobpGBe1dcyouy3P1z6xQyh4SixTdANKUxFF YwiKUZ+ZfqwCwSfuxdOHCnQHkckusw9U+tZyvi7QisjCER8PIR /zdlstKtTKxn34lkIJQR3XhvdaPzlsryUjgNLK3MZDwydh61IV ystoZnzHYTenpFrgtkTBsLO297K+VLvEfjHJH/CG3ce9iTvwZo seLRn3kpBAV0zFhVRGBN536RDoeqb3QsiVpFGN0wsPGJUDUC1U UgxBHCTd/RF3Q== Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/_6YEBgcAgLqT2FEKKCDVBC0TDjs Cc: "aeon@ietf.org" , "Fan, Peng" , "'Tirumaleswar Reddy \(tireddy\)'" Subject: Re: [Aeon] Charter 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, 05 Jun 2014 21:00:53 -0000 --Apple-Mail=_2B08547B-B30B-4E34-845B-40B4722B6F16 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Linda, On Jun 5, 2014, at 6:49 PM, Linda Dunbar wrote: > Alper, > =20 > Do you mean exchange Metadata via control plane or out-of-band signal? Yes. Alper > Such as today=92s Mobile network using Diameter to pass metadata to = service functions? > =20 > Linda > =20 > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Thursday, June 05, 2014 3:30 AM > To: Linda Dunbar > Cc: Fan, Peng; 'Tirumaleswar Reddy (tireddy)'; aeon@ietf.org > Subject: Re: [Aeon] Charter Proposal > =20 > Hi Linda, > =20 > The metadata "may" also be communicated at the beginning of the IP = flow. In other words, it does not have to be communicated on each IP = packet. > So, AEON may not be just about extending SFC all the way to the = terminal. > =20 > Alper > =20 > =20 > On Jun 4, 2014, at 8:31 PM, Linda Dunbar wrote: >=20 >=20 > Peng, > =20 > For metadata to be visible to the network, the metadata have to be = carried in a header such as SFC header. > Is AEON also defining this Metadata header? Should the Metadata Header = defined by AEON consistent with the Metadata defined by SFC? > =20 > I am just concerned if AEON only focus on the metadata between = applications and service functions, then AEON would become a subset of = SFC WG deliverables. > =20 > Linda > =20 > =20 > From: Fan, Peng [mailto:fanpeng@chinamobile.com]=20 > Sent: Wednesday, June 04, 2014 8:16 AM > To: Linda Dunbar; 'Tirumaleswar Reddy (tireddy)'; aeon@ietf.org > Subject: RE: [Aeon] Charter Proposal > =20 > Hi Linda, > =20 > I am trying to understand why the metadata is not visible to network. = Flow characteristics, or metadata, are conveyed to network nodes which = can be a gateway, a router, or other elements that need visibility into = the traffic. These nodes are not necessarily a DPI element, and are not = necessarily located at the edge or center of a network. Speaking of SFC = metadata I would like to know how is it related with flow = characteristics we are now working on. > =20 > We have not gone that far in discussing how the characteristics are = encoded and carried, though at the very early age of this work there = were some drafts on this. Also I remember this minutes of the barbof at = London IETF which I think is helpful in showing some of the concepts of = this work = http://www.ietf.org/mail-archive/web/aeon/current/msg00025.html. > =20 > Best regards, > Peng > =20 > From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Linda Dunbar > Sent: Tuesday, June 03, 2014 11:57 PM > To: Fan, Peng; 'Tirumaleswar Reddy (tireddy)'; aeon@ietf.org > Subject: Re: [Aeon] Charter Proposal > =20 > Peng, > =20 > The current charter statement is all about applications exchanging = information with network functions, such as DPI, FW, etc. > =20 > This is the Metadata, which have been addressed by SFC WG. Why = creating a new WG simply for Metadata? Besides, all traffic will be = aggregated by the provider edge devices. The DPI/FW in the middle of the = provider networks can=92t even seen those metadata attached to = Applications, unless using a new header such as SFC header to carry = those metadata. > =20 > Linda > =20 > =20 > From: Fan, Peng [mailto:fanpeng@chinamobile.com]=20 > Sent: Monday, June 02, 2014 10:50 PM > To: 'Tirumaleswar Reddy (tireddy)'; Linda Dunbar; aeon@ietf.org > Subject: RE: [Aeon] Charter Proposal > =20 > Yes Tiru I have sent the proposal request to both INT and TSV ADs last = week. Thank you Linda for your contribution, I will try to incorporate = the ideas into the draft charter. > =20 > Hi all, > =20 > The current BoF proposal can be found at = http://wiki.tools.ietf.org/bof/trac/#Internet. It includes a revised = draft charter based on the initial version before the last IETF meeting, = and I would appreciate it if you all can share opinions about the = current proposal and help revise the draft charter. > =20 > Best regards, > Peng > =20 > From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Tirumaleswar = Reddy (tireddy) > Sent: Monday, June 02, 2014 12:20 PM > To: Linda Dunbar; aeon@ietf.org > Subject: Re: [Aeon] Charter Proposal > =20 > I think Peng has already sent the revised charter proposal to AD based = on the updated problem statement = drafthttp://tools.ietf.org/html/draft-conet-aeon-problem-statement-00 > =20 > -Tiru > =20 > From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Linda Dunbar > Sent: Monday, June 02, 2014 3:33 AM > To: aeon@ietf.org > Subject: Re: [Aeon] Charter Proposal > =20 > We really need to send the BOF request by Thurs (June 5) because June = 6th is the BoF request deadline. > The previously proposed charter only focuses on why operators wanting = to know applications. Without applications wanting to send their = characteristics to network, the network has to depend on DPI (or nothing = when the traffic is encrypted). >=20 > I think that we should change the angle to describe why today=92s = applications need to send their traffic characteristics to network for = differentiated services. With this in mind, I rewrote the charter = proposal: >=20 > Do people on the list agree if we can send this charter proposal to = the Transport ADs (Spencer & Martin) to request a BoF in Toronto. >=20 > Linda >=20 > Description of Working Group: > =20 > Today=92s traffic characteristics, such as bandwidth, delay, loss, = jitter, etc, are statically configured and managed by service providers = on per client or port basis. Even with edge devices or CPE (customer = premises equipment) being able to configure different QoS for = differentiated network services, the classification is usually coarse = and fixed. For example, CPE can assign different QoS to differentiate = video, voice and data traffic, but CPE can=92t differentiate the = applications under data category even though more and more data traffic = are carrying video content.=20 > It is impossible for applications to get differentiated services from = public internet, such as hotspot WIFI. It is also not possible for = applications to change network behavior. For example it is not easy for = AntiDoS applications to enforce certain traffic to a special scrubbing = center when some threat is detected. > =20 > Today, more and more applications need differentiated services from = network. Some applications may need special services for a specific time = span, while other applications may need to indicate their unique = characteristics to the network for special treatment, especially when = they send encrypted traffic. > =20 > The working group will examine what network characteristics that = applications need to communicate with network, define general framework = and architecture for enabling those communications, examine existing = protocols for those communications, and potentially identify new = protocols. >=20 > Specifically, the Working Group will: > 1. Identify the applications (or use cases) that need differentiated = services, and time based services. > =20 > 2. identify typical workflows for which heuristic based approaches are = used > 2. identify limitations of existing solutions > 3. create a set of requirements for a solution based on explicit > communication between applications and the network that can be applied = in > a consistent fashion across a variety of signaling protocols > 4. identify a set of use cases addressable by such a solution > 5. identify the information that needs to be communicated between > application and the network > 6. create a framework for providing this communication between > applications and the network and that addresses the use cases > 7. specify how existing signaling protocols can be enhanced to support > this framework > =20 > The Working Group is expected to work closely with other Transport = area > groups. > =20 > The following topics are out of scope of this Working Group: > TBD > =20 > Deliverables: > TBD > =20 > Milestones: > TBD > =20 > _______________________________________________ > Aeon mailing list > Aeon@ietf.org > https://www.ietf.org/mailman/listinfo/aeon > =20 > _______________________________________________ > Aeon mailing list > Aeon@ietf.org > https://www.ietf.org/mailman/listinfo/aeon --Apple-Mail=_2B08547B-B30B-4E34-845B-40B4722B6F16 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Linda,


On Jun = 5, 2014, at 6:49 PM, Linda Dunbar wrote:

Do = you mean exchange Metadata via control plane or out-of-band signal? =


Yes.

Alper



Such = as today=92s Mobile network using Diameter to pass metadata to service = functions?
From: Alper Yegin = [mailto:alper.yegin@yegin.org] 
Sent: Thursday, June 05, 2014 = 3:30 AM
To: Linda = Dunbar
Cc: Fan, Peng; 'Tirumaleswar = Reddy (tireddy)'; aeon@ietf.org
Subject: Re: [Aeon] Charter = Proposal
Hi = Linda,
The metadata "may" also = be communicated at the beginning of the IP flow. In other words, it does = not have to be communicated on each IP = packet.
So, AEON may not be just = about extending SFC all the way to the = terminal.
On Jun 4, 2014, at 8:31 = PM, Linda Dunbar wrote:
 For = metadata to be visible to the network, the metadata have to be carried = in a header such as = SFC header.
Is AEON also defining this Metadata header? Should = the Metadata Header defined by AEON consistent with the Metadata defined = by SFC?
 I am = just concerned if AEON only focus on the metadata between applications = and service functions, then AEON would become a subset of SFC WG = deliverables.
 
 
Fan, Peng [mailto:fanpeng@chinamobile.com] 
Sent: Wednesday, June 04, 2014 = 8:16 AM
To: Linda Dunbar; 'Tirumaleswar = Reddy (tireddy)'; aeon@ietf.org
Subject: RE: [Aeon] Charter = Proposal
 
Hi Linda,
I am trying to understand why the metadata is not = visible to network. Flow characteristics, or metadata, are conveyed to = network nodes which can be a gateway, a router, or other elements that = need visibility into the traffic. These nodes are not necessarily a DPI = element, and are not necessarily located at the edge or center of a = network. Speaking of SFC metadata I would like to know how is it related = with flow characteristics we are now working on.
We have not gone that far in discussing how the = characteristics are encoded and carried, though at the very early age of = this work there were some drafts on this. Also I remember this minutes = of the barbof at London IETF which I think is helpful in showing some of = the concepts of this work 
 
Peng,
The current charter statement is all about = applications exchanging information with network functions, such as DPI, = FW, etc.
 This = is the Metadata,  which have been addressed by SFC WG. Why creating = a new WG simply for Metadata? Besides, all traffic will be aggregated by = the provider edge devices. The DPI/FW in the middle of the provider = networks can=92t even seen those metadata attached to Applications, = unless using a new header such as SFC header to carry those = metadata.
 
 
Fan, Peng [mailto:fanpeng@chinamobile.com] 
Sent: Monday, June 02, 2014 10:50 = PM
To: 'Tirumaleswar Reddy = (tireddy)'; Linda Dunbar; aeon@ietf.org
Subject: RE: [Aeon] Charter = Proposal
 
Yes Tiru I have sent the proposal = request to both INT and TSV ADs last week. Thank you Linda for your = contribution, I will try to incorporate the ideas into the draft = charter.
 Hi = all,
 The = current BoF proposal can be found at 
 
I think Peng has = already sent the revised charter proposal to AD based on the updated = problem statement draft
 
We really need to send the BOF request by Thurs (June 5) = because June 6th is the BoF request = deadline.

The = previously proposed charter only focuses on why operators wanting to = know applications. Without applications wanting to send their = characteristics to network, the network has to depend on DPI (or nothing = when the traffic is encrypted).

I think that we should change the angle to describe why = today=92s applications need to send their traffic characteristics to = network for differentiated services. With this in mind, I rewrote the = charter proposal:

Do people = on the list agree if we can send this charter  proposal to the = Transport ADs (Spencer & Martin) to request a BoF in = Toronto.

Linda

Description of Working Group: Today=92s traffic characteristics, = such as bandwidth, delay, loss, jitter, etc, are statically configured = and managed by service providers on per client or port basis. Even with = edge devices or CPE (customer premises equipment) being able to = configure different QoS for differentiated network services, the = classification is usually coarse and fixed. For example, CPE can assign = different QoS to differentiate video, voice and data traffic, but CPE = can=92t differentiate the applications under data category even though = more and more data traffic are carrying video content. It is impossible for applications to = get differentiated services from public internet, such as hotspot WIFI. = It is also not possible for applications to change network behavior. For = example it is not easy for AntiDoS applications to enforce certain = traffic to a special scrubbing center when some threat is = detected.
Today, more and = more applications need differentiated services from network. Some = applications may need special services for a specific time span, while = other applications may need to indicate their unique characteristics to = the network for special treatment, especially when they send encrypted = traffic.

The working = group will examine what network characteristics that applications need = to communicate with network, define general framework and architecture = for enabling those communications, examine existing protocols for those = communications, and potentially identify new protocols.Specifically, the Working Group = will:

1. Identify the = applications (or use cases) that need differentiated services, and time = based services.
 2. identify typical workflows for = which heuristic based approaches are used2. identify limitations of existing = solutions
3. create a set = of requirements for a solution based on explicitcommunication between applications = and the network that can be applied ina consistent fashion across a = variety of signaling protocols4. identify a set of use cases = addressable by such a solution5. identify the information that = needs to be communicated betweenapplication and the = network
6. create a = framework for providing this communication betweenapplications and the network and = that addresses the use cases7. specify how existing signaling = protocols can be enhanced to supportthis framework The Working Group is expected to = work closely with other Transport areagroups. The following topics are out of = scope of this Working Group:TBD Deliverables:TBD Milestones:TBDAeon@ietf.org
To: =?gb2312?B?J8vvvaPpqic=?= , References: <00c101cf809e$063098f0$1291cad0$@chinamobile.com> <006701cf80a5$7dfa2b60$79ee8220$@com> In-Reply-To: <006701cf80a5$7dfa2b60$79ee8220$@com> Date: Fri, 6 Jun 2014 11:01:15 +0800 Message-ID: <002d01cf8133$94cea6c0$be6bf440$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEDg0X2P7Oj/l4XNXZT43BBjmDoTANLAzZQnOEIW7A= Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/o91P1_PR7Uza9ssAObcaupnUggo Subject: Re: [Aeon] FW: New Version Notification for draft-conet-aeon-use-cases-00.txt 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, 06 Jun 2014 03:01:36 -0000 Hi Jiannan, Thanks for your reminding of software distribution from an application provider's point of view. If an end user application is participating in = the solution, it is worth suggesting that application providers wishing to benefit from such a solution should bear in mind that users may not = update immediately from old versions, which are not yet supporting the = function. Best regards, Peng -----Original Message----- From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of = =CB=EF=BD=A3=E9=AA Sent: Thursday, June 05, 2014 6:04 PM To: aeon@ietf.org Subject: Re: [Aeon] FW: New Version Notification for draft-conet-aeon-use-cases-00.txt It is technically feasible. For application providers, if it is = compatible with the old version should be taken into account when put into use. It = is related to version distribution and operation & maintanaince other than technical matters. _______________________________________________ Aeon mailing list Aeon@ietf.org https://www.ietf.org/mailman/listinfo/aeon From nobody Sat Jun 7 16:29: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 613CE1A0449 for ; Fri, 6 Jun 2014 03:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 bbJt_O22JHLd for ; Fri, 6 Jun 2014 03:03:15 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB5481A02C1 for ; Fri, 6 Jun 2014 03:03:14 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id rl12so2134711iec.23 for ; Fri, 06 Jun 2014 03:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:subject:mime-version:content-type; bh=TONUPlGdvIIzYFZISWanNdDgqmmEHBbHfRxYyT7NxRw=; b=zAf9Qopvi0hVmV9JcmypQDoRcaON/FDYQ8ZZOos8N+bssiFJOq27SI30DeFT8B1jn1 yGdG01BdH3nFcEn2cxJbTuBRRGNamlz4WPCKDc1LonApLIAXWaxJOzvxsdoCvHb6gCye SWlYMt6m7DPqwMSVfRHQ8LfT6b37ebbJ8HLedH31MGaa0n932Lz+NfJLQSf6MbV19x7T gslg0tPeBQBCLU3qRPmaTreCtlGT1yk5sTPY5rwdtny9h9rpR3mK9Qsa4bh1zHCUR1NT 4N2c9uew+jVM10iy/vFlGqx1nA1uoJGuAfXCqcg+wZcKjkg+eCrPAVQGqh/8q1Tg6ARH JfOg== X-Received: by 10.50.25.101 with SMTP id b5mr4149987igg.26.1402048987849; Fri, 06 Jun 2014 03:03:07 -0700 (PDT) Received: from [183.243.155.59] ([183.243.155.59]) by mx.google.com with ESMTPSA id wp3sm33805328pbc.67.2014.06.06.03.03.05 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 06 Jun 2014 03:03:06 -0700 (PDT) Date: Fri, 6 Jun 2014 18:07:22 +0800 From: Dapeng Liu To: aeon@ietf.org Message-ID: <01CCF4AE8F724BFD99678882E2C12F67@gmail.com> X-Mailer: sparrow 1.6.3 (build 1173) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="539192da_3f07acc3_1e7" Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/qz93-MIp6y4sGRqPmOc7N4li5Zg X-Mailman-Approved-At: Sat, 07 Jun 2014 16:29:21 -0700 Subject: [Aeon] use case document 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, 06 Jun 2014 10:03:16 -0000 --539192da_3f07acc3_1e7 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello All, I have read the use case document and have one comment: http://www.ietf.org/id/draft-conet-aeon-use-cases-00.txt Section 2.4 Multi-interface selection: MIF working group also trying to solve the similar problem, may need coordination or work together with MIF WG. For your reference: 1. MIF charter: http://datatracker.ietf.org/wg/mif/charter/ 2. Current documents: http://datatracker.ietf.org/wg/mif/ -- Dapeng Liu --539192da_3f07acc3_1e7 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hello All,

I have read the use case docume= nt and have one comment: 

http://www.ietf.o= rg/id/draft-conet-aeon-use-cases-00.txt

Section = 2.4 Multi-interface selection: MI=46 working group also trying to solve t= he similar problem, may need coordination or work together with MI=46 WG.=

=46or your reference:
1. MI=46 charte= r: http://datatracker.ietf.org/wg/mif/charter/
2. Current = documents: http://datatracker.ietf.org/wg/mif/

-- 
Dapeng Liu
--539192da_3f07acc3_1e7-- From nobody Wed Jun 11 13:41:15 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 997671A029B for ; Wed, 11 Jun 2014 13:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 SnLCIrM-1Zga for ; Wed, 11 Jun 2014 13:41:11 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A551A0081 for ; Wed, 11 Jun 2014 13:41:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6895; q=dns/txt; s=iport; t=1402519272; x=1403728872; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=3LN3kZxAg93Qle5tYIkpteS4bpOZcVkcnNNCMlBLVF8=; b=gU3IZGaqsutno8uqRVs3AqvGwO75MscIwftQBCP9s5AzoQc8NM4DPJTg APizoR+NdrQ/C9oBHDzh/R0ZvaItcY7RbBWLcfCzdpdEPoBZpBV0uTThW UlP53CPdjdBnItx9LPp5vmyaDA3VT1cmR5cPFMfibxuiAGeBTxaLnKYpw c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcFADK+mFOtJV2a/2dsb2JhbABQCoMNUlmqTgEBAQEBAQUBkV+HPAGBCBZ1hAMBAQEEAQEBNy0HCQ4EAgEIEQQBAR8JBycLFAkIAgQBCQkJEognDdAeF4Vcg1GEUGMGhDsEmi6BQpIJgXyBQIIv X-IronPort-AV: E=Sophos;i="5.01,460,1400025600"; d="scan'208";a="332216646" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 11 Jun 2014 20:41:11 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s5BKfAlI014732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jun 2014 20:41:10 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.9]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Wed, 11 Jun 2014 15:41:10 -0500 From: "Charles Eckel (eckelcu)" To: Linda Dunbar , "Paul E. Jones" , "aeon@ietf.org" Thread-Topic: [Aeon] New Version Notification for draft-conet-aeon-problem-statement-00.txt Thread-Index: AQHPdtuQqD2ZBTVI7EKTZI/ZuDsHO5tOqYOAgAZaNRCAAF8dgIAJalOAgA3A14A= Date: Wed, 11 Jun 2014 20:41:10 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F645D265BF@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645D2B79D@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D2B79D@dfweml701-chm.china.huawei.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.101.201] Content-Type: text/plain; charset="us-ascii" Content-ID: <2CDA54D0BA02B249A23FD67C5EDDFE87@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/Hyo-P0785PZyQap7VTsTh-ZeEKw Subject: Re: [Aeon] New Version Notification for draft-conet-aeon-problem-statement-00.txt 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, 11 Jun 2014 20:41:13 -0000 Hi Linda, Sorry for the delated response. I was away on vacation and am still playing catchup. Please see inline. On 6/2/14, 3:39 PM, "Linda Dunbar" wrote: >Comments inserted below: > >-----Original Message----- >From: Paul E. Jones [mailto:paulej@packetizer.com] >Sent: Tuesday, May 27, 2014 5:53 PM >To: Linda Dunbar; Charles Eckel (eckelcu); aeon@ietf.org >Subject: Re: [Aeon] New Version Notification for >draft-conet-aeon-problem-statement-00.txt > >Linda, > >I'd assume this is open for discussion, but I can imagine information >such as tolerance to loss, delay, and jitter are important. > >One piece of data I think would be useful to send into the network is the >Traffic Class Label (TCL), which identifies with some precision what the >flow is. For example, is this a real-time gaming session, a >conversational voice/video session, bulk file transfer, or other? The >TCL would tell us this. > >Another piece of data might just be some kind of locally-determined >priority value. > >[Linda] I can see that Applications can be motivated to request those >traffic characteristics from to network to achieve better services. Great. >=20 > >Sending those traffic characteristics to network devices is so much like >the User-Network interface (which was hot during 2001 time frame). After >15 years, it still didn't take off. Why: Because there are so many >access devices deployed. Service providers can't afford to upgrade such >massively deployed access devices to take care of new signal, billing, >etc. Are you referring to NSIS? If not, can you provide a ptr? It is certainly helpful and important to learn from the past. >=20 > >A much more realistic way is for the signal to be sent to a "broker" (or >controller) that can take requests from Applications and dispatch the >relevant configuration to the network elements. Such an approach has some nice properties. I envision there being multiple ways to exchange well defined flow characteristics between application and the network. Pal-Erik mentioned one way, you suggest another. A controller based solution works very well in some scenarios, but has challenges in others. If I understand your proposal, each application needs to discover the right controller(s), and the controller(s) need to be able to identify and configure the network elements in the path of each media stream associated with the application. So there are tradeoffs. Cheers, Charles >=20 > >Linda=20 > >=20 > > >You're correct that traffic is aggregated, but it might be useful if this >information could somehow be conveyed end-to-end for the benefit of other >carrier or enterprise networks. > >Paul > >------ Original Message ------ >From: "Linda Dunbar" >To: "Charles Eckel (eckelcu)" ; "aeon@ietf.org" > >Sent: 5/27/2014 6:22:01 PM >Subject: Re: [Aeon] New Version Notification for >draft-conet-aeon-problem-statement-00.txt > >>Charles, et al: >> >>Your Req-1 states "allow applications to explicitly signal their flow >>characteristics to the networks". >> >>Can you give a few examples of what those "flow characteristics" are? >> >>The draft also states that DPI can't be performed when the traffic is >>encrypted. What kind of signals will the applications that encrypt >>their traffic send to network? >> >> >>Almost all End to End traffic are aggregated by network operators edge >>devices (there could be many layers of operators). All the signals from >>end devices are lost once entering provider domain. I think a more >>realistic approach is to establish interface between applications to >>network controllers. >> >> >>Linda >>-----Original Message----- >>From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Charles Eckel >>(eckelcu) >>Sent: Friday, May 23, 2014 6:12 PM >>To: aeon@ietf.org >>Subject: [Aeon] FW: New Version Notification for >>draft-conet-aeon-problem-statement-00.txt >> >>The following draft is the result of merging the CoNET and AEON problem >>statement drafts discussed previously on this list. It is intended as a >>replacement for both of them, combining important aspects of both and >>addressing review comments received to date. Please review and share >>your comments. >> >>Cheers, >>Charles >> >>On 5/23/14, 4:05 PM, "internet-drafts@ietf.org" >> >>wrote: >> >>> >>>A new version of I-D, draft-conet-aeon-problem-statement-00.txt >>>has been successfully submitted by Charles Eckel and posted to the >>>IETF repository. >>> >>>Name: draft-conet-aeon-problem-statement >>>Revision: 00 >>>Title: Application Enabled Collaborative Networking: Problem Statement >>>and Requirements Document date: 2014-05-21 >>>Group: Individual Submission >>>Pages: 11 >>>URL: >>>http://www.ietf.org/internet-drafts/draft-conet-aeon-problem-statement-0 >>>0. >>>txt >>>Status: >>>https://datatracker.ietf.org/doc/draft-conet-aeon-problem-statement/ >>>Htmlized: >>>http://tools.ietf.org/html/draft-conet-aeon-problem-statement-00 >>> >>> >>>Abstract: >>> Identification and treatment of application flows are important to >>> many application providers and network operators. They often rely >>>on >>> these capabilities to deploy and/or support a wide range of >>> applications. These applications, and the packet flows they >>>generate >>> and consume, may have specific connectivity requirements that can >>>be >>> met if made known to the network. Historically, this functionality >>> has been implemented to the extent possible using heuristics, which >>> inspect and infer flow characteristics. Heuristics may be based on >>> port ranges, network separation (e.g. subnets or VLANs, Deep Flow >>> Inspection (DFI), or Deep Packet Inspection (DPI). But many >>> application flows in current usages are dynamic, adaptive, time- >>> bound, encrypted, peer-to-peer, asymmetric, used on multipurpose >>> devices, and have different priorities depending on direction of >>> flow, user preferences, and other factors. Any combination of these >>> properties renders heuristic based techniques less effective and >>>may >>> result in compromises to application security or user privacy. >>> >>> >>> >>> >>> >>>Please note that it may take a couple of minutes from the time of >>>submission until the htmlized version and diff are available at >>>tools.ietf.org. >>> >>>The IETF Secretariat >>> >> >>_______________________________________________ >>Aeon mailing list >>Aeon@ietf.org >>https://www.ietf.org/mailman/listinfo/aeon >> >>_______________________________________________ >>Aeon mailing list >>Aeon@ietf.org >>https://www.ietf.org/mailman/listinfo/aeon > From nobody Wed Jun 11 15:33:06 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 B1F7E1A031F for ; Wed, 11 Jun 2014 15:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 jM3a-qdBVAGM for ; Wed, 11 Jun 2014 15:33:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89F581A02ED for ; Wed, 11 Jun 2014 15:33:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BII12519; Wed, 11 Jun 2014 22:33:00 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 11 Jun 2014 23:32:59 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml703-chm.china.huawei.com ([169.254.5.144]) with mapi id 14.03.0158.001; Wed, 11 Jun 2014 15:32:46 -0700 From: Linda Dunbar To: "Charles Eckel (eckelcu)" , "Paul E. Jones" , "aeon@ietf.org" Thread-Topic: [Aeon] New Version Notification for draft-conet-aeon-problem-statement-00.txt Thread-Index: AQHPdtuQqD2ZBTVI7EKTZI/ZuDsHO5tOqYOAgAZaNRCAAICkgIAI8cBAgA58eQD//53RAA== Date: Wed, 11 Jun 2014 22:32:46 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D3373A@dfweml701-chm.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645D265BF@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645D2B79D@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/odXhjK0C-27Jqp2Nmdj1jdqtN78 Subject: Re: [Aeon] New Version Notification for draft-conet-aeon-problem-statement-00.txt 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, 11 Jun 2014 22:33:04 -0000 Charles,=20 Replies are inserted below: -----Original Message----- From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]=20 >=20 > >Sending those traffic characteristics to network devices is so much=20 >like the User-Network interface (which was hot during 2001 time frame).=20 >After >15 years, it still didn't take off. Why: Because there are so many=20 >access devices deployed. Service providers can't afford to upgrade such=20 >massively deployed access devices to take care of new signal, billing,=20 >etc. Are you referring to NSIS? If not, can you provide a ptr? It is certainly h= elpful and important to learn from the past. [Linda] the famous User Network Interface (UNI) which was started in 1999 (= OIF started UNI project) when there was a big push on Bandwidth on Demand f= or video distribution, or time-based network bandwidth. After 14 years, it = still hasn't been deployed very much for the reasons I stated above.=20 =20 >=20 > >A much more realistic way is for the signal to be sent to a "broker"=20 >(or >controller) that can take requests from Applications and dispatch the=20 >relevant configuration to the network elements. Such an approach has some nice properties. I envision there being multiple = ways to exchange well defined flow characteristics between application and = the network. Pal-Erik mentioned one way, you suggest another. A controller = based solution works very well in some scenarios, but has challenges in oth= ers. If I understand your proposal, each application needs to discover the = right controller(s), and the controller(s) need to be able to identify and = configure the network elements in the path of each media stream associated = with the application. So there are tradeoffs. [Linda] Applications don't have to "discover" the right controller. Wireles= s LTE has good model. We can borrow some concept to wireline.=20 Linda =20 >=20 > >Linda > >=20 > > >You're correct that traffic is aggregated, but it might be useful if=20 >this information could somehow be conveyed end-to-end for the benefit=20 >of other carrier or enterprise networks. > >Paul > >------ Original Message ------ >From: "Linda Dunbar" >To: "Charles Eckel (eckelcu)" ; "aeon@ietf.org" > >Sent: 5/27/2014 6:22:01 PM >Subject: Re: [Aeon] New Version Notification for=20 >draft-conet-aeon-problem-statement-00.txt > >>Charles, et al: >> >>Your Req-1 states "allow applications to explicitly signal their flow=20 >>characteristics to the networks". >> >>Can you give a few examples of what those "flow characteristics" are? >> >>The draft also states that DPI can't be performed when the traffic is=20 >>encrypted. What kind of signals will the applications that encrypt=20 >>their traffic send to network? >> >> >>Almost all End to End traffic are aggregated by network operators edge=20 >>devices (there could be many layers of operators). All the signals=20 >>from end devices are lost once entering provider domain. I think a=20 >>more realistic approach is to establish interface between applications=20 >>to network controllers. >> >> >>Linda >>-----Original Message----- >>From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Charles Eckel >>(eckelcu) >>Sent: Friday, May 23, 2014 6:12 PM >>To: aeon@ietf.org >>Subject: [Aeon] FW: New Version Notification for=20 >>draft-conet-aeon-problem-statement-00.txt >> >>The following draft is the result of merging the CoNET and AEON=20 >>problem statement drafts discussed previously on this list. It is=20 >>intended as a replacement for both of them, combining important=20 >>aspects of both and addressing review comments received to date.=20 >>Please review and share your comments. >> >>Cheers, >>Charles >> >>On 5/23/14, 4:05 PM, "internet-drafts@ietf.org" >> >>wrote: >> >>> >>>A new version of I-D, draft-conet-aeon-problem-statement-00.txt >>>has been successfully submitted by Charles Eckel and posted to the=20 >>>IETF repository. >>> >>>Name: draft-conet-aeon-problem-statement >>>Revision: 00 >>>Title: Application Enabled Collaborative Networking: Problem=20 >>>Statement and Requirements Document date: 2014-05-21 >>>Group: Individual Submission >>>Pages: 11 >>>URL: >>>http://www.ietf.org/internet-drafts/draft-conet-aeon-problem-statemen >>>t-0 >>>0. >>>txt >>>Status: >>>https://datatracker.ietf.org/doc/draft-conet-aeon-problem-statement/ >>>Htmlized: >>>http://tools.ietf.org/html/draft-conet-aeon-problem-statement-00 >>> >>> >>>Abstract: >>> Identification and treatment of application flows are important to >>> many application providers and network operators. They often rely=20 >>>on >>> these capabilities to deploy and/or support a wide range of >>> applications. These applications, and the packet flows they=20 >>>generate >>> and consume, may have specific connectivity requirements that can=20 >>>be >>> met if made known to the network. Historically, this functionality >>> has been implemented to the extent possible using heuristics, which >>> inspect and infer flow characteristics. Heuristics may be based on >>> port ranges, network separation (e.g. subnets or VLANs, Deep Flow >>> Inspection (DFI), or Deep Packet Inspection (DPI). But many >>> application flows in current usages are dynamic, adaptive, time- >>> bound, encrypted, peer-to-peer, asymmetric, used on multipurpose >>> devices, and have different priorities depending on direction of >>> flow, user preferences, and other factors. Any combination of these >>> properties renders heuristic based techniques less effective and=20 >>>may >>> result in compromises to application security or user privacy. >>> >>> >>> >>> >>> >>>Please note that it may take a couple of minutes from the time of=20 >>>submission until the htmlized version and diff are available at=20 >>>tools.ietf.org. >>> >>>The IETF Secretariat >>> >> >>_______________________________________________ >>Aeon mailing list >>Aeon@ietf.org >>https://www.ietf.org/mailman/listinfo/aeon >> >>_______________________________________________ >>Aeon mailing list >>Aeon@ietf.org >>https://www.ietf.org/mailman/listinfo/aeon > From nobody Mon Jun 30 06:21:37 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 B415D1A033E for ; Mon, 30 Jun 2014 06:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 DxqBylponC1x for ; Mon, 30 Jun 2014 06:21:33 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1A601A0338 for ; Mon, 30 Jun 2014 06:21:32 -0700 (PDT) X-AuditID: c1b4fb3a-f799e6d000005085-ec-53b1645ae7c5 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 99.0E.20613.A5461B35; Mon, 30 Jun 2014 15:21:30 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.228]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0174.001; Mon, 30 Jun 2014 15:21:29 +0200 From: Szilveszter Nadas To: "aeon@ietf.org" Thread-Topic: Next step, IETF 90? Thread-Index: Ac+UZitwzhnDUsdiSuWIYkG5NbmJTg== Date: Mon, 30 Jun 2014 13:21:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_EA4C43BE752A194597B002779DF69BAE23B3DD5CESESSMB303erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+JvjW5UysZggw1njSwO3Kp2YPRYsuQn UwBjFJdNSmpOZllqkb5dAlfGpc6lTAXPJCqaN19mbWB8KdrFyMkhIWAi8XHSHTYIW0ziwr31 QDYXh5DAUUaJaQ9XMEI4SxgljnZeZAapYhOwkGhYuRmsQ0RAWaL/5m1WEFtYQEbi9Lvl7BBx RYn+DxuBmjmAbD2JP4cEQMIsAqoSP6Y1MYHYvAK+Ets654ONZARa/P3UGrA4s4C4xK0n85kg DhKQWLLnPDOELSrx8vE/VpCREkDjl/fLQZTnS0xZeIwFYqSgxMmZT1gmMArNQjJpFpKyWUjK IOI6Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2M wHg4uOW31Q7Gg88dDzEKcDAq8fAuOLIhWIg1say4MvcQozQHi5I478Jz84KFBNITS1KzU1ML Uovii0pzUosPMTJxcEo1MHLtmGd77sWOLx/9t2689u6+6L4nPYmLL/yoqRFna2VO8uaf9dGi 5tLJ2APuLEnT5xe1mnP/V3ko4CVlqm1w/7m3juCUI6wn1u5rSji+tE8s8l8um8hMpqdfVS5L C2+waw+1/e/L1R3m67M3zUtkqnvtWcMNXeLprn48DrIfnh35HfSw4ZL1QiWW4oxEQy3mouJE AJRZQrNoAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/EiYmLLVEtDthROQ6zYTiUZ9y21s Subject: [Aeon] Next step, IETF 90? 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, 30 Jun 2014 13:21:35 -0000 --_000_EA4C43BE752A194597B002779DF69BAE23B3DD5CESESSMB303erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I have seen that the BoF was not approved for IETF 90. Did you receive a mo= re detailed explanation of the reasons? What is the next step? Will there be a Bar BoF at Toronto? Best Regards, Szilveszter --_000_EA4C43BE752A194597B002779DF69BAE23B3DD5CESESSMB303erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I have seen that the BoF was not approved for IETF 9= 0. Did you receive a more detailed explanation of the reasons?

 

What is the next step? Will there be a Bar BoF at To= ronto?

 

Best Regards,

Szilveszter

--_000_EA4C43BE752A194597B002779DF69BAE23B3DD5CESESSMB303erics_--