From internet-drafts@ietf.org Fri Mar 2 06:57:29 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A5E21F8587; Fri, 2 Mar 2012 06:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wz89jfvV217; Fri, 2 Mar 2012 06:57:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5720F21F8551; Fri, 2 Mar 2012 06:57:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120302145729.12075.62586.idtracker@ietfa.amsl.com> Date: Fri, 02 Mar 2012 06:57:29 -0800 Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-concepts-uses-04.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 14:57:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion Exposure Working Group of = the IETF. Title : ConEx Concepts and Use Cases Author(s) : Bob Briscoe Richard Woundy Alissa Cooper Filename : draft-ietf-conex-concepts-uses-04.txt Pages : 15 Date : 2012-03-02 This document provides the entry point to the set of documentation about the Congestion Exposure (ConEx) protocol. It explains the motivation for including a ConEx marking at the IP layer: to expose information about congestion to network nodes. Although such information may have a number of uses, this document focuses on how the information communicated by the ConEx marking can serve as the basis for significantly more efficient and effective traffic management than what exists on the Internet today. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-conex-concepts-uses-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-conex-concepts-uses-04.txt From acooper@cdt.org Fri Mar 2 06:59:13 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A4221F85D0 for ; Fri, 2 Mar 2012 06:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.373 X-Spam-Level: X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUmiVzOwpmd2 for ; Fri, 2 Mar 2012 06:59:12 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 3867921F85A4 for ; Fri, 2 Mar 2012 06:59:12 -0800 (PST) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for conex@ietf.org; Fri, 2 Mar 2012 09:59:10 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Alissa Cooper In-Reply-To: <20120302145729.12075.62586.idtracker@ietfa.amsl.com> Date: Fri, 2 Mar 2012 09:59:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2943B4DB-77D8-4A5C-B784-38559BE49F43@cdt.org> References: <20120302145729.12075.62586.idtracker@ietfa.amsl.com> To: ConEx IETF list X-Mailer: Apple Mail (2.1084) Subject: Re: [conex] I-D Action: draft-ietf-conex-concepts-uses-04.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 14:59:13 -0000 This version addresses all WGLC comments and is ready to have = publication requested. Alissa On Mar 2, 2012, at 9:57 AM, Internet-Drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Congestion Exposure = Working Group of the IETF. >=20 > Title : ConEx Concepts and Use Cases > Author(s) : Bob Briscoe > Richard Woundy > Alissa Cooper > Filename : draft-ietf-conex-concepts-uses-04.txt > Pages : 15 > Date : 2012-03-02 >=20 > This document provides the entry point to the set of documentation > about the Congestion Exposure (ConEx) protocol. It explains the > motivation for including a ConEx marking at the IP layer: to expose > information about congestion to network nodes. Although such > information may have a number of uses, this document focuses on how > the information communicated by the ConEx marking can serve as the > basis for significantly more efficient and effective traffic > management than what exists on the Internet today. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-conex-concepts-uses-04.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-conex-concepts-uses-04.txt >=20 > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex >=20 From marcelo@it.uc3m.es Mon Mar 5 22:23:13 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041C721F876E for ; Mon, 5 Mar 2012 22:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kmv-8WMtKJ3Y for ; Mon, 5 Mar 2012 22:23:12 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 4146021F876D for ; Mon, 5 Mar 2012 22:23:11 -0800 (PST) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 8A01E875CE2 for ; Tue, 6 Mar 2012 07:23:10 +0100 (CET) Message-ID: <4F55AD4E.3080007@it.uc3m.es> Date: Tue, 06 Mar 2012 07:23:10 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: 'ConEx IETF list' Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18756.003 Subject: [conex] Agenda requests for Paris IETF meeting X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 06:23:13 -0000 Hi, If you want a slot, please send us a mail. Regards, marcelo From bob.briscoe@bt.com Thu Mar 8 02:53:35 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D18021F8670 for ; Thu, 8 Mar 2012 02:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.843 X-Spam-Level: X-Spam-Status: No, score=-2.843 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlY82dSfoyFh for ; Thu, 8 Mar 2012 02:53:34 -0800 (PST) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id 49EBF21F8680 for ; Thu, 8 Mar 2012 02:53:34 -0800 (PST) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 8 Mar 2012 10:53:29 +0000 Received: from rdw02134app71.domain1.systemhost.net (193.113.234.138) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 8 Mar 2012 10:53:32 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com (147.149.100.81) by rdw02134app71.domain1.systemhost.net (10.36.6.87) with Microsoft SMTP Server id 14.1.323.0; Thu, 8 Mar 2012 10:53:25 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1331204008834; Thu, 8 Mar 2012 10:53:28 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.153.82]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q28ArLGs016987 for ; Thu, 8 Mar 2012 10:53:23 GMT Message-ID: <201203081053.q28ArLGs016987@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 8 Mar 2012 10:51:35 +0000 To: ConEx IETF list From: Bob Briscoe MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Subject: [conex] PhD dissertation relevant to ConEx audit X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 10:53:35 -0000 Folks, I (at last) have permission to publish my PhD dissertation. Re-feedback: Freedom with Accountability for Causing Congestion in a Connectionless Internetwork It focused on what we now call the audit function in ConEx. Although it was based on the re-ECN protocol, I believe it is nearly all still relevant to the ConEx protocol. It's 256 pages so not for the faint-hearted. If you mainly interested in ConEx protocol desgn and audit, you only need to read ptIII (147pp) and it's double-spaced, so under 100 pages really! It includes a wide range of potential attacks on the integrity of the protocol, which shaped the design of the protocol and of the audit function (at the time we called it the 'dropper'). It gives pseudocode for two alternative audit functions to maintain the protocol's integrity, including rationale and evaluation. At least a couple of aspects have become dated: * I have a much simpler but still as effective algo to replace the downstream congestion monitoring algo in S.8.2.7. I shall publish that as soon as I can - available on request. * Mirja Kuehlewind has shown that the assumptions about TCP slow-start overshoot in S.7.7 were very over-optimistic You will notice it acknowledges many who contributed. I would like to repeat my thanks to them all. Cheers Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From sebastien.jobert@orange.com Thu Mar 8 16:51:18 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9D821F85A7 for ; Thu, 8 Mar 2012 16:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.971 X-Spam-Level: X-Spam-Status: No, score=-5.971 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfUD3u3eF4UC for ; Thu, 8 Mar 2012 16:51:13 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id DCECD21F85A5 for ; Thu, 8 Mar 2012 16:51:09 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DC9BE5D893F for ; Fri, 9 Mar 2012 01:51:08 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id D09F05D8937 for ; Fri, 9 Mar 2012 01:51:08 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 01:51:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCFD8E.B6FB6411" Date: Fri, 9 Mar 2012 01:51:08 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft "Pre-congestion notification in mobile networks" Thread-Index: Acz9jrbRNPBod6S3QWSO/G4dZZpM1Q== From: To: X-OriginalArrivalTime: 09 Mar 2012 00:51:08.0736 (UTC) FILETIME=[B72E7400:01CCFD8E] Cc: isabelle.hamchaoui@orange.com Subject: [conex] Draft "Pre-congestion notification in mobile networks" X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 00:51:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFD8E.B6FB6411 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 We have uploaded an Internet-Draft called "Pre-congestion notification = in mobile networks" - = http://www.ietf.org/id/draft-jobert-tsvwg-pre-congest-notif-mobile-00.pdf= =20 Abstract =20 Mobile networks may be divided into two main segments: the radio segment, and the wireline segment. This document highlights that the algorithms leading to pre-congestion notification (e.g. ECN marking) are usually significantly different for these two segments, and not defined or documented in general over the radio segment. It also explains that using ECN bits leads to having a unique signal for notifying a pre-congestion related to two separate segments with very different notification algorithms. Some consequences are questioned, as well as the potential benefits of being able to identify where the congestion comes from. This document finally discusses the possibility to take into account the radio conditions of the terminals when counting the volume of congestion over the radio segment. =20 It has been posted in TSVWG, but some aspects discussed in this draft = are related to discussions in CONEX, and might be of interest to the WG. We are interested by review and comments. =20 Thanks. =20 Best Regards, =20 S=E9bastien JOBERT Orange Expert, network synchronization and QoS in mobile networks Orange Labs, Networks & Carriers - France Telecom Orange sebastien.jobert@orange.com = =20 =20 =20 ------_=_NextPart_001_01CCFD8E.B6FB6411 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

We have uploaded an Internet-Draft called = “Pre-congestion notification in mobile networks” - http://www.ietf.org/id/draft-jobert-tsvwg-pre-congest-notif-mob= ile-00.pdf

 

Abstract

 

   Mobile networks may be divided into two main = segments: the radio

   segment, and the wireline segment. This document = highlights that the

   algorithms leading to pre-congestion notification = (e.g. ECN marking)

   are usually significantly different for these two = segments, and not

   defined or documented in general over the radio = segment. It also

   explains that using ECN bits leads to having a unique = signal for

   = notifying a pre-congestion related to two separate segments = with

   very = different notification algorithms. Some consequences = are

   = questioned, as well as the potential benefits of being able = to

   = identify where the congestion comes from. This document = finally

   = discusses the possibility to take into account the radio = conditions

   of the = terminals when counting the volume of congestion over = the

   radio = segment.

 

It has been posted in TSVWG, but some aspects discussed in = this draft are related to discussions in CONEX, and might be of interest = to the WG.

We are interested by review and = comments.

 

Thanks.

 

Best = Regards,

 

S=E9bastien = JOBERT
Orange = Expert, network synchronization and QoS in mobile = networks
Orange Labs, Networks & Carriers - France Telecom = Orange
sebastien.jobert@orange.com

 

 

------_=_NextPart_001_01CCFD8E.B6FB6411-- From stuart.venters@adtran.com Mon Mar 12 08:59:29 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85EF21E801E for ; Mon, 12 Mar 2012 08:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rnsELDBA2eH for ; Mon, 12 Mar 2012 08:59:27 -0700 (PDT) Received: from p02c12o147.mxlogic.net (p02c12o147.mxlogic.net [208.65.145.80]) by ietfa.amsl.com (Postfix) with ESMTP id 25DDB11E8075 for ; Mon, 12 Mar 2012 08:59:25 -0700 (PDT) Received: from unknown [76.164.174.83] (EHLO p02c12o147.mxlogic.net) by p02c12o147.mxlogic.net(mxl_mta-6.13.0-2) with ESMTP id e5d1e5f4.656e3940.86651.00-548.211849.p02c12o147.mxlogic.net (envelope-from ); Mon, 12 Mar 2012 09:59:26 -0600 (MDT) X-MXL-Hash: 4f5e1d5e5a616668-def9e2790c277100e49d98064afcd0182a9b4a18 Received: from unknown [76.164.174.83] by p02c12o147.mxlogic.net(mxl_mta-6.13.0-2) with SMTP id 55d1e5f4.0.86604.00-330.211674.p02c12o147.mxlogic.net (envelope-from ); Mon, 12 Mar 2012 09:59:19 -0600 (MDT) X-MXL-Hash: 4f5e1d57043402d1-d3852fdf4080375c001a214bdbbb75ec0efc1164 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc2.corp.adtran.com ([fe80::d50f:ceda:4e38:ebf0%15]) with mapi id 14.01.0339.001; Mon, 12 Mar 2012 10:59:40 -0500 From: STUART VENTERS To: "sebastien.jobert@orange.com" Thread-Topic: Draft "Pre-congestion notification in mobile networks" Thread-Index: Acz9jrbRNPBod6S3QWSO/G4dZZpM1QC2Qa8Q Date: Mon, 12 Mar 2012 15:59:40 +0000 Message-ID: <1220E2C537595D439C5D026E83751866220398FC@ex-mb1.corp.adtran.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.113.98] Content-Type: multipart/alternative; boundary="_000_1220E2C537595D439C5D026E83751866220398FCexmb1corpadtran_" MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.83] X-AnalysisOut: [v=1.0 c=1 a=ruWq0YzyRmIA:10 a=qZE7q64NgjsA:10 a=qZHQZMT3ap] X-AnalysisOut: [YA:10 a=BLceEmwcHowA:10 a=xqWC_Br6kY4A:10 a=5zDNsY1we+1mvV] X-AnalysisOut: [cp/5+1jQ==:17 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8 a=jO2692MM] X-AnalysisOut: [AAAA:8 a=_r_i8vQ192Ogds36LjUA:9 a=eCQlZ5lrrOeqQI8_LMUA:7 a] X-AnalysisOut: [=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 a=oAXR_kdF8uMA:10 a=cPi] X-AnalysisOut: [Qg-nXjNYA:10 a=qO5-93tIaei6J40F:21 a=Ny3ohJtp7xYIOw76:21 a] X-AnalysisOut: [=SSmOFEACAAAA:8 a=yMhMjlubAAAA:8 a=8AYmYBJub6LVdLqT1JIA:9 ] X-AnalysisOut: [a=VcQpiWaILO6tJEF1yMQA:7 a=gKO2Hq4RSVkA:10 a=_W_S_7VecoQA:] X-AnalysisOut: [10 a=gMsgoVrhTLqk6YWP:21 a=9nthCi0HMFfofmHi:21] Cc: "conex@ietf.org" Subject: Re: [conex] Draft "Pre-congestion notification in mobile networks" X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 15:59:30 -0000 --_000_1220E2C537595D439C5D026E83751866220398FCexmb1corpadtran_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sebastien, You bring up an interesting point about fairness in a wireless network. Since the radio path quality may be different from handset to handset, the amount of radio resources required to transport a given number of b= its may also be different. To be fair, should each handset get the same number of bits or the same num= ber of radio resources? (Or, more likely, as you suggest in section 6, a combination of the two.= ) This seems as much a marketing issue as a technical one, so I would expect = each carrier to want to be able to choose the cost function combining these= two factors. I agree with you that just counting the bytes is not enough. Cheers, Stuart ________________________________ From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of s= ebastien.jobert@orange.com Sent: Thursday, March 08, 2012 6:51 PM To: conex@ietf.org Cc: isabelle.hamchaoui@orange.com Subject: [conex] Draft "Pre-congestion notification in mobile networks" Hi all, We have uploaded an Internet-Draft called "Pre-congestion notification in m= obile networks" - http://www.ietf.org/id/draft-jobert-tsvwg-pre-congest-not= if-mobile-00.pdf Abstract Mobile networks may be divided into two main segments: the radio segment, and the wireline segment. This document highlights that the algorithms leading to pre-congestion notification (e.g. ECN marking) are usually significantly different for these two segments, and not defined or documented in general over the radio segment. It also explains that using ECN bits leads to having a unique signal for notifying a pre-congestion related to two separate segments with very different notification algorithms. Some consequences are questioned, as well as the potential benefits of being able to identify where the congestion comes from. This document finally discusses the possibility to take into account the radio conditions of the terminals when counting the volume of congestion over the radio segment. It has been posted in TSVWG, but some aspects discussed in this draft are r= elated to discussions in CONEX, and might be of interest to the WG. We are interested by review and comments. Thanks. Best Regards, S=E9bastien JOBERT Orange Expert, network synchronization and QoS in mobile networks Orange Labs, Networks & Carriers - France Telecom Orange sebastien.jobert@orange.com --_000_1220E2C537595D439C5D026E83751866220398FCexmb1corpadtran_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Sebastien,
 
You bring up an interesting point= about fairness in a wireless network.
 
Since the radio path quality may = be different from handset to handset,
    the amount of = radio resources required to transport a given number of bits may also be di= fferent.
 
To be fair, should each handset g= et the same number of bits or the same number of radio resources?
  (Or, more likely,  as= you suggest in section 6, a combination of the two.)
 
This seems as much a marketing is= sue as a technical one, so I would expect each carrier to want to be able t= o choose the cost function combining these two factors.  I agree with you that just counting the bytes is not e= nough.
 
 
Cheers,
 
Stuart
 
 
 
 
 
 

From: conex-bounces@ietf.org [mailt= o:conex-bounces@ietf.org] On Behalf Of sebastien.jobert@orange.com
Sent: Thursday, March 08, 2012 6:51 PM
To: conex@ietf.org
Cc: isabelle.hamchaoui@orange.com
Subject: [conex] Draft "Pre-congestion notification in mobile n= etworks"

Hi all,

 

We have uploaded an Internet-Dr= aft called “Pre-congestion notification in mobile networks” - http://www.ietf.org/id/draft-jobert-tsvwg-pre-congest-notif-mobile-00.pdf

 

Abstract

 

   Mobile networks may be divided into two= main segments: the radio

   segment, and the wireline segment. This= document highlights that the

   algorithms leading to pre-congestion no= tification (e.g. ECN marking)

   are usually significantly different for= these two segments, and not

   defined or documented in general over t= he radio segment. It also

   explains that using ECN bits leads to h= aving a unique signal for

   notifying a pre-congestion related to t= wo separate segments with

   very different notification algorithms.= Some consequences are

   questioned, as well as the potential be= nefits of being able to

   identify where the congestion comes fro= m. This document finally

   discusses the possibility to take into = account the radio conditions

   of the terminals when counting the volu= me of congestion over the

   radio segment.

 

It has been posted in TSVWG, bu= t some aspects discussed in this draft are related to discussions in CONEX,= and might be of interest to the WG.

We are interested by review and= comments.

 

Thanks.

 

Best Regards,=

 

S=E9bastien JOBERT
Orange Expert, network synchronization and QoS in mobile netw= orks
Orange Labs, Networks & Carriers - Fra= nce Telecom Orange
sebastien.jobert@orange.com

 

 

--_000_1220E2C537595D439C5D026E83751866220398FCexmb1corpadtran_-- From internet-drafts@ietf.org Mon Mar 12 10:44:37 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB8321F8978; Mon, 12 Mar 2012 10:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-N9zvGQiZJB; Mon, 12 Mar 2012 10:44:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7453A21F897F; Mon, 12 Mar 2012 10:44:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312174435.21170.89495.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 10:44:35 -0700 Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-tcp-modifications-01.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 17:44:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion Exposure Working Group of = the IETF. Title : TCP modifications for Congestion Exposure Author(s) : Mirja Kuehlewind Richard Scheffenegger Filename : draft-ietf-conex-tcp-modifications-01.txt Pages : 13 Date : 2012-03-12 Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by previous packets on the same flow. This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-conex-tcp-modifications-01.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-conex-tcp-modifications-01.txt From marcelo@it.uc3m.es Mon Mar 12 10:53:19 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639AC21F89CC for ; Mon, 12 Mar 2012 10:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.491 X-Spam-Level: X-Spam-Status: No, score=-106.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90CP+FORMDsc for ; Mon, 12 Mar 2012 10:53:18 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id AB85F11E8083 for ; Mon, 12 Mar 2012 10:53:18 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (152.31.18.95.dynamic.jazztel.es [95.18.31.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 32AB175ADFC for ; Mon, 12 Mar 2012 18:53:17 +0100 (CET) Message-ID: <4F5E380C.605@it.uc3m.es> Date: Mon, 12 Mar 2012 18:53:16 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: 'ConEx IETF list' Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18770.000 Subject: [conex] agenda requests for paris X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 17:53:19 -0000 So, we have only received one request for paris so far. Any other stuff to discuss? Please send them to us before wed, as we need to post the agenda. From sebastien.jobert@orange.com Mon Mar 12 16:16:23 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5066221E8133 for ; Mon, 12 Mar 2012 16:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.026 X-Spam-Level: X-Spam-Status: No, score=-6.026 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzdbN3aetpcp for ; Mon, 12 Mar 2012 16:16:20 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4098921E812C for ; Mon, 12 Mar 2012 16:16:20 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 723F7DE4003; Tue, 13 Mar 2012 00:17:49 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 5ECA9DE4002; Tue, 13 Mar 2012 00:17:49 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Mar 2012 00:16:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD00A6.211224D7" Date: Tue, 13 Mar 2012 00:16:16 +0100 Message-ID: In-Reply-To: <1220E2C537595D439C5D026E83751866220398FC@ex-mb1.corp.adtran.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft "Pre-congestion notification in mobile networks" Thread-Index: Acz9jrbRNPBod6S3QWSO/G4dZZpM1QC2Qa8QAA6dXvA= References: <1220E2C537595D439C5D026E83751866220398FC@ex-mb1.corp.adtran.com> From: To: X-OriginalArrivalTime: 12 Mar 2012 23:16:18.0762 (UTC) FILETIME=[215852A0:01CD00A6] Cc: conex@ietf.org Subject: Re: [conex] Draft "Pre-congestion notification in mobile networks" X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 23:16:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD00A6.211224D7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Stuart, =20 The definition of fairness in wireless networks is indeed not so = simple... In general, the trade-off between capacity and fairness is handled by = the algorithms developed in the radio schedulers. =20 >From the ConEx perspective, the key point that we wanted to highlight = was that it might be useful to blame more the users in bad radio = conditions in terms of congestion-volume counting when the network is = overloaded, since they use more radio resources for the same amount of = traffic to be carried. It would provide incentives to delay some = non-urgent data consumptions to periods when the radio conditions will = be better, or when the network will be less loaded. =20 And because the congestion-volume may be related to the ECN marking = algorithms, it seems also useful to further investigate how the ECN = marking is currently supported over the wireless segment. =20 Thanks. =20 Cheers, =20 S=E9bastien =20 De : STUART VENTERS [mailto:stuart.venters@adtran.com]=20 Envoy=E9 : lundi 12 mars 2012 17:00 =C0 : JOBERT Sebastien RD-CORE-LAN Cc : conex@ietf.org Objet : RE: Draft "Pre-congestion notification in mobile networks" =20 Sebastien, =20 You bring up an interesting point about fairness in a wireless network. =20 Since the radio path quality may be different from handset to handset, the amount of radio resources required to transport a given number = of bits may also be different. =20 To be fair, should each handset get the same number of bits or the same = number of radio resources? (Or, more likely, as you suggest in section 6, a combination of the = two.) =20 This seems as much a marketing issue as a technical one, so I would = expect each carrier to want to be able to choose the cost function = combining these two factors. I agree with you that just counting the = bytes is not enough. =20 =20 Cheers, =20 Stuart =20 =20 =20 =20 =20 =20 =20 ________________________________ From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf = Of sebastien.jobert@orange.com Sent: Thursday, March 08, 2012 6:51 PM To: conex@ietf.org Cc: isabelle.hamchaoui@orange.com Subject: [conex] Draft "Pre-congestion notification in mobile networks" Hi all, =20 We have uploaded an Internet-Draft called "Pre-congestion notification = in mobile networks" - = http://www.ietf.org/id/draft-jobert-tsvwg-pre-congest-notif-mobile-00.pdf= =20 Abstract =20 Mobile networks may be divided into two main segments: the radio segment, and the wireline segment. This document highlights that the algorithms leading to pre-congestion notification (e.g. ECN marking) are usually significantly different for these two segments, and not defined or documented in general over the radio segment. It also explains that using ECN bits leads to having a unique signal for notifying a pre-congestion related to two separate segments with very different notification algorithms. Some consequences are questioned, as well as the potential benefits of being able to identify where the congestion comes from. This document finally discusses the possibility to take into account the radio conditions of the terminals when counting the volume of congestion over the radio segment. =20 It has been posted in TSVWG, but some aspects discussed in this draft = are related to discussions in CONEX, and might be of interest to the WG. We are interested by review and comments. =20 Thanks. =20 Best Regards, =20 S=E9bastien JOBERT Orange Expert, network synchronization and QoS in mobile networks Orange Labs, Networks & Carriers - France Telecom Orange sebastien.jobert@orange.com = =20 =20 =20 ------_=_NextPart_001_01CD00A6.211224D7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Stuart,

 

The = definition of fairness in wireless networks is indeed not so = simple…

In general, the trade-off between = capacity and fairness is handled by the algorithms developed in the = radio schedulers.

 

From the = ConEx perspective, the key point that we wanted to highlight was that it = might be useful to blame more the users in bad radio conditions in terms = of congestion-volume counting when the network is overloaded, since they = use more radio resources for the same amount of traffic to be carried. = It would provide incentives to delay some non-urgent data consumptions = to periods when the radio conditions will be better, or when the network = will be less loaded.

 

And because = the congestion-volume may be related to the ECN marking algorithms, it = seems also useful to further investigate how the ECN marking is = currently supported over the wireless segment.

 

Thanks.

 

Cheers,

 

S=E9bastien

 

De : STUART = VENTERS [mailto:stuart.venters@adtran.com]
Envoy=E9 : = lundi 12 mars 2012 17:00
=C0 : JOBERT Sebastien = RD-CORE-LAN
Cc : conex@ietf.org
Objet : = RE: Draft "Pre-congestion notification in mobile = networks"

 

Se= bastien,

 

Yo= u bring up an interesting point about fairness in a wireless = network.

 

Si= nce the radio path quality may be different from handset to = handset,

&n= bsp;   the amount of radio resources required to transport a = given number of bits may also be different.

 

To= be fair, should each handset get the same number of bits or the same = number of radio resources?

&n= bsp; (Or, more likely,  as you suggest in section 6, a combination = of the two.)

 

Th= is seems as much a marketing issue as a technical one, so I would expect = each carrier to want to be able to choose the cost function = combining these two factors.  I agree with you that just = counting the bytes is not enough.

 

 

Ch= eers,

 

St= uart

 

 

 

 

 

 

 

From:= = conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of = sebastien.jobert@orange.com
Sent: Thursday, March 08, 2012 = 6:51 PM
To: conex@ietf.org
Cc: = isabelle.hamchaoui@orange.com
Subject: [conex] Draft = "Pre-congestion notification in mobile networks"

Hi all,

 

We have uploaded an Internet-Draft called = “Pre-congestion notification in mobile networks” - http://www.ietf.org/id/draft-jobert-tsvwg-pre-congest-notif-mob= ile-00.pdf

 

Abstract

 

   Mobile networks may be divided into two main = segments: the radio

   segment, and the wireline segment. This document = highlights that the

   algorithms leading to pre-congestion notification = (e.g. ECN marking)

   are usually significantly different for these two = segments, and not

   defined or documented in general over the radio = segment. It also

   explains that using ECN bits leads to having a unique = signal for

   = notifying a pre-congestion related to two separate segments = with

   very = different notification algorithms. Some consequences = are

   = questioned, as well as the potential benefits of being able = to

   = identify where the congestion comes from. This document = finally

   = discusses the possibility to take into account the radio = conditions

   of the = terminals when counting the volume of congestion over = the

   radio = segment.

 

It has been posted in TSVWG, but some aspects discussed in = this draft are related to discussions in CONEX, and might be of interest = to the WG.

We are interested by review and = comments.

 

Thanks.

 

Best = Regards,

 

S=E9bastien = JOBERT
Orange = Expert, network synchronization and QoS in mobile = networks
Orange Labs, Networks & Carriers - France Telecom = Orange
sebastien.jobert@orange.com

 

 

------_=_NextPart_001_01CD00A6.211224D7-- From internet-drafts@ietf.org Mon Mar 12 16:33:21 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E1321E8201; Mon, 12 Mar 2012 16:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5rl45pE9dSd; Mon, 12 Mar 2012 16:33:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7745421E81FB; Mon, 12 Mar 2012 16:33:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312233320.21886.79857.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 16:33:20 -0700 Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-abstract-mech-04.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 23:33:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion Exposure Working Group of = the IETF. Title : Congestion Exposure (ConEx) Concepts and Abstract Mechan= ism Author(s) : Matt Mathis Bob Briscoe Filename : draft-ietf-conex-abstract-mech-04.txt Pages : 27 Date : 2012-03-12 This document describes an abstract mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. Today, network elements at any layer may signal congestion to the receiver by dropping packets or by ECN markings, and the receiver passes this information back to the sender in transport-layer feedback. The mechanism described here enables the sender to also relay this congestion information back into the network in-band at the IP layer, such that the total amount of congestion from all elements on the path is revealed to all IP elements along the path, where it could, for example, be used to provide input to traffic management. This mechanism is called congestion exposure or ConEx. The companion document "ConEx Concepts and Use Cases" provides the entry-point to the set of ConEx documentation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-conex-abstract-mech-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-conex-abstract-mech-04.txt From internet-drafts@ietf.org Mon Mar 12 16:59:24 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19EDD21E8075; Mon, 12 Mar 2012 16:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqNqzkMIMW4W; Mon, 12 Mar 2012 16:59:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F7021E80A6; Mon, 12 Mar 2012 16:59:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312235923.3567.47950.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 16:59:23 -0700 Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-destopt-02.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 23:59:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion Exposure Working Group of = the IETF. Title : IPv6 Destination Option for Conex Author(s) : Suresh Krishnan Mirja Kuehlewind Carlos Ralli Ucendo Filename : draft-ietf-conex-destopt-02.txt Pages : 8 Date : 2012-03-12 Conex is a mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. This document specifies an IPv6 destination option that is capable of carrying conex markings in IPv6 datagrams. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-conex-destopt-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-conex-destopt-02.txt From nanditad@google.com Thu Mar 15 10:14:51 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46DA421F869A for ; Thu, 15 Mar 2012 10:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjBaf3G9DSPv for ; Thu, 15 Mar 2012 10:14:50 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7910921F87B8 for ; Thu, 15 Mar 2012 10:14:50 -0700 (PDT) Received: by yenm5 with SMTP id m5so3746499yen.31 for ; Thu, 15 Mar 2012 10:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record; bh=qvRKZyIfPMQ1Hw+TVNHBdFq7dprq85ogJuFolV2A3hE=; b=C3x/UM/fdF6awnY/thQvSTqEeZevBTFWTOCnmAf/m2HIEIeWX88ChMRC1/6LEng571 IWk6UNvLvDW//V6mqJfBBxic283JlXK0qNqCP854hmbiZ2YYlUll9745kmD8o01H/Nyl F5wID7J3+s2cNBYzvn2C6ac5VxepVB7p4om8kyJwQit5vt2EuAdg3BBnd4IMjhe29CuD ELITaqKHbtuqfASAbrbN+181uTJemNAEs/Ex08yzs+RRZupGZXv6AQxotUYtoR7tmiwj ltgWMn5Toc0tdAheosm7HZt8MESTTotKSIIT+i9foSL5sHkSKh/Eee6U15ns3VstmG0P OMAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record:x-gm-message-state; bh=qvRKZyIfPMQ1Hw+TVNHBdFq7dprq85ogJuFolV2A3hE=; b=Tw0XaZfWs+xDdZTNoGAZdttvGzgLNoWrEXQ96cMJGuth7xhSETLBdSkY8dKyBMpCmj 8ebUB9BXgy6N9yLVH0OTiTGjqHfcSdv8OnhoB9aljgghM+oRskxP0KYyxBLMWyOmGN8F E0Ii5MyAgEgbCl1nk6/Fxxg/s3eN/vP+71kNG6sRrEt3y0aqYz96dI2QUZTP4miQ2CUk ZrHI7DqRxVy6Ly0dBU/vUGKDYU85aRW6VLniO3Oap7Ai7kejEVZzhggdK1I8ai/YGqT3 PR/6Za0SOGQ2msWZwDDF3OrQnJ9Fo8JXGxkQxG3mHS5KjkdJiWNtcOR/rvqgkw6m2FbP ncog== Received: by 10.182.159.65 with SMTP id xa1mr9025144obb.25.1331831681615; Thu, 15 Mar 2012 10:14:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.159.65 with SMTP id xa1mr9025138obb.25.1331831681522; Thu, 15 Mar 2012 10:14:41 -0700 (PDT) Received: by 10.182.101.231 with HTTP; Thu, 15 Mar 2012 10:14:41 -0700 (PDT) Date: Thu, 15 Mar 2012 10:14:41 -0700 Message-ID: From: Nandita Dukkipati To: conex@ietf.org Content-Type: multipart/alternative; boundary=14dae9399b91471c2d04bb4b3ac9 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlcZ2zD8TWuyJhDVEw0GT3NTzfxCm/lOi60uadD69IfCOXvtumE7crqxRP/MuE9hquDQJOiNncorWteYdGlwyYNbHEb3dcYckQyt98KvSuoOV/xVsdhyTrrlhh7lRCm73SQVaFl Subject: [conex] Agenda for IETF-83 Conex X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 17:14:51 -0000 --14dae9399b91471c2d04bb4b3ac9 Content-Type: text/plain; charset=ISO-8859-1 Please find the agenda at: http://tools.ietf.org/wg/conex/agenda?item=agenda-83-conex.html Let us know if we missed anything or you would like to add something. We have some room for changes. Nandita --14dae9399b91471c2d04bb4b3ac9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please find the agenda at:=A0http://tools.ietf.org/wg/conex/agenda?item= =3Dagenda-83-conex.html

Let us know if we missed any= thing or you would like to add something. We have some room for changes.

Nandita
--14dae9399b91471c2d04bb4b3ac9-- From nanditad@google.com Wed Mar 28 05:07:33 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D7121F8658 for ; Wed, 28 Mar 2012 05:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-b9NeGiDEWq for ; Wed, 28 Mar 2012 05:07:32 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5333821F85ED for ; Wed, 28 Mar 2012 05:07:25 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1489686obb.31 for ; Wed, 28 Mar 2012 05:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-system-of-record; bh=9X6hJ2gPyjt+LMalPzyq/10Gm1JC7XxAAWzrJ9cObCQ=; b=R/Qy+fyDm4gMiNF2qT80DpyVM0qRQ7EeRyh8TwXfa6wX3sKJ0IPHHI/4WHqMwDRrTi ikwju6JctxjpvnPxBqwrtevl2UFBG7nryzv/11TIFr4biGj7ftd4OQEH1kDfFLqKOvdg s/Ea01gjZWrfLzYtB2igTh9Ha/iulSJh2r1fYTz5GqBqRtNtcv9GnUKlykoUYIZIm5hg fq97uteEe8d8KZu75skrwUaNc9ZKgv+ddfeuGuXnNP1fCYaGGiAS9liuz7j4H8857/Ag KYo1L8IyWj2SxXZ0fXazVYFnMdOWoYCCOdn7DKn3LuvtIQItvPWhN/Nxf6Z20D56R9mi 63Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=9X6hJ2gPyjt+LMalPzyq/10Gm1JC7XxAAWzrJ9cObCQ=; b=GojUMbWj33Vz3r+kd+ooVvLFVJPwUhxA20gEP9AXx5zalImeWdYIx2G79jB3+9yZXL xaUap1Dgcyp/sZNj35RG9edk1e5i0Zztj1/TSoc/rjym/TVvLvmfIXQlR/g8n0434wrW LClC/cnJlN6SDMgZ4mEbzCiJ0YCHFZXK3JxiyPzBm5T3DrAPdzPsd2Mi2ZeHQKjHDWQ3 1tuWC3SsfGwZOxtUCeI7ICdNR183tx3Zxv1Y4yGy5lNUrWXKZcxImlsat8lP5Oka/Wvq HVHFc5AL7NKTQkuiIbMr/00Bdqay3MdyTt94Tfj1JH/ZhyPsN6ur8G8jlorOQz+VDMXj cNcg== Received: by 10.182.202.69 with SMTP id kg5mr38162930obc.35.1332936444770; Wed, 28 Mar 2012 05:07:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.202.69 with SMTP id kg5mr38162912obc.35.1332936444653; Wed, 28 Mar 2012 05:07:24 -0700 (PDT) Received: by 10.182.69.164 with HTTP; Wed, 28 Mar 2012 05:07:24 -0700 (PDT) Date: Wed, 28 Mar 2012 14:07:24 +0200 Message-ID: From: Nandita Dukkipati To: =?ISO-8859-1?Q?Mirja_K=FChlewind?= , "Scheffenegger, Richard" Content-Type: multipart/alternative; boundary=e89a8f6438c24ab0d404bc4c7375 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnZ/68wh7QoBuyjADnApjilorGahLUuNsj0MplcNUh9Rz5HN1T3KTTPbFx+7Xg1OAk4ai664JlmV8FCtmx8256k1GezP7ojIh2clFtu/A/1+kBlxddHdz6P8isRBOww7679Bhie Cc: conex@ietf.org Subject: [conex] Comments on ConEx TCP Modifications X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 12:07:33 -0000 --e89a8f6438c24ab0d404bc4c7375 Content-Type: text/plain; charset=ISO-8859-1 Following are a comments as individual contributor on http://www.ietf.org/id/draft-ietf-conex-tcp-modifications-01.txt and one comment as chair. Nandita 1. What changes, if any, are required to accounting when ConEx marked packets get lost? 2. Sec 3 "A sender which sends different sized packets with unequally distributed packet sizes should know about reason to do so and thus may be able to reconstruct the exact number of headers based on this information." Sentence doesn't read well; please reword. 3. Sections 3.1.1 and 3.1.2 By acked_bytes I assume you mean the cumulatively acked bytes or the change in snd.una. What happens when there is loss and snd.una does not advance? Instead, I suggest that you consider using DeliveredData as defined in http://datatracker.ietf.org/doc/draft-ietf-tcpm-proportional-rate-reduction/?include_text=1 - it tracks precisely that amount of data delivered to the receiver for each ACK even in the loss case. 4. Section 3.1.2 "Unfortunately, in a high congestion situation where all packets are CE marled..." marled -> marked 5. Section 3.1.2 On the use of 'M' You won't require to use any variable 'M' when you track precisely the bytes delivered per ACK using the DeliveredData that I mentioned above. 6. Sec 3.1.2 "In average the sender will sent..." -> "On average the sender will send..." 7. Advanced Compatibility mode Not clear to me at all what this text is trying to say. 8. Sec 3.2 "Note that the above heuristics delays the ConEx signal by one segment, and also..." You mean delay by 1 RTT? Comment as chair Section 3 Accounting Congestion bytes vs. packets: I would like to see consistency across the two drafts (abstract mechanism, TCP modifications) on the issue of whether ConEx marking and accounting should be in bytes or in packets. What are the pros/cons and corner cases for each? What is the final recommendation that you make? Which of these drafts should make this recommendation - I would think it's the TCP modifications draft. If you haven't already, could you please read up the latest Concepts and Abstract Mechanism draft and communicate with the authors of that document and make sure we have consistency on bytes vs. packets across the two I-Ds. --e89a8f6438c24ab0d404bc4c7375 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Following are a comments as individual contributor on=A0http://www.ietf.org/id/draft-ietf-conex-tcp-modifications-01.txt=A0and= one comment as chair.

Nandita

1. What changes, if any, are = required to accounting when ConEx marked packets get lost?

2. Sec 3
"A sender which sends different= sized packets with unequally distributed packet sizes should know about re= ason to do so and thus may be able to reconstruct the exact number of heade= rs based on this information."
Sentence doesn't read well; please reword.

3. Sections 3.1.1 and 3.1.2
By acked_bytes I assume you mean th= e cumulatively acked bytes or the change in snd.una. What happens when ther= e is loss and snd.una does not advance? Instead, I suggest that you conside= r using DeliveredData as defined in=A0http:/= /datatracker.ietf.org/doc/draft-ietf-tcpm-proportional-rate-reduction/?incl= ude_text=3D1=A0- it tracks precisely that amount of data delivered to t= he receiver for each ACK even in the loss case.

4. Section 3.1.2
"Unfortunately, in a hi= gh congestion situation where all packets are CE marled..."
= marled -> marked

5. Section 3.1.2 =A0
On the use of 'M'
You won't require to use any variab= le 'M' when you track precisely the bytes delivered per ACK using t= he DeliveredData that I mentioned above.

6. Sec 3.= 1.2
"In average the sender will sent..." -> "On average = the sender will send..."

7. Advanced Compatib= ility mode
Not clear to me at all what this text is trying to say= .

8. Sec 3.2
"Note that the above heuristi= cs delays the ConEx signal by one segment, and also..."
You = mean delay by 1 RTT?

Comment as chair

Section 3 Accounting Congestion
bytes vs. packets:= I would like to see consistency across the two drafts (abstract mechanism,= TCP modifications) on the issue of whether ConEx marking and accounting sh= ould be in bytes or in packets. What are the pros/cons and corner cases for= each? What is the final recommendation that you make? Which of these draft= s should make this recommendation - I would think it's the TCP modifica= tions draft.=A0

If you haven't already, could you=A0please read up = the latest Concepts and Abstract Mechanism draft and communicate with the a= uthors of that document and make sure we have consistency on bytes vs. pack= ets across the two I-Ds.
--e89a8f6438c24ab0d404bc4c7375-- From nanditad@google.com Wed Mar 28 18:20:13 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9485821E8036 for ; Wed, 28 Mar 2012 18:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.826 X-Spam-Level: X-Spam-Status: No, score=-102.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-rP0vn6K9b8 for ; Wed, 28 Mar 2012 18:20:12 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED6421E800F for ; Wed, 28 Mar 2012 18:20:11 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so2425069obb.31 for ; Wed, 28 Mar 2012 18:20:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-system-of-record; bh=W7Vqze7bVHn7nbn5xp/qGQbS8JeQjl7GeDAV5XBZiwk=; b=HXCeB3VgpkKEZgPhGdzPXHVQaQ3oGq2KSSbVUB44wWzojGPAnKdYyVt5o2Q07vS8ey 47VIGzjf8uAODQyLKNRYxvX4ZMZpwHhNQULCmRIeeWfZLQO3mYjZOFd0O+ur+/oK4vVj OzA/SVRiOmsVmqfDP7WY4XFAwPL8litnYl79+MzBh6xNrb/DZtRno4VrMCn/mV2Rtul5 T6gA+7tHpThVhlsdgjf6dm/lLCjvM33i4jng8mo+nNtrdrhYFhNtZTgEO63ETnB8em7C 59f4MgXwjjGJ7fbyeDltKTvZCpIlVGN52F4tuW3NQVTTKuLRv7e8i2cgKyUVqT0yRCgD OxCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=W7Vqze7bVHn7nbn5xp/qGQbS8JeQjl7GeDAV5XBZiwk=; b=KNdMx6073X25MkDgwhsgvllaeVD9hmLKmhU59fbECg+oftizuB77kcEDQ6qyS1X7tO J7ejwbefiMKH5MJhps3hZKaRIXaLnAcuOSsqvgRc7BXJ2655PMvzvspSPQYRQ7kOSQGq f0eOWgwD6/8Pd5brJ1/OlGZJbwLnGn9uk23lhvazmfINzqciuzjjM+SNGiV7mUB2O9oO nwvExXTUrYCT7EtObiFF/i5w2LUU+1i+mIcGjZdVGL31LW15GFFCKLhf27baQdxDsL+l hVtKZbrsMLgFpRuOG7rq88RIBMQA1JcAiMAkgXj3esGQ9jFR9DcBYJWNhYeu1l6S1gLx CVLg== Received: by 10.182.183.73 with SMTP id ek9mr31396325obc.15.1332984011303; Wed, 28 Mar 2012 18:20:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.183.73 with SMTP id ek9mr31396313obc.15.1332984011169; Wed, 28 Mar 2012 18:20:11 -0700 (PDT) Received: by 10.182.69.164 with HTTP; Wed, 28 Mar 2012 18:20:11 -0700 (PDT) Date: Thu, 29 Mar 2012 03:20:11 +0200 Message-ID: From: Nandita Dukkipati To: Dirk Kutscher , Suresh Krishnan Content-Type: multipart/alternative; boundary=f46d04478a317a1f2004bc578609 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkiu8LXsh4tTuG+nSoolmrKktZbv7DT1MqIz3w65S4xKqSmmskx3bf98YAtOvSRbF82XAfSMNDbmEB0hD71SkGUHiWuLPSIzn4jC7HW6OqBKcBBlQ/Rcxxil9j5zPugrjFCg95B Cc: conex@ietf.org Subject: [conex] Comments on draft-kutscher-conex-mobile-03.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 01:20:13 -0000 --f46d04478a317a1f2004bc578609 Content-Type: text/plain; charset=ISO-8859-1 Following are my first parse of comments/questions on draft-kutscher-conex-mobile-03.txt (as individual contributor). Please fwd to your co-authors - I do not have their emails right now. Nandita ------------- 1. First of, this is a nice draft elucidating the use of ConEx in mobile scenarios. At a high level, my take is that the draft expands upon the use scenarios presented in ConEx Concepts and Uses, but putting it in the context of mobile networks. Mobile networks are an apt example for ConEx usage given their limited bandwidth and the fact that they already perform some sort of detailed per-use volume accounting. As you mention, hopefully adding congestion based accounting can be built upon it. 2. Sec 3.4 ConEx as a Form of Differential QoS I don't get this para at all. Please consider rewording. 3. A high level question: do you have any data on loss rates (exposed to TCP) in mobile (cellular) networks? Is it true that link layer protocols perform aggressive retransmissions to mask losses from higher layers such as TCP - and if so, what does this property mean in the context of ConEx. If very little loss is exposed to higher layers, how will the end systems give ConEx feedback to the network? A discussion on those lines would be great in this draft. 4. Finally, the draft is filled with many 3GPP acronyms of which I know very little - but I guess you can't do anything about that :-) --f46d04478a317a1f2004bc578609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Following are my first parse of comments/questions on=A0draft-kutscher-cone= x-mobile-03.txt (as individual contributor). Please fwd to your co-authors = - I do not have their emails right now.

Nandita
-------------

1. First of, this is a nice draft eluc= idating the use of ConEx in mobile scenarios. At a high level, my take is t= hat the draft expands upon the use scenarios presented in ConEx Concepts an= d Uses, but putting it in the context of mobile networks.

Mobile networks are an apt example for ConEx usage give= n their limited bandwidth and the fact that they already perform some sort = of detailed per-use volume accounting. As you mention, hopefully adding con= gestion based accounting can be built upon it.

2. Sec 3.4 ConEx as a Form of Differential QoS
I don't get this para at all. Please consider rewording.
3. A high level question: do you have any data on loss rates (= exposed to TCP) in mobile (cellular) networks?=A0

Is it true that link layer protocols perform aggressive= retransmissions to mask losses from higher layers such as TCP - and if so,= what does this property mean in the context of ConEx. If very little loss = is exposed to higher layers, how will the end systems give ConEx feedback t= o the network?

A discussion on those lines would be great in this draf= t.=A0

4. Finally, the draft is filled with many 3G= PP acronyms of which I know very little - but I guess you can't do anyt= hing about that :-)


--f46d04478a317a1f2004bc578609-- From bob.briscoe@bt.com Thu Mar 29 01:49:20 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E47C21F8864 for ; Thu, 29 Mar 2012 01:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.163 X-Spam-Level: X-Spam-Status: No, score=-3.163 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ah3wh-QFTRWC for ; Thu, 29 Mar 2012 01:49:19 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 8534421F881D for ; Thu, 29 Mar 2012 01:49:19 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 29 Mar 2012 09:49:17 +0100 Received: from rdw02134app71.domain1.systemhost.net (193.113.234.138) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 29 Mar 2012 09:49:15 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com (147.149.100.81) by rdw02134app71.domain1.systemhost.net (10.36.6.87) with Microsoft SMTP Server id 14.2.247.3; Thu, 29 Mar 2012 09:49:15 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1333010964625; Thu, 29 Mar 2012 09:49:24 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.163.15]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q2T8nBvn031553; Thu, 29 Mar 2012 09:49:11 +0100 Message-ID: <201203290849.q2T8nBvn031553@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 29 Mar 2012 09:49:13 +0100 To: Nandita Dukkipati From: Bob Briscoe In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: conex@ietf.org Subject: Re: [conex] Comments on draft-kutscher-conex-mobile-03.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 08:49:20 -0000 Nandita, At 02:20 29/03/2012, Nandita Dukkipati wrote: >4. Finally, the draft is filled with many 3GPP acronyms of which I >know very little - but I guess you can't do anything about that :-) Given the intended audience is 3GPP types, I guess this is fine. In a previous review, I think I caught all the abbrevs that weren't explained. I think they have all been fixed now. Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Thu Mar 29 02:14:41 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E250321F8A1B for ; Thu, 29 Mar 2012 02:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.674 X-Spam-Level: X-Spam-Status: No, score=-2.674 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDc7Z+EZYzv9 for ; Thu, 29 Mar 2012 02:14:41 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id 588F321F8A1A for ; Thu, 29 Mar 2012 02:14:40 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 29 Mar 2012 10:14:37 +0100 Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 29 Mar 2012 10:14:37 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.2.247.3; Thu, 29 Mar 2012 10:14:30 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 133301248276; Thu, 29 Mar 2012 10:14:42 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.163.15]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q2T9ERBT031709; Thu, 29 Mar 2012 10:14:27 +0100 Message-ID: <201203290914.q2T9ERBT031709@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 29 Mar 2012 10:14:30 +0100 To: "Eddy Wesley M. [VZ]" , ConEx IETF list From: Bob Briscoe MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Subject: [conex] IPR on ConEx mechanisms X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:14:42 -0000 Wes as responsible AD, ConEx chairs & list, A request to publish draft-ietf-conex-concepts-uses is currently being passed to the IESG. It says that no relevant IPR declaration is known to exist. In the interests of full disclosure, the re-ECN protocol can be thought of as a precursor to ConEx and BT declared its IPR relevant to re-ECN here: It is very likely that at least some of the BT patents identified in that BT declaration are also relevant to ConEx. BT is in the process of reviewing its patent portfolio so that it might re-issue the above IPR declaration. Any re-issue will point both to specifications of re-ECN and to specifications of ConEx mechanisms as well as identifying any additional BT patents. Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From Dirk.Kutscher@neclab.eu Thu Mar 29 03:58:16 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053B721F88AA for ; Thu, 29 Mar 2012 03:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fef4S91utFA7 for ; Thu, 29 Mar 2012 03:58:14 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4482821F8872 for ; Thu, 29 Mar 2012 03:58:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id F08B31006E0; Thu, 29 Mar 2012 12:58:48 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUURvtLcpRWV; Thu, 29 Mar 2012 12:58:48 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id D1B391006DA; Thu, 29 Mar 2012 12:58:33 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.36]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 29 Mar 2012 12:57:36 +0200 From: Dirk Kutscher To: Nandita Dukkipati , Dirk Kutscher , Suresh Krishnan Thread-Topic: Comments on draft-kutscher-conex-mobile-03.txt Thread-Index: AQHNDUoa3MWWB5/x80iUu5pDsc2fMpaBB3xw Date: Thu, 29 Mar 2012 10:57:38 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F524924C633FE@Polydeuces.office.hd> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.204] Content-Type: multipart/alternative; boundary="_000_82AB329A76E2484D934BBCA77E9F524924C633FEPolydeucesoffic_" MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] Comments on draft-kutscher-conex-mobile-03.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 10:58:16 -0000 --_000_82AB329A76E2484D934BBCA77E9F524924C633FEPolydeucesoffic_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks a lot for the feedback, Nandita. Regarding section 3.4, I agree that this can be explained better. The main = message was that CONEX might be used to provide a more dynamic, more flexib= le form of QoS compared to the existing static bearer class selection. Regarding loss rates, best effort traffic would get 10^-6 or better (per st= andard at least). That's for the wireless link. For CONEX, I think we would be interested in end-to-end (at least terminal-= to-gateway) loss rates. Such data is normally not easy to obtain, but you c= an expect significantly higher loss rates there (caused by congestion). I think it's a good idea to include more discussion on this. Regarding the acronyms, yes there are many. As Bob mentioned, we think that= we have at least spelled out most of them now - it's possible that some tr= anslation to Internet terms can be useful - we will consider that. Cheers, Dirk From: Nandita Dukkipati [mailto:nanditad@google.com] Sent: Donnerstag, 29. M=E4rz 2012 03:20 To: Dirk Kutscher; Suresh Krishnan Cc: conex@ietf.org Subject: Comments on draft-kutscher-conex-mobile-03.txt Following are my first parse of comments/questions on draft-kutscher-conex-= mobile-03.txt (as individual contributor). Please fwd to your co-authors - = I do not have their emails right now. Nandita ------------- 1. First of, this is a nice draft elucidating the use of ConEx in mobile sc= enarios. At a high level, my take is that the draft expands upon the use sc= enarios presented in ConEx Concepts and Uses, but putting it in the context= of mobile networks. Mobile networks are an apt example for ConEx usage given their limited band= width and the fact that they already perform some sort of detailed per-use = volume accounting. As you mention, hopefully adding congestion based accoun= ting can be built upon it. 2. Sec 3.4 ConEx as a Form of Differential QoS I don't get this para at all. Please consider rewording. 3. A high level question: do you have any data on loss rates (exposed to TC= P) in mobile (cellular) networks? Is it true that link layer protocols perform aggressive retransmissions to = mask losses from higher layers such as TCP - and if so, what does this prop= erty mean in the context of ConEx. If very little loss is exposed to higher= layers, how will the end systems give ConEx feedback to the network? A discussion on those lines would be great in this draft. 4. Finally, the draft is filled with many 3GPP acronyms of which I know ver= y little - but I guess you can't do anything about that :-) --_000_82AB329A76E2484D934BBCA77E9F524924C633FEPolydeucesoffic_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks a lot for the feed= back, Nandita.

 <= /p>

Regarding section 3.4, I = agree that this can be explained better. The main message was that CONEX mi= ght be used to provide a more dynamic, more flexible form of QoS compared to the existing static bearer class selection.<= /span>

 <= /p>

Regarding loss rates, bes= t effort traffic would get 10^-6 or better (per standard at least). That= 217;s for the wireless link.

 <= /p>

For CONEX, I think we wou= ld be interested in end-to-end (at least terminal-to-gateway) loss rates. S= uch data is normally not easy to obtain, but you can expect significantly higher loss rates there (caused by congestion).

 <= /p>

I think it’s a good= idea to include more discussion on this.

 <= /p>

Regarding the acronyms, y= es there are many. As Bob mentioned, we think that we have at least spelled= out most of them now – it’s possible that some translation to Internet terms can be useful – we will consider that.<= /span>

 <= /p>

Cheers,=

Dirk

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: Nandita = Dukkipati [mailto:nanditad@google.com]
Sent: Donnerstag, 29. M=E4rz 2012 03:20
To: Dirk Kutscher; Suresh Krishnan
Cc: conex@ietf.org
Subject: Comments on draft-kutscher-conex-mobile-03.txt

 

Following are my first parse of comments/questions o= n draft-kutscher-conex-mobile-03.txt (as individual contributor). Plea= se fwd to your co-authors - I do not have their emails right now.

 

Nandita

-------------

 

1. First of, this is a nice draft elucidating the us= e of ConEx in mobile scenarios. At a high level, my take is that the draft = expands upon the use scenarios presented in ConEx Concepts and Uses, but pu= tting it in the context of mobile networks.

 

Mobile networks are an apt example for ConEx usage g= iven their limited bandwidth and the fact that they already perform some so= rt of detailed per-use volume accounting. As you mention, hopefully adding = congestion based accounting can be built upon it.

 

2. Sec 3.4 ConEx as a Form of Differential QoS<= /o:p>

I don't get this para at all. Please consider reword= ing.

 

3. A high level question: do you have any data on lo= ss rates (exposed to TCP) in mobile (cellular) networks? 

 

Is it true that link layer protocols perform aggress= ive retransmissions to mask losses from higher layers such as TCP - and if = so, what does this property mean in the context of ConEx. If very little lo= ss is exposed to higher layers, how will the end systems give ConEx feedback to the network?

 

A discussion on those lines would be great in this d= raft. 

 

4. Finally, the draft is filled with many 3GPP acron= yms of which I know very little - but I guess you can't do anything about t= hat :-)

 

 

--_000_82AB329A76E2484D934BBCA77E9F524924C633FEPolydeucesoffic_-- From nanditad@google.com Thu Mar 29 05:16:14 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7A221F8A79 for ; Thu, 29 Mar 2012 05:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.864 X-Spam-Level: X-Spam-Status: No, score=-102.864 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lgq1qwvTDXDr for ; Thu, 29 Mar 2012 05:16:13 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC9D21F8A8A for ; Thu, 29 Mar 2012 05:16:11 -0700 (PDT) Received: by obbta17 with SMTP id ta17so558350obb.31 for ; Thu, 29 Mar 2012 05:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record; bh=96SRqb1IRUaSt1pzYpsYsilnVtQ6yE1iOtT4K9OaYBk=; b=CBezV2+cXfr/0MSCI+2lTQ6t4AFW729tjiQaq8E60H5mwisB91jaUsBGJ+ymc4HUSz 2ZH+LELWQJEJnUpBxbbpQfcqeEvsasm63rJxj43+kE54LWI2yRfnUDv9Y8JfhhwHhjPo FFhEIsVww2GsELPcA3prgLhoWC2TZoQ2xNvW7fRUZmxU9AneCF4GDMIVecuu9bxKXNhJ gaod+Vg+f/VgIVUt9MqCujcMLa9hBX4DTSvt10wowY3djQT0TIKI1qy+CLWgJcbNMwAd 009Bnh/rbmLhHdWEGxL2zeJH7kVcb5ifuYdr6LloxizMBjzMkrShq2qV1pI++UTEW0Q1 vhzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record:x-gm-message-state; bh=96SRqb1IRUaSt1pzYpsYsilnVtQ6yE1iOtT4K9OaYBk=; b=L1KQyBZ1roENjSrrgCny31ckuT+QCgwHMDyo0Lvt/Ak9w3DC0r/NXK7G1BVhiweNuc n8WpnxbHEWVwrmTzis4LZUinDVwDLZPLBQd2Hty4M4Oq7N/fBrE4mAuBJi90ha/yUW5v NNEJRmjmL/Mj1POLtNGEL5tob/r/ZDxaMpIj3YawLX05Aq4gQGQO7NU5A2mhuFRn298w fpp1sQ6UplJcg+bQaT8Z1tXtmW13TqyDZzLB2ZhYSnpueGPSlbfW89yD2wbuhmA+SbuZ En1VA1ydqCD4MyWf51hNTqyg4DiTbt5YkzW1Oy3JnbigaZAE/HEW4fxXER5wf1njWQIb 9WZA== Received: by 10.182.202.69 with SMTP id kg5mr44035040obc.35.1333023369376; Thu, 29 Mar 2012 05:16:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.202.69 with SMTP id kg5mr44035018obc.35.1333023369165; Thu, 29 Mar 2012 05:16:09 -0700 (PDT) Received: by 10.182.69.164 with HTTP; Thu, 29 Mar 2012 05:16:09 -0700 (PDT) Date: Thu, 29 Mar 2012 14:16:09 +0200 Message-ID: From: Nandita Dukkipati To: conex@ietf.org Content-Type: multipart/alternative; boundary=e89a8f6438c2657c4904bc60b048 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmOql7L5XMr5A6FbHHEgaEHKmhAcBho/YiHU5UbCpRLJt+gZc99D4Vo9qhOif8OVEVZciDZuyk+kXggWTWfCaEfO0vGwu8wYAIO5X6X+zQ2xZAA3QBvW7h7JfjQrUIw6xysry3v Subject: [conex] call for note takers X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:16:14 -0000 --e89a8f6438c2657c4904bc60b048 Content-Type: text/plain; charset=ISO-8859-1 We require two people for taking meeting notes and doing jabber scribe for this evening's ConEx WG meeting. Any volunteers? Nandita --e89a8f6438c2657c4904bc60b048 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We require two people for taking meeting notes and doing jabber scribe for = this evening's ConEx WG meeting.=A0

Any volunteers?<= /div>

Nandita=A0
--e89a8f6438c2657c4904bc60b048-- From iesg-secretary@ietf.org Thu Mar 29 07:10:03 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA8821E809A; Thu, 29 Mar 2012 07:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZM7VV5LjyGs8; Thu, 29 Mar 2012 07:10:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB0221E809D; Thu, 29 Mar 2012 07:10:02 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120329141002.22903.96428.idtracker@ietfa.amsl.com> Date: Thu, 29 Mar 2012 07:10:02 -0700 Cc: conex@ietf.org Subject: [conex] Last Call: (ConEx Concepts and Use Cases) to Informational RFC X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:10:03 -0000 The IESG has received a request from the Congestion Exposure WG (conex) to consider the following document: - 'ConEx Concepts and Use Cases' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-04-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides the entry point to the set of documentation about the Congestion Exposure (ConEx) protocol. It explains the motivation for including a ConEx marking at the IP layer: to expose information about congestion to network nodes. Although such information may have a number of uses, this document focuses on how the information communicated by the ConEx marking can serve as the basis for significantly more efficient and effective traffic management than what exists on the Internet today. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-conex-concepts-uses/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-conex-concepts-uses/ballot/ No IPR declarations have been submitted directly on this I-D. From christopher.morrow@gmail.com Thu Mar 29 09:11:35 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4EE21E8231; Thu, 29 Mar 2012 09:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.561 X-Spam-Level: X-Spam-Status: No, score=-103.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QH+awABvbAe; Thu, 29 Mar 2012 09:11:35 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E07BA21E8229; Thu, 29 Mar 2012 09:11:34 -0700 (PDT) Received: by obbta17 with SMTP id ta17so841090obb.31 for ; Thu, 29 Mar 2012 09:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2OsZJbLOAB3ydpvd7XWlvI+yciJvWhDtFjmz42SEc0A=; b=sVpy8Ldr8ne82exDSb633j22acWpz5KUx2via6SAZpnoIJ0KwUGLdgy25qbH5Zoc44 9qkZAQ4X3VJVYOSU05hNLu7IdxHwaZGOtEQ9ovX0BL+VWthk2Js/7DB/X7mLKDjykEei iH1SyRdF7lD9dIFF/u7og+h3Ec61FXRvGSIrDhgCrKH4bA/ykIw0+IW28OMG7TDEyQAP OZYAp8UgRER0xSlfwaVs5dOR60SJJJqFrfPX0Him4dMlAgeko7KBwdYqf+GSd/g4md4d 10ZGnS9fyfzPBF9QEFraZnPFR3fslXGQpeL4bOee5evICroBgAQuPiMwIDYi21ho15hg gSzA== MIME-Version: 1.0 Received: by 10.182.85.39 with SMTP id e7mr43807279obz.51.1333037494489; Thu, 29 Mar 2012 09:11:34 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Thu, 29 Mar 2012 09:11:34 -0700 (PDT) In-Reply-To: <20120329141002.22903.96428.idtracker@ietfa.amsl.com> References: <20120329141002.22903.96428.idtracker@ietfa.amsl.com> Date: Thu, 29 Mar 2012 12:11:34 -0400 X-Google-Sender-Auth: u1rScoPALWGBi6yogXzIAqA4EIE Message-ID: From: Christopher Morrow To: ietf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF-Announce , conex@ietf.org Subject: Re: [conex] Last Call: (ConEx Concepts and Use Cases) to Informational RFC X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 16:11:35 -0000 On Thu, Mar 29, 2012 at 10:10 AM, The IESG wrote: > > The IESG has received a request from the Congestion Exposure WG (conex) > to consider the following document: > - 'ConEx Concepts and Use Cases' > =A0 as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-04-12. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > =A0 This document provides the entry point to the set of documentation > =A0 about the Congestion Exposure (ConEx) protocol. =A0It explains the > =A0 motivation for including a ConEx marking at the IP layer: to expose > =A0 information about congestion to network nodes. =A0Although such > =A0 information may have a number of uses, this document focuses on how > =A0 the information communicated by the ConEx marking can serve as the > =A0 basis for significantly more efficient and effective traffic > =A0 management than what exists on the Internet today. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-conex-concepts-uses/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-conex-concepts-uses/ballot/ > > > No IPR declarations have been submitted directly on this I-D. Didn't Mr Briscoe just email that there was a BT IPR claim against this ID, related to re-ECN work he did/does for BT? > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From christopher.morrow@gmail.com Thu Mar 29 09:12:42 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3625721F8735; Thu, 29 Mar 2012 09:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.562 X-Spam-Level: X-Spam-Status: No, score=-103.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGVi6oEWu3V1; Thu, 29 Mar 2012 09:12:41 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1868621F8718; Thu, 29 Mar 2012 09:12:41 -0700 (PDT) Received: by obbta17 with SMTP id ta17so842217obb.31 for ; Thu, 29 Mar 2012 09:12:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=goocOdoos0EcpvmqV/NB8Yht2B9VdaqUvspMg/UCxBA=; b=k8M6FELH97sl7ihMQ7jy7DbHzgZ0ZgrbjTaIA0ntvTqKx2sH18KdnikPOLRqJfkWk+ UDCyFKgn74mAxfc0wYoDZeJAZxdj51hzCLFSZa32oeT1YWAbVet+kv4kV9Mh7ZST4CBl L0MNj/FjLD/Qw8O/mIRfkuTZ4FsPEGujm3gZIKAjulHZ6rVnGluMzEDc1v7DL3t92nqo 8AQExYGhOO3dq5Q+QZxKeq5QeXNp2BZVsj2f4qC9fRhkde91V/TMUIIZGQTAa7j+/53j wO6kNwEFcX55QmD2JWeSpQjEI8+NcNFzXzsghiGecQYY1Mbdeq6vlk7OBenh0TaTNakp yx4A== MIME-Version: 1.0 Received: by 10.182.74.8 with SMTP id p8mr44706459obv.41.1333037560641; Thu, 29 Mar 2012 09:12:40 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Thu, 29 Mar 2012 09:12:40 -0700 (PDT) In-Reply-To: References: <20120329141002.22903.96428.idtracker@ietfa.amsl.com> Date: Thu, 29 Mar 2012 12:12:40 -0400 X-Google-Sender-Auth: a2HANQ9mkgUIsGab7BqOq8RQTxQ Message-ID: From: Christopher Morrow To: ietf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF-Announce , conex@ietf.org Subject: Re: [conex] Last Call: (ConEx Concepts and Use Cases) to Informational RFC X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 16:12:42 -0000 On Thu, Mar 29, 2012 at 12:11 PM, Christopher Morrow wrote: > On Thu, Mar 29, 2012 at 10:10 AM, The IESG wrot= e: >> >> The IESG has received a request from the Congestion Exposure WG (conex) >> to consider the following document: >> - 'ConEx Concepts and Use Cases' >> =A0 as an Informational RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2012-04-12. Exceptionally, comments may b= e >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> =A0 This document provides the entry point to the set of documentation >> =A0 about the Congestion Exposure (ConEx) protocol. =A0It explains the >> =A0 motivation for including a ConEx marking at the IP layer: to expose >> =A0 information about congestion to network nodes. =A0Although such >> =A0 information may have a number of uses, this document focuses on how >> =A0 the information communicated by the ConEx marking can serve as the >> =A0 basis for significantly more efficient and effective traffic >> =A0 management than what exists on the Internet today. >> >> >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-conex-concepts-uses/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-conex-concepts-uses/ballot/ >> >> >> No IPR declarations have been submitted directly on this I-D. > > Didn't Mr Briscoe just email that there was a BT IPR claim against > this ID, related to re-ECN work he did/does for BT? http://www.ietf.org/mail-archive/web/conex/current/msg00916.html From bob.briscoe@bt.com Thu Mar 29 09:12:42 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330E521F8732 for ; Thu, 29 Mar 2012 09:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78ZDQCDL+VhI for ; Thu, 29 Mar 2012 09:12:41 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 77B5721F8711 for ; Thu, 29 Mar 2012 09:12:40 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 29 Mar 2012 17:12:38 +0100 Received: from rdw02134app71.domain1.systemhost.net (193.113.234.138) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 29 Mar 2012 17:12:37 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com (147.149.100.81) by rdw02134app71.domain1.systemhost.net (10.36.6.87) with Microsoft SMTP Server id 14.2.247.3; Thu, 29 Mar 2012 17:12:31 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1333037562272; Thu, 29 Mar 2012 17:12:42 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.162.109]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q2TGCQPI001627; Thu, 29 Mar 2012 17:12:26 +0100 Message-ID: <201203291612.q2TGCQPI001627@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 29 Mar 2012 17:10:39 +0100 To: Ingemar Johansson S From: Bob Briscoe In-Reply-To: References: <20111030141755.21962.83789.idtracker@ietfa.amsl.com> <20111107160135.GA45061@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: "conex@ietf.org" Subject: Re: [conex] ConEx as sender side only modification X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 16:12:42 -0000 Ingemar, For a Not-ECN-capable transport, SACK is fully=20 accurate enough for the sender to know every lost=20 byte. That's the main reason ConEx is optional for the receiver. For ECN-capable transport, using an un-modifed=20 receiver is not so good. You can use various=20 strategies if you have to (a couple are given in the accurate ECN draft). You will see Michael Menth's simulations later in=20 the ConEx session show how it's not so good with=20 unmodified ECN-capable receiver. HTH Bob At 11:16 14/11/2011, Ingemar Johansson S wrote: >Hi > >Have not been able to follow the ConEx list in detail but reading >http://tools.ietf.org/id/draft-briscoe-conex-initial-deploy-00.txt >I can see that received side modifications are optional. >This is of course interesting at least if=20 >consinder the normal server client architecture=20 >as it is easier to modify a million servers than a zillion clients. >Assuming that I read right... >How does it work with TCP, I know TCP=20 >modifications have been considered to make TCP=20 >echo back the exact correct number of ECN-CE to the server. >Does this then mean that a TCP flow (unmodified=20 >TCP) will state a higher congestion level in the dest-opts than the actual= ? > >/Ingemar > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >INGEMAR JOHANSSON M.Sc. >Senior Researcher > >Ericsson AB >Wireless Access Networks >Labratoriegr=E4nd 11 >971 28, Lule=E5, Sweden >Phone +46-1071 43042 >SMS/MMS +46-73 078 3289 >ingemar.s.johansson@ericsson.com >www.ericsson.com >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 From rs@netapp.com Thu Mar 29 23:39:24 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89A021F879B for ; Thu, 29 Mar 2012 23:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.535 X-Spam-Level: X-Spam-Status: No, score=-10.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6Caxoy0qCCB for ; Thu, 29 Mar 2012 23:39:23 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id B061F21F8582 for ; Thu, 29 Mar 2012 23:39:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,341,1330934400"; d="scan'208";a="637398047" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 29 Mar 2012 23:39:22 -0700 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q2U6dMkF017468; Thu, 29 Mar 2012 23:39:22 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.178]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0247.003; Thu, 29 Mar 2012 23:39:15 -0700 From: "Scheffenegger, Richard" To: Bob Briscoe , Ingemar Johansson S Thread-Topic: [conex] ConEx as sender side only modification Thread-Index: AQHNDcbkWDATXpQn5E29dgi3nK8Uk5aBy8bg Date: Fri, 30 Mar 2012 06:39:14 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F130496@SACEXCMBX02-PRD.hq.netapp.com> References: <20111030141755.21962.83789.idtracker@ietfa.amsl.com> <20111107160135.GA45061@verdi> <201203291612.q2TGCQPI001627@bagheera.jungle.bt.co.uk> In-Reply-To: <201203291612.q2TGCQPI001627@bagheera.jungle.bt.co.uk> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] ConEx as sender side only modification X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 06:39:25 -0000 Bob,=20 a minor nit-pick; even with SACK-enabled flows, you may underestimate the l= ost bytes from time to time. Whenever a retransmission is lost, the sender = won't know about these further bytes that have lost. Unless, that is, the sender also implements lost retransmission detection (= which is not standard, and only available in Linux, when the sender buffer = is not empty). But I do agree with the spirit of your comment, SACK is good enough for con= ex to account the lost bytes. The deviation can be estimated by looking at = the fraction of (sender side) timeout retransmissions (I think linux breaks= them down even further) vs. total packets sent. That should be in the orde= r of 10^-4 or lower even for bad links. Richard Scheffenegger > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Bob Briscoe > Sent: Donnerstag, 29. M=E4rz 2012 18:11 > To: Ingemar Johansson S > Cc: conex@ietf.org > Subject: Re: [conex] ConEx as sender side only modification >=20 > Ingemar, >=20 > For a Not-ECN-capable transport, SACK is fully accurate enough for the > sender to know every lost byte. That's the main reason ConEx is optional = for > the receiver. >=20 > For ECN-capable transport, using an un-modifed receiver is not so good. Y= ou > can use various strategies if you have to (a couple are given in the accu= rate > ECN draft). >=20 > You will see Michael Menth's simulations later in the ConEx session show > how it's not so good with unmodified ECN-capable receiver. >=20 > HTH >=20 >=20 > Bob >=20 > At 11:16 14/11/2011, Ingemar Johansson S wrote: > >Hi > > > >Have not been able to follow the ConEx list in detail but reading > >http://tools.ietf.org/id/draft-briscoe-conex-initial-deploy-00.txt > >I can see that received side modifications are optional. > >This is of course interesting at least if consinder the normal server > >client architecture as it is easier to modify a million servers than a > >zillion clients. > >Assuming that I read right... > >How does it work with TCP, I know TCP > >modifications have been considered to make TCP echo back the exact > >correct number of ECN-CE to the server. > >Does this then mean that a TCP flow (unmodified > >TCP) will state a higher congestion level in the dest-opts than the actu= al ? > > > >/Ingemar > > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > >INGEMAR JOHANSSON M.Sc. > >Senior Researcher > > > >Ericsson AB > >Wireless Access Networks > >Labratoriegr=E4nd 11 > >971 28, Lule=E5, Sweden > >Phone +46-1071 43042 > >SMS/MMS +46-73 078 3289 > >ingemar.s.johansson@ericsson.com > >www.ericsson.com > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > >_______________________________________________ > >conex mailing list > >conex@ietf.org > >https://www.ietf.org/mailman/listinfo/conex >=20 > __________________________________________________________ > ______ > Bob Briscoe, BT Innovate & Design >=20 > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From teco@inf-net.nl Fri Mar 30 00:30:46 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE17821F8757 for ; Fri, 30 Mar 2012 00:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeeJCqNH4Zfx for ; Fri, 30 Mar 2012 00:30:46 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 41A0821F8754 for ; Fri, 30 Mar 2012 00:30:44 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so223738wib.13 for ; Fri, 30 Mar 2012 00:30:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:subject:date:message-id:to:mime-version:x-mailer :x-gm-message-state:content-type:content-transfer-encoding; bh=Jw4mA2PMcpIi1nlDkIi7Yk1ySO284HGpq4hEFpA1MkY=; b=UTXeeSqAWiYh2Cd1xY5EqFCoCafNaLZ/invzWDMCvO+yBhfrZ+1RrA8E/1LnK7APlH vjalvBi+wY9rMM2EmhKn9Eux/bIU4fqFBLwB/gJEGYnfc7VLCl/gsq/Ipc5udZUujzWw /670R5ODnIq/dt8AqI2fhvqzWD3iGCjBfJx/Ia9ryviX0wg95ghQFKlZM5a/tbKdcFB2 vBhGDeFiXT2gzqqBcsBiKfIC7IxZMOwhL4rmlXmxcLilW0H46fdR8yo/OTlulow//eSQ kzl+S3Oes7IFrKnHiD9fekIml9TjyGC6GD1Dty6JICfaNSTgsdzpESO/ReyaS4PgJZnp vmew== Received: by 10.180.95.74 with SMTP id di10mr7187440wib.1.1333092643402; Fri, 30 Mar 2012 00:30:43 -0700 (PDT) Received: from dhcp-1333.meeting.ietf.org (dhcp-1333.meeting.ietf.org. [130.129.19.51]) by mx.google.com with ESMTPS id ff9sm4230905wib.2.2012.03.30.00.30.42 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Mar 2012 00:30:42 -0700 (PDT) From: Teco Boot Date: Fri, 30 Mar 2012 09:30:41 +0200 Message-Id: <69F41DCF-573C-4A1F-BCE7-5877E5025B0E@inf-net.nl> To: conex@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmLTHrCcX1+C5+ywnfyH0usfw5lTShxbiCOALV2LI9VA53RE4cnL1RIVIPi+stBkBTCLDr3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [conex] conex-destopt-02 section 7: IPsec and tunneling / byte-counting X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 07:30:47 -0000 In draft-ietf-conex-destopt-02 there is some wording on IPsec and tunnels. I think this applies to all tunnel methods. I suggest to put the byte-counting stuff in another document. It is more complex as written down here, as for example the IPsec function is often decoupled with the Conex function, probably another box. Teco From marcelo@it.uc3m.es Fri Mar 30 02:56:03 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D86A21F894F; Fri, 30 Mar 2012 02:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KK-lIpjD8Z-1; Fri, 30 Mar 2012 02:56:02 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 5587521F8926; Fri, 30 Mar 2012 02:56:01 -0700 (PDT) X-uc3m-safe: yes Received: from dhcp-117d.meeting.ietf.org (dhcp-117d.meeting.ietf.org [130.129.17.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 9B0FA9C63A0; Fri, 30 Mar 2012 11:56:00 +0200 (CEST) Message-ID: <4F758327.3000104@it.uc3m.es> Date: Fri, 30 Mar 2012 11:55:51 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Christopher Morrow References: <20120329141002.22903.96428.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18806.006 Cc: ietf@ietf.org, IETF-Announce , conex@ietf.org Subject: Re: [conex] Last Call: (ConEx Concepts and Use Cases) to Informational RFC X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 09:56:03 -0000 Hi, Bob's email specifically said specifications and mechanisms would be likely to be tagged with the IPR. This particular document is neither a specification nor a mechanism as it describes the use cases for conex. When the drafts describing the conex spec are sent to the IESG, the IPR claim will be propely pointed out. I hope this clarifies the issue. Regards, marcelo El 29/03/12 18:11, Christopher Morrow escribió: > On Thu, Mar 29, 2012 at 10:10 AM, The IESG wrote: >> The IESG has received a request from the Congestion Exposure WG (conex) >> to consider the following document: >> - 'ConEx Concepts and Use Cases' >> as an Informational RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2012-04-12. Exceptionally, comments may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> This document provides the entry point to the set of documentation >> about the Congestion Exposure (ConEx) protocol. It explains the >> motivation for including a ConEx marking at the IP layer: to expose >> information about congestion to network nodes. Although such >> information may have a number of uses, this document focuses on how >> the information communicated by the ConEx marking can serve as the >> basis for significantly more efficient and effective traffic >> management than what exists on the Internet today. >> >> >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-conex-concepts-uses/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-conex-concepts-uses/ballot/ >> >> >> No IPR declarations have been submitted directly on this I-D. > Didn't Mr Briscoe just email that there was a BT IPR claim against > this ID, related to re-ECN work he did/does for BT? > >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex > From ingemar.s.johansson@ericsson.com Fri Mar 30 03:16:00 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525E021F8880 for ; Fri, 30 Mar 2012 03:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.054 X-Spam-Level: X-Spam-Status: No, score=-8.054 tagged_above=-999 required=5 tests=[AWL=-1.805, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0FuUbHDHTEG for ; Fri, 30 Mar 2012 03:15:59 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8314621F8799 for ; Fri, 30 Mar 2012 03:15:57 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-24-4f7587dc699b Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B6.D0.25560.CD7857F4; Fri, 30 Mar 2012 12:15:56 +0200 (CEST) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.196]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Fri, 30 Mar 2012 12:15:56 +0200 From: Ingemar Johansson S To: "Scheffenegger, Richard" , Bob Briscoe Date: Fri, 30 Mar 2012 12:15:54 +0200 Thread-Topic: [conex] ConEx as sender side only modification Thread-Index: AQHNDcbkWDATXpQn5E29dgi3nK8Uk5aBy8bggADUJEA= Message-ID: References: <20111030141755.21962.83789.idtracker@ietfa.amsl.com> <20111107160135.GA45061@verdi> <201203291612.q2TGCQPI001627@bagheera.jungle.bt.co.uk> <012C3117EDDB3C4781FD802A8C27DD4F130496@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F130496@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "conex@ietf.org" Subject: Re: [conex] ConEx as sender side only modification X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 10:16:00 -0000 Hi Thanks all, this really improved my understanding.=20 /Ingemar > -----Original Message----- > From: Scheffenegger, Richard [mailto:rs@netapp.com]=20 > Sent: den 30 mars 2012 08:39 > To: Bob Briscoe; Ingemar Johansson S > Cc: conex@ietf.org > Subject: RE: [conex] ConEx as sender side only modification >=20 >=20 > Bob,=20 >=20 > a minor nit-pick; even with SACK-enabled flows, you may=20 > underestimate the lost bytes from time to time. Whenever a=20 > retransmission is lost, the sender won't know about these=20 > further bytes that have lost. >=20 > Unless, that is, the sender also implements lost=20 > retransmission detection (which is not standard, and only=20 > available in Linux, when the sender buffer is not empty). >=20 > But I do agree with the spirit of your comment, SACK is good=20 > enough for conex to account the lost bytes. The deviation can=20 > be estimated by looking at the fraction of (sender side)=20 > timeout retransmissions (I think linux breaks them down even=20 > further) vs. total packets sent. That should be in the order=20 > of 10^-4 or lower even for bad links. >=20 >=20 >=20 > Richard Scheffenegger >=20 >=20 > > -----Original Message----- > > From: conex-bounces@ietf.org=20 > [mailto:conex-bounces@ietf.org] On Behalf=20 > > Of Bob Briscoe > > Sent: Donnerstag, 29. M=E4rz 2012 18:11 > > To: Ingemar Johansson S > > Cc: conex@ietf.org > > Subject: Re: [conex] ConEx as sender side only modification > >=20 > > Ingemar, > >=20 > > For a Not-ECN-capable transport, SACK is fully accurate=20 > enough for the=20 > > sender to know every lost byte. That's the main reason ConEx is=20 > > optional for the receiver. > >=20 > > For ECN-capable transport, using an un-modifed receiver is not so=20 > > good. You can use various strategies if you have to (a couple are=20 > > given in the accurate ECN draft). > >=20 > > You will see Michael Menth's simulations later in the ConEx session=20 > > show how it's not so good with unmodified ECN-capable receiver. > >=20 > > HTH > >=20 > >=20 > > Bob > >=20 > > At 11:16 14/11/2011, Ingemar Johansson S wrote: > > >Hi > > > > > >Have not been able to follow the ConEx list in detail but reading=20 > > >http://tools.ietf.org/id/draft-briscoe-conex-initial-deploy-00.txt > > >I can see that received side modifications are optional. > > >This is of course interesting at least if consinder the=20 > normal server=20 > > >client architecture as it is easier to modify a million=20 > servers than=20 > > >a zillion clients. > > >Assuming that I read right... > > >How does it work with TCP, I know TCP modifications have been=20 > > >considered to make TCP echo back the exact correct number=20 > of ECN-CE=20 > > >to the server. > > >Does this then mean that a TCP flow (unmodified > > >TCP) will state a higher congestion level in the dest-opts=20 > than the actual ? > > > > > >/Ingemar > > > > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >INGEMAR JOHANSSON M.Sc. > > >Senior Researcher > > > > > >Ericsson AB > > >Wireless Access Networks > > >Labratoriegr=E4nd 11 > > >971 28, Lule=E5, Sweden > > >Phone +46-1071 43042 > > >SMS/MMS +46-73 078 3289 > > >ingemar.s.johansson@ericsson.com > > >www.ericsson.com > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >_______________________________________________ > > >conex mailing list > > >conex@ietf.org > > >https://www.ietf.org/mailman/listinfo/conex > >=20 > > __________________________________________________________ > > ______ > > Bob Briscoe, BT Innovate & Design > >=20 > > _______________________________________________ > > conex mailing list > > conex@ietf.org > > https://www.ietf.org/mailman/listinfo/conex > = From rs@netapp.com Fri Mar 30 05:48:13 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9801121F8692 for ; Fri, 30 Mar 2012 05:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.392 X-Spam-Level: X-Spam-Status: No, score=-10.392 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YssEbI5wjXok for ; Fri, 30 Mar 2012 05:48:11 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id A0FBB21F8671 for ; Fri, 30 Mar 2012 05:48:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,344,1330934400"; d="scan'208,217";a="637452385" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 30 Mar 2012 05:48:05 -0700 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q2UCm4kC013902; Fri, 30 Mar 2012 05:48:04 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.178]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0247.003; Fri, 30 Mar 2012 05:47:57 -0700 From: "Scheffenegger, Richard" To: Nandita Dukkipati , =?iso-8859-1?Q?Mirja_K=FChlewind?= Thread-Topic: Comments on ConEx TCP Modifications Thread-Index: AQHNDNtTba2T0AMdn0iF2+wPmf3O0JZ/sT1A Date: Fri, 30 Mar 2012 12:47:56 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F13135B@SACEXCMBX02-PRD.hq.netapp.com> References: In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F13135BSACEXCMBX02PRDhqn_" MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] Comments on ConEx TCP Modifications X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 12:48:13 -0000 --_000_012C3117EDDB3C4781FD802A8C27DD4F13135BSACEXCMBX02PRDhqn_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Nandita, thank you for your comments! I think using the definition of DeliveredData instead of acked_bytes makes = sense. However, in section 3.1.2, simple and advanced compatibility mode, we run i= nto problems one way or the other... We will - on average - miss up to (M-= 1)/M CE marks (M ... delayed ACK count, ie. 2) for every CE received. The o= bvious and preferred approach is to have a accurate ECN feedback on TCP her= e, but for some time we will need to consider these compatibility modes. Fo= r them, knowning the ACK ratio (M) is definitely necessary. However, a prop= er definition of M (and making it uppercase everywhere) needs to be added. Advanced Compatibility mode would be when the sender selectively sets CWR o= nly on those packets, that will trigger an ACK on a legacy ECN receiver. Th= at would, to a large extent, address the concern we have around missing a C= E mark (which would result in a reduction of the TCP window). The basic ide= a around this we came up after some brainstorming (thanks Andrew and Jana).= However, the complexity of implementing this (phase locked loops to figure= out which data packets trigger ACKs, and the dead-time compensation) is pr= obably too complex for the gains here, compared with the two other variants= (simple, legacy ECN feedback, and basic compatibility by keeping CWR set c= onstantly). After some discussions with Alfons yesterday, there is actually one point t= hat needs further discussion / clearification. During the presentation of t= he simulation results, two variants of policers were presented. The strict = variant would preferably drop conex-marked packets, the normal should drop = any conex-enabled packet with equal probability. (Also, in "inverse" of the= strict variant can be envisioned). Depending on what the proper way is to = implement the drop policies in there, our current conex TCP mod draft needs= to revisit when to set the L mark actually. Richard Scheffenegger 5. Section 3.1.2 On the use of 'M' You won't require to use any variable 'M' when you track precisely the byte= s delivered per ACK using the DeliveredData that I mentioned above. 7. Advanced Compatibility mode Not clear to me at all what this text is trying to say. 8. Sec 3.2 "Note that the above heuristics delays the ConEx signal by one segment, and= also..." You mean delay by 1 RTT? Comment as chair Section 3 Accounting Congestion bytes vs. packets: I would like to see consistency across the two drafts (a= bstract mechanism, TCP modifications) on the issue of whether ConEx marking= and accounting should be in bytes or in packets. What are the pros/cons an= d corner cases for each? What is the final recommendation that you make? Wh= ich of these drafts should make this recommendation - I would think it's th= e TCP modifications draft. If you haven't already, could you please read up the latest Concepts and Ab= stract Mechanism draft and communicate with the authors of that document an= d make sure we have consistency on bytes vs. packets across the two I-Ds. --_000_012C3117EDDB3C4781FD802A8C27DD4F13135BSACEXCMBX02PRDhqn_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Nandita= ,

 = ;

thank you = for your comments!

 = ;

I think us= ing the definition of DeliveredData instead of acked_bytes makes sense.

 = ;

However, i= n section 3.1.2, simple and advanced compatibility mode, we run into proble= ms one way or the other…  We will – on average – mis= s up to (M-1)/M CE marks (M … delayed ACK count, ie. 2) for every CE receive= d. The obvious and preferred approach is to have a accurate ECN feedback on= TCP here, but for some time we will need to consider these compatibility m= odes. For them, knowning the ACK ratio (M) is definitely necessary. However, a proper definition of M (and making= it uppercase everywhere) needs to be added.

 = ;

 = ;

Advanced C= ompatibility mode would be when the sender selectively sets CWR only on tho= se packets, that will trigger an ACK on a legacy ECN receiver. That would, to a large extent, address the concern we have around missing = a CE mark (which would result in a reduction of the TCP window). The basic = idea around this we came up after some brainstorming (thanks Andrew and Jan= a). However, the complexity of implementing this (phase locked loops to figure out which data packets trigger ACKs, an= d the dead-time compensation) is probably too complex for the gains here, c= ompared with the two other variants (simple, legacy ECN feedback, and basic= compatibility by keeping CWR set constantly).

 = ;

 = ;

After some= discussions with Alfons yesterday, there is actually one point that needs = further discussion / clearification. During the presentation of the simulation results, two variants of policers were presented. The st= rict variant would preferably drop conex-marked packets, the normal should = drop any conex-enabled packet with equal probability. (Also, in “inve= rse” of the strict variant can be envisioned). Depending on what the proper way is to implement the drop policies in ther= e, our current conex TCP mod draft needs to revisit when to set the L mark = actually.

 = ;

 = ;

 = ;

 = ;

Richard Sc= heffenegger

5. Section 3.1.2  

On the use of 'M'

You won't require to use any va= riable 'M' when you track precisely the bytes delivered per ACK using the D= eliveredData that I mentioned above.

 

7. Advanced Compatibility mode<= o:p>

Not clear to me at all what thi= s text is trying to say.

 

8. Sec 3.2

"Note that the above heuri= stics delays the ConEx signal by one segment, and also..."<= /span>

You mean delay by 1 RTT?

 

Comment as chair

 

Section 3 Accounting Congestion=

bytes vs. packets: I would like= to see consistency across the two drafts (abstract mechanism, TCP modifica= tions) on the issue of whether ConEx marking and accounting should be in by= tes or in packets. What are the pros/cons and corner cases for each? What is the final recommendation that you make?= Which of these drafts should make this recommendation - I would think it's= the TCP modifications draft. 

 

If you haven't already, could y= ou please read up the latest Concepts and Abstract Mechanism draft and= communicate with the authors of that document and make sure we have consis= tency on bytes vs. packets across the two I-Ds.

--_000_012C3117EDDB3C4781FD802A8C27DD4F13135BSACEXCMBX02PRDhqn_-- From mattmathis@google.com Fri Mar 30 12:52:09 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6678721F8464 for ; Fri, 30 Mar 2012 12:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.902 X-Spam-Level: X-Spam-Status: No, score=-102.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id db1OBFy0bMKL for ; Fri, 30 Mar 2012 12:52:08 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id E054A21F84FB for ; Fri, 30 Mar 2012 12:52:07 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so734394wib.13 for ; Fri, 30 Mar 2012 12:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=hFK3ZpTzy2014bWKm97TujX0/HYSRGkQyf29QRL9mgc=; b=VQk9Q6JDxnOEttnHuhBneLKU0nSlZhRn76/CZLODOlpJ8q/s99Af+Q0EbtfLm00Gv7 9QHr2+uLxJurAW3PHwJUmFIrRZpHtdRRwKWEL7WT9QVXSfDGk34OBrHIqy3PP1bgpQ1m JKWw14R5nSa3g3dyKaSnahHylLhmvi73U4eEl01v6cQcbgNIq0loUKvNPZaW99WKV/o8 exKFK8Fhun8nTZBOVQzYZP30MfovQLZGt6/WpQ9lhJIjzlmkG3jRJoQqsgp8udZy11pH o78pKHhN2fEU8I3Rc2aKFXCk2dGkhi4v1720BukUH4xnMzDR7Zs9N4sPJjUtc3i2sDk9 6zzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=hFK3ZpTzy2014bWKm97TujX0/HYSRGkQyf29QRL9mgc=; b=QRJAEliqOS3rm6sotLsHTFzsJcM0MJSKHHg1ik7gjfvfBkIhmvymQrw1Y0Otd5P78/ KHdwGbhSCtMsZTYnAkkqh5ZeDmPqO75kusRz/RNl2MPb+LL01MPG5jBXiZTt9BFlT/hq jnicAPOfkByB0fQRIucZRwA3FAI4Latgen/GJff5dYk5Li4NTQiY8Sz5tHxleWmQhcnB ibw56Mz9VzTDG8IuI/Rj79rqG04DUKYwQMzfPIVJw2xec6ZWvLVIj7IcPnxTwoh4X7Yr Oo5jYxfG6Gn7F8r7a02d24IcEXuS5PKt8tWwwoyyYHAN2Yt0wt1UzxKcK4SZDBHxN0u7 uIgA== Received: by 10.180.103.134 with SMTP id fw6mr187173wib.0.1333137126942; Fri, 30 Mar 2012 12:52:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.103.134 with SMTP id fw6mr187149wib.0.1333137126840; Fri, 30 Mar 2012 12:52:06 -0700 (PDT) Received: by 10.216.217.85 with HTTP; Fri, 30 Mar 2012 12:52:06 -0700 (PDT) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F130496@SACEXCMBX02-PRD.hq.netapp.com> References: <20111030141755.21962.83789.idtracker@ietfa.amsl.com> <20111107160135.GA45061@verdi> <201203291612.q2TGCQPI001627@bagheera.jungle.bt.co.uk> <012C3117EDDB3C4781FD802A8C27DD4F130496@SACEXCMBX02-PRD.hq.netapp.com> Date: Fri, 30 Mar 2012 21:52:06 +0200 Message-ID: From: Matt Mathis To: "Scheffenegger, Richard" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQkTK3y3XV5Jv3jxe+Xzuy5dGMV1ysWRcgtdaNPS033ROD3uVkmfv3otXaecisQJWZADnAHeZT5lQ7YOl/xsADedoHRx2j3Zd0dXC0mr6c1YEPIK5p+J4e7M3VQPEDS9fxvW2mzo Cc: Ingemar Johansson S , "conex@ietf.org" Subject: Re: [conex] ConEx as sender side only modification X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 19:52:09 -0000 One robust algorithm to audit loss is to look at sequences numbers and count duplicate data. Such an auditor will see every retransmission (including twice lost and re-retransmitted segments), but it can't tell if TCP later decided that they were spurious. So the audit has to balance retransmissions, and not TCP's estimated losses= . Thanks, --MM-- The best way to predict the future is to create it. =A0- Alan Kay On Fri, Mar 30, 2012 at 8:39 AM, Scheffenegger, Richard wro= te: > > Bob, > > a minor nit-pick; even with SACK-enabled flows, you may underestimate the= lost bytes from time to time. Whenever a retransmission is lost, the sende= r won't know about these further bytes that have lost. > > Unless, that is, the sender also implements lost retransmission detection= (which is not standard, and only available in Linux, when the sender buffe= r is not empty). > > But I do agree with the spirit of your comment, SACK is good enough for c= onex to account the lost bytes. The deviation can be estimated by looking a= t the fraction of (sender side) timeout retransmissions (I think linux brea= ks them down even further) vs. total packets sent. That should be in the or= der of 10^-4 or lower even for bad links. > > > > Richard Scheffenegger > > >> -----Original Message----- >> From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf >> Of Bob Briscoe >> Sent: Donnerstag, 29. M=E4rz 2012 18:11 >> To: Ingemar Johansson S >> Cc: conex@ietf.org >> Subject: Re: [conex] ConEx as sender side only modification >> >> Ingemar, >> >> For a Not-ECN-capable transport, SACK is fully accurate enough for the >> sender to know every lost byte. That's the main reason ConEx is optional= for >> the receiver. >> >> For ECN-capable transport, using an un-modifed receiver is not so good. = You >> can use various strategies if you have to (a couple are given in the acc= urate >> ECN draft). >> >> You will see Michael Menth's simulations later in the ConEx session show >> how it's not so good with unmodified ECN-capable receiver. >> >> HTH >> >> >> Bob >> >> At 11:16 14/11/2011, Ingemar Johansson S wrote: >> >Hi >> > >> >Have not been able to follow the ConEx list in detail but reading >> >http://tools.ietf.org/id/draft-briscoe-conex-initial-deploy-00.txt >> >I can see that received side modifications are optional. >> >This is of course interesting at least if consinder the normal server >> >client architecture as it is easier to modify a million servers than a >> >zillion clients. >> >Assuming that I read right... >> >How does it work with TCP, I know TCP >> >modifications have been considered to make TCP echo back the exact >> >correct number of ECN-CE to the server. >> >Does this then mean that a TCP flow (unmodified >> >TCP) will state a higher congestion level in the dest-opts than the act= ual ? >> > >> >/Ingemar >> > >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >INGEMAR JOHANSSON =A0M.Sc. >> >Senior Researcher >> > >> >Ericsson AB >> >Wireless Access Networks >> >Labratoriegr=E4nd 11 >> >971 28, Lule=E5, Sweden >> >Phone +46-1071 43042 >> >SMS/MMS +46-73 078 3289 >> >ingemar.s.johansson@ericsson.com >> >www.ericsson.com >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >_______________________________________________ >> >conex mailing list >> >conex@ietf.org >> >https://www.ietf.org/mailman/listinfo/conex >> >> __________________________________________________________ >> ______ >> Bob Briscoe, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0BT Innovate & Design >> >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From nanditad@google.com Fri Mar 30 14:55:14 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4CD21F8602 for ; Fri, 30 Mar 2012 14:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.886 X-Spam-Level: X-Spam-Status: No, score=-102.886 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Reox9UAv-RyQ for ; Fri, 30 Mar 2012 14:55:14 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 06FFC21F8627 for ; Fri, 30 Mar 2012 14:55:13 -0700 (PDT) Received: by obbta17 with SMTP id ta17so1752587obb.31 for ; Fri, 30 Mar 2012 14:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=St+vyWPHdt95LNzuNApXGlCX9xvsZMitEUU66fZ1maE=; b=ErUzBIw3fwNiD/ommCTy3O7o97tSsZZmMtDk4kxsH89n8rQqFCldwgGezBHWXX+sxm XaUckW9yBkXJq96mf5yFEg1ke7jmcgusdvwx2LPw9Eu+xKqhu1c2U4SYgx4gUWtPDgQa 1wRNbCyh/w74Wc1nG8CQ47zmlkkH2a7pm/f9Q2bKEkwauYl7fRog0kwV6GI1lPetuaZ3 XdnfyAq3bkxsrTo02f0y5XCct5AjjKCYKVZZt2mxdOVIDLEw8pkERyhXfLEXBUCIHxDb phEvhuE3+Qfo1BbVcgZBKnRcPm5F1e+N89SMMQU8tesdOvORm12Hlk6XH8HOB0l/XMbu Zt+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=St+vyWPHdt95LNzuNApXGlCX9xvsZMitEUU66fZ1maE=; b=S51iXjBqhJeFI4NKXxrIm59xFuZVIWahxHgt93KCAAt49xe5iJZI1NQz59eKKDLuLo 3jP/6nltK+sA7OXE13G68O5VKFsY/xqee1Xw4pulwsJDR9DIaHeQIlvt11eWHvLIhV7W 4P+CsHCwupOa59ZZPAiqIuvpfrXLOdk1W30JBzL5QjMEyGMH1nzPr9OxqxvAFrpeifn8 u5b1YNGZqEJUbYqQ9Sbmmw8Hb6+5T4l95hwWD9cq9Z7jm4LZJVVTBMvr8WKnOe9Iu5Sy sN/IcBPzyl0ksKJ3Z0at5tp8hBuCCzUdkaER6ytRNgFFnrX9+espavPUvLcFaBClBgv3 k7Cw== Received: by 10.182.202.69 with SMTP id kg5mr83720obc.35.1333144513433; Fri, 30 Mar 2012 14:55:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.202.69 with SMTP id kg5mr83709obc.35.1333144513342; Fri, 30 Mar 2012 14:55:13 -0700 (PDT) Received: by 10.182.69.164 with HTTP; Fri, 30 Mar 2012 14:55:13 -0700 (PDT) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F13135B@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F13135B@SACEXCMBX02-PRD.hq.netapp.com> Date: Fri, 30 Mar 2012 23:55:13 +0200 Message-ID: From: Nandita Dukkipati To: "Scheffenegger, Richard" Content-Type: multipart/alternative; boundary=e89a8f6438c226ecc404bc7ce5c3 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmzfBMn51PtXaUqeVeVeoMi4q2ZX6aUAW//l9jX2q3Cbatt1Lg6SGQLRyOkj9exswbYbtGKOVKOPLnF4/Zb+kHGYONYFw/iktzwn9ArAWer9kWQhSzQpJjO0Kn64nWd34dJwIBH Cc: "conex@ietf.org" Subject: Re: [conex] Comments on ConEx TCP Modifications X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 21:55:14 -0000 --e89a8f6438c226ecc404bc7ce5c3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Mar 30, 2012 at 2:47 PM, Scheffenegger, Richard wrot= e: > Hi Nandita,**** > > ** ** > > thank you for your comments!**** > > ** ** > > I think using the definition of DeliveredData instead of acked_bytes make= s > sense.**** > > ** ** > > However, in section 3.1.2, simple and advanced compatibility mode, we run > into problems one way or the other=85 We will =96 on average =96 miss up= to > (M-1)/M CE marks (M =85 delayed ACK count, ie. 2) for every CE received. = The > obvious and preferred approach is to have a accurate ECN feedback on TCP > here, but for some time we will need to consider these compatibility mode= s. > For them, knowning the ACK ratio (M) is definitely necessary. > > However, a proper definition of M (and making it uppercase everywhere) > needs to be added. > keep it simple and easy to reason about. The CUBIC CC algo. in Linux impl. has one way to track delayed ack ratio - take a look to see if you can make it better than what there. --e89a8f6438c226ecc404bc7ce5c3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Fri, Mar 30, 2012 at 2:47 PM, Scheffe= negger, Richard <rs@n= etapp.com> wrote:

Hi Nandita= ,

=A0=

thank you = for your comments!

=A0=

I think us= ing the definition of DeliveredData instead of acked_bytes makes sense.<= /u>

=A0=

However, i= n section 3.1.2, simple and advanced compatibility mode, we run into proble= ms one way or the other=85=A0 We will =96 on average =96 miss up to (M-1)/M CE marks (M =85 delayed ACK count, ie. 2) for every CE received. T= he obvious and preferred approach is to have a accurate ECN feedback on TCP= here, but for some time we will need to consider these compatibility modes= . For them, knowning the ACK ratio (M) is definitely necessary.

=A0<= /div>

Howev= er, a proper definition of M (and making it uppercase everywhere) needs to = be added.

=A0
keep it simple and easy to reas= on about. The CUBIC CC algo. in Linux impl. has one way to track delayed ac= k ratio - take a look to see if you can make it better than what there.
--e89a8f6438c226ecc404bc7ce5c3-- From bob.briscoe@bt.com Sat Mar 31 07:03:58 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C9321F86B7 for ; Sat, 31 Mar 2012 07:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.667 X-Spam-Level: X-Spam-Status: No, score=-2.667 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWodYtPnQVNP for ; Sat, 31 Mar 2012 07:03:57 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBD221F8678 for ; Sat, 31 Mar 2012 07:03:57 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 31 Mar 2012 15:03:56 +0100 Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 31 Mar 2012 15:03:54 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.2.247.3; Sat, 31 Mar 2012 15:03:52 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1333202645495; Sat, 31 Mar 2012 15:04:05 +0100 Received: from MUT.jungle.bt.co.uk ([10.142.64.76]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q2VE3oQE016770; Sat, 31 Mar 2012 15:03:51 +0100 Message-ID: <201203311403.q2VE3oQE016770@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 30 Mar 2012 20:30:42 +0100 To: "Scheffenegger, Richard" From: Bob Briscoe In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F13135B@SACEXCMBX02-PRD.hq. netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F13135B@SACEXCMBX02-PRD.hq.netapp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: "conex@ietf.org" Subject: Re: [conex] Comments on ConEx TCP Modifications X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 14:03:58 -0000 Richard, At 13:47 30/03/2012, Scheffenegger, Richard wrote: >two variants of policers were presented. The strict variant would >preferably drop conex-marked packets, the normal should drop any >conex-enabled packet with equal probability. (Also, in "inverse" of >the strict variant can be envisioned). Depending on what the proper >way is to implement the drop policies in there, our current conex >TCP mod draft needs to revisit when to set the L mark actually. I know Credit marking and *audit* are mutually dependent (Matt's talk). But I don't see how TCP's ConEx marking depends on *policer* design (or the other way round for that matter). I imagine people will design policers to try not to be firm but not pathological to typical transport *responses* to loss, but I don't see how ConEx-marking behaviour will matter to a policer. What are you thinking of here? 1/ 'Best' treatment of L-markings I have always been worried that dropping L packets could lead to problems, by creating a "black hole", as follows: 1) Bucket is empty, which must have been due to too many L packets. 2) Policer drop causes sender to slow-down but also insert more L packets. 3) Bucket empties faster. 4) Goto 2) I suspected this might cause the sender to stall, so we always tried to avoid dropping L-marked packets. I was interested to see that this didn't happen in Alfons/Michael's simulations, so I would like to know the details of their policer algo. Perhaps it's because the NewReno rate-reduction is sufficient to jump out of the "black hole". It would be interesting to see what happens with an unresponsive flow, and with DCTCP, which responds in more smaller steps. 2/ Policer diversity One of the outcomes of ConEx experiments will be to see the breadth of designs people come up with. Michael's experiments are a welcome start to that. We should maintain a list of these designs and experiments. In S.11.2 of my PhD thesis "Policer Diversity" , I listed all the designs of policer I had published or knew of at the time. Since then I know of one more publication of a policer design, with summary simulation results: Raiciu, C. (Ed.), "Progress on resource control," Trilogy EU 7th Framework Project ICT-216372 Deliverable 9 (December 2009) Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From rs@netapp.com Sat Mar 31 10:57:13 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734B121F8531 for ; Sat, 31 Mar 2012 10:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.481 X-Spam-Level: X-Spam-Status: No, score=-10.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jANFZk1lyvxF for ; Sat, 31 Mar 2012 10:57:12 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id E1C5C21F851C for ; Sat, 31 Mar 2012 10:57:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,349,1330934400"; d="scan'208";a="637726855" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 31 Mar 2012 10:56:54 -0700 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q2VHusVv009401; Sat, 31 Mar 2012 10:56:54 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.76]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0247.003; Sat, 31 Mar 2012 10:56:46 -0700 From: "Scheffenegger, Richard" To: Bob Briscoe Thread-Topic: [conex] Comments on ConEx TCP Modifications Thread-Index: AQHNDNtTba2T0AMdn0iF2+wPmf3O0JZ/sT1AgATDQA+AADd8EA== Date: Sat, 31 Mar 2012 17:56:45 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F1428A3@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F13135B@SACEXCMBX02-PRD.hq.netapp.com> <201203311403.q2VE3oQE016770@bagheera.jungle.bt.co.uk> In-Reply-To: <201203311403.q2VE3oQE016770@bagheera.jungle.bt.co.uk> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] Comments on ConEx TCP Modifications X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 17:57:13 -0000 Hi Bob, Richard Scheffenegger > I imagine people will design policers to try not to be firm but not patho= logical > to typical transport *responses* to loss, but I don't see how ConEx-marki= ng > behaviour will matter to a policer. >=20 > What are you thinking of here? >=20 >=20 > 1/ 'Best' treatment of L-markings > I have always been worried that dropping L packets could lead to problems= , > by creating a "black hole", as follows: > 1) Bucket is empty, which must have been due to too many L packets. > 2) Policer drop causes sender to slow-down but also insert more L packets= . > 3) Bucket empties faster. > 4) Goto 2) >=20 > I suspected this might cause the sender to stall, so we always tried to a= void > dropping L-marked packets. I was interested to see that this didn't happe= n in > Alfons/Michael's simulations, so I would like to know the details of thei= r > policer algo. In our current draft, we have effectively a SHOULD to set the L bit not wit= h the retransmission itself, but with the next following (data) packet - at= least the text can be interpreted that way. The intention was actually to = prevent the interpretation of L-bit =3D=3D retransmission. But if the WG f= eels that explicitly marking only the actual retransmissions with L, to all= ow additional uses of the conex bits, we should spell that out more clearly= : "When a data segment is retransmitted, LEG will be increased by the size of the TCP payload packet containing the retransmission, assuming equal sized segments such that the retransmitted packet will have the same number of header as the original ones. When sending subsequent segments, the ConEx L bit is set as long as LEG is positive, and LEG is decreased by the size of the sent TCP payload with the ConEx L bit set." However, I think you have one assumption in your 4 steps above that doesn't= hold. The statement "bucket empties faster". I was under the impression, t= hat the refill ratio of the buckts is time- and packet-rate invariant, not?= With other words, within a given time t, the bucket fills up with b credit= s; if the packet rate during t, with conex marks exceeds b, the policer dro= ps; this causes the sender to reduce the packet rate - so in a given time p= eriod t, fewer packets are seen by the policier (unless the sender is not r= eactive, of course). Even when all packets sent by the sender are marked wi= th conex bits, eventually the packet rate will drop below b/t, and the poli= cer won't drop any more packets...=20 Or am I missing something there? But my issue is with the probability of dropping a packet; when the retrans= mitted data packets are dropped with a higher likelihood (and this depends = on which packets carry the L-bit, and if the way the policer implements a "= variable" drop probability depending on the conex marks), this may result i= n a higher probability of a retransmission get dropped, which will inevitab= ly lead to a RTO stall of the TCP session... Which IMHO is undesirable (los= s of ACK clock, significant latency etc). For that reason, I believe we must have understanding which packets should = carry the L-bits (only retransmissions, regular data and retransmissions), = and if packets carrying conex marks should be treated any different from pa= ckets being merely conex-enabled... Best regards, Richard Scheffenegger