From mirja.kuehlewind@ikr.uni-stuttgart.de Mon Apr 2 04:23: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 EDE9821F88A0 for ; Mon, 2 Apr 2012 04:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_DE=0.35] 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 i3fI2-rtQjDr for ; Mon, 2 Apr 2012 04:23:08 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id D6A2621F889F for ; Mon, 2 Apr 2012 04:23:04 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 10FBE633B1; Mon, 2 Apr 2012 13:23:03 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 0181959A8A; Mon, 2 Apr 2012 13:23:02 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: conex@ietf.org Date: Mon, 2 Apr 2012 13:23:02 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201203311403.q2VE3oQE016770@bagheera.jungle.bt.co.uk> <012C3117EDDB3C4781FD802A8C27DD4F1428A3@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F1428A3@SACEXCMBX02-PRD.hq.netapp.com> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201204021323.02141.mirja.kuehlewind@ikr.uni-stuttgart.de> 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: Mon, 02 Apr 2012 11:23:09 -0000 Hi Richard, hi Bob, my concern with a policy that drops (only) marked packets is, that the=20 congestion exposure signal get corrupted and thus the audit will see too=20 little ConEx markings and thus might drop additional packets. In the=20 simulation this was no problem as there was not audit. Should we add somewhere a recommendation that ConEx marked packets should=20 preferably be not dropped (if another packet is available to drop) as those= =20 packets carry additional information? Mirja On Saturday 31 March 2012 19:56:45 Scheffenegger, Richard wrote: > Hi Bob, > > > Richard Scheffenegger > > > 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. > > In our current draft, we have effectively a SHOULD to set the L bit not > with 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 > feels that explicitly marking only the actual retransmissions with L, to > allow 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, > that 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 > credits; if the packet rate during t, with conex marks exceeds b, the > policer drops; this causes the sender to reduce the packet rate - so in a > given time period t, fewer packets are seen by the policier (unless the > sender is not reactive, of course). Even when all packets sent by the > sender are marked with conex bits, eventually the packet rate will drop > below b/t, and the policer won't drop any more packets... > > Or am I missing something there? > > > But my issue is with the probability of dropping a packet; when the > retransmitted 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 in a higher probability of a retransmission get dropped, > which will inevitably lead to a RTO stall of the TCP session... Which IMHO > is undesirable (loss 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 > packets being merely conex-enabled... > > > Best regards, > Richard Scheffenegger > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From rs@netapp.com Mon Apr 2 13:41: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 E5C2821F86FA for ; Mon, 2 Apr 2012 13:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.088 X-Spam-Level: X-Spam-Status: No, score=-10.088 tagged_above=-999 required=5 tests=[AWL=0.511, 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 qkk7TbyAKVip for ; Mon, 2 Apr 2012 13:41:12 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7F23121F8685 for ; Mon, 2 Apr 2012 13:41:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,358,1330934400"; d="scan'208";a="638072769" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 02 Apr 2012 13:41:02 -0700 Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q32Kf0TQ004057; Mon, 2 Apr 2012 13:41:01 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.76]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0247.003; Mon, 2 Apr 2012 13:40:52 -0700 From: "Scheffenegger, Richard" To: Mirja Kuehlewind , "conex@ietf.org" Thread-Topic: [conex] Comments on ConEx TCP Modifications Thread-Index: AQHNDNtTba2T0AMdn0iF2+wPmf3O0JZ/sT1AgATDQA+AADd8EIADNZcAgAAQK5A= Date: Mon, 2 Apr 2012 20:40:50 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F1533CF@SACEXCMBX02-PRD.hq.netapp.com> References: <201203311403.q2VE3oQE016770@bagheera.jungle.bt.co.uk> <012C3117EDDB3C4781FD802A8C27DD4F1428A3@SACEXCMBX02-PRD.hq.netapp.com> <201204021323.02141.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201204021323.02141.mirja.kuehlewind@ikr.uni-stuttgart.de> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Mon, 02 Apr 2012 20:41:14 -0000 Also a very valid concern! If there is a preferential treatment to either type of packets (conex-marke= d or conex-enabled), retransmissions from TCP should be put in the category= that is less likely to be dropped. I believe the reason for the current te= xt around L-marks was to avoid the notion of L-Mark =3D=3D Retransmission. = However, explicitly exposing retransmissions may not be such a bad idea aft= er all, thinking further about this... But that would imply that conex-mark= ed packets get dropped with the same or lower probability as conex-enabled = packets. Nevertheless, avoiding slightly increased drop probabilities (vs. overall d= rop probability) for retransmissions is a more important aspect from the TC= P point of view... However we achieve that; treating all packets equal woul= d be good enough (equal to current state of affairs). If retransmissions are dropped with lower probability, that should statisti= cally noticeable in lower total RTOs. Best regards,=20 Richard Scheffenegger > -----Original Message----- > From: Mirja Kuehlewind [mailto:mirja.kuehlewind@ikr.uni-stuttgart.de] > Sent: Montag, 02. April 2012 13:23 > To: conex@ietf.org > Cc: Scheffenegger, Richard; Bob Briscoe > Subject: Re: [conex] Comments on ConEx TCP Modifications >=20 > Hi Richard, hi Bob, >=20 > my concern with a policy that drops (only) marked packets is, that the > congestion exposure signal get corrupted and thus the audit will see too = little > ConEx markings and thus might drop additional packets. In the simulation = this > was no problem as there was not audit. >=20 > Should we add somewhere a recommendation that ConEx marked packets > should preferably be not dropped (if another packet is available to drop)= as > those packets carry additional information? >=20 > Mirja >=20 >=20 > On Saturday 31 March 2012 19:56:45 Scheffenegger, Richard wrote: > > Hi Bob, > > > > > > Richard Scheffenegger > > > > > 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. > > > > In our current draft, we have effectively a SHOULD to set the L bit > > not with 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 feels that explicitly marking only the > > actual retransmissions with L, to allow 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 bi= t > > 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, that 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 credits; if the packet rate during t, with > > conex marks exceeds b, the policer drops; this causes the sender to > > reduce the packet rate - so in a given time period t, fewer packets > > are seen by the policier (unless the sender is not reactive, of > > course). Even when all packets sent by the sender are marked with > > conex bits, eventually the packet rate will drop below b/t, and the pol= icer > won't drop any more packets... > > > > Or am I missing something there? > > > > > > But my issue is with the probability of dropping a packet; when the > > retransmitted 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 in a higher probability of a > > retransmission get dropped, which will inevitably lead to a RTO stall > > of the TCP session... Which IMHO is undesirable (loss 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 packets being merely conex-enabled... > > > > > > Best regards, > > Richard Scheffenegger > > > > _______________________________________________ > > conex mailing list > > conex@ietf.org > > https://www.ietf.org/mailman/listinfo/conex >=20 >=20 >=20 > -- > ------------------------------------------------------------------- > Dipl.-Ing. Mirja K=FChlewind > Institute of Communication Networks and Computer Engineering (IKR) > University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart >=20 > tel: +49(0)711/685-67973 > email: mirja.kuehlewind@ikr.uni-stuttgart.de > web: www.ikr.uni-stuttgart.de > ------------------------------------------------------------------- From bob.briscoe@bt.com Wed Apr 4 10:51: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 F2F1721F87D5 for ; Wed, 4 Apr 2012 10:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=0.700, 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 z4KsizOhqeMb for ; Wed, 4 Apr 2012 10:51:18 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 5040421F87D4 for ; Wed, 4 Apr 2012 10:51:18 -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; Wed, 4 Apr 2012 18:51:17 +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; Wed, 4 Apr 2012 18:51:14 +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; Wed, 4 Apr 2012 18:51:09 +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 1333561884400; Wed, 4 Apr 2012 18:51:24 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q34Hp4mU006010; Wed, 4 Apr 2012 18:51:04 +0100 Message-ID: <201204041751.q34Hp4mU006010@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 4 Apr 2012 18:51:07 +0100 To: Marcelo BAGNULO BRAUN 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 Cc: ConEx IETF list Subject: [conex] Splitting up conex-intial-deploy: effect on concepts-uses 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, 04 Apr 2012 17:51:19 -0000 Marcelo, I just noticed that conex-concepts-uses refers to conex-intial-deploy as a convenient catch-all for all the deployment arrangements. Given we have decided to split-up intial-deploy, we will need to update the citation in concepts-uses, to instead point to a number of refs to various deployment arrangements. These are all currently individual drafts. Are you still happy for me to proceed with splitting up initial-deploy? Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From marcelo@it.uc3m.es Wed Apr 4 13:18:25 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 CCADD11E80FA for ; Wed, 4 Apr 2012 13:18:25 -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 gS2Tw0eUNTzW for ; Wed, 4 Apr 2012 13:18:25 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 2FEC011E8099 for ; Wed, 4 Apr 2012 13:18:24 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (18.8.218.87.dynamic.jazztel.es [87.218.8.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id C438B75A73B; Wed, 4 Apr 2012 22:18:22 +0200 (CEST) Message-ID: <4F7CAC8D.5000804@it.uc3m.es> Date: Wed, 04 Apr 2012 22:18:21 +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: Bob Briscoe References: <201204041751.q34Hp4mU006010@bagheera.jungle.bt.co.uk> In-Reply-To: <201204041751.q34Hp4mU006010@bagheera.jungle.bt.co.uk> 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-18818.000 Cc: ConEx IETF list Subject: Re: [conex] Splitting up conex-intial-deploy: effect on concepts-uses 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, 04 Apr 2012 20:18:25 -0000 Yes, go ahead, we can easily fix that in the new version after the IESG review (or in auth48 if needed) El 04/04/12 19:51, Bob Briscoe escribió: > Marcelo, > > I just noticed that conex-concepts-uses refers to conex-intial-deploy > as a convenient catch-all for all the deployment arrangements. > > Given we have decided to split-up intial-deploy, we will need to > update the citation in concepts-uses, to instead point to a number of > refs to various deployment arrangements. These are all currently > individual drafts. > > Are you still happy for me to proceed with splitting up initial-deploy? > > > Bob > > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > From bob.briscoe@bt.com Tue Apr 24 11:57: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 6F72721E809D for ; Tue, 24 Apr 2012 11:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.108 X-Spam-Level: X-Spam-Status: No, score=-3.108 tagged_above=-999 required=5 tests=[AWL=0.491, 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 Cyq9++ZrKCwE for ; Tue, 24 Apr 2012 11:57:40 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 23B1A21E8088 for ; Tue, 24 Apr 2012 11:57:39 -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; Tue, 24 Apr 2012 19:57: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; Tue, 24 Apr 2012 19:57: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; Tue, 24 Apr 2012 19:57:36 +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 1335293855306; Tue, 24 Apr 2012 19:57:35 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q3OIvY0v028421 for ; Tue, 24 Apr 2012 19:57:34 +0100 Message-ID: <201204241857.q3OIvY0v028421@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 24 Apr 2012 19:57:38 +0100 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] New: draft-briscoe-conex-re-ecn-tcp-00 & re-ecn-motiv-00 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, 24 Apr 2012 18:57:41 -0000 ConEx folks, You may have noticed two old re-ECN drafts just got posted with the tag in their filename changed from tsvwg to conex: * draft-briscoe-conex-re-ecn-tcp-00.txt * draft-briscoe-conex-re-ecn-motiv-00.txt This is just to reassure the list that we're not trying to get these drafts adopted. In fact in the header we've put "Intended Status: Historic", and we've put a big note in the abstract about historic status. Reasons for re-posting: a) to keep them sufficiently alive to be referenced from the conex-abstract-mech draft b) to be able to point to them from BT's patent declaration c) to bring them under the conex heading, not tsvwg d) to allow for the possibility of getting them turned into historic RFCs if the ConEx WG want that. e) identify errors and gaps so they can be carried over to ConEx work where relevant f) much of the re-ecn-motive draft is just as applicable to ConEx (mostly about audit and policing), so pls feel free to lift text into ConEx drafts if you want. We've revealed items tagged 'ToDo', that were previously only comments within the XML source. This will help people see that these drafts are incomplete, and it records potential open issues for the ConEx w-g to take on board. I did spend a couple of hours clarifying some aspects of these drafts that could otherwise cause unfamiliar readers to get confused about how they relate to current ConEx work. Full diffs from previous version: Bob >From: >To: >CC: , , >Subject: New Version Notification for draft-briscoe-conex-re-ecn-tcp-00.txt > >A new version of I-D, draft-briscoe-conex-re-ecn-tcp-00.txt has been >successfully submitted by Bob Briscoe and posted to the IETF repository. > >Filename: draft-briscoe-conex-re-ecn-tcp >Revision: 00 >Title: Re-ECN: Adding Accountability for Causing Congestion to TCP/IP >Creation date: 2012-04-22 >WG ID: Individual Submission >Number of pages: 52 > >Abstract: > This document introduces re-ECN (re-inserted explicit congestion > notification), which is intended to make a simple but far-reaching > change to the Internet architecture. The sender uses the IP header > to reveal the congestion that it expects on the end-to-end path. The > protocol works by arranging an extended ECN field in each packet so > that, as it crosses any interface in an internetwork, it will carry a > truthful prediction of congestion on the remainder of its path. It > can be deployed incrementally around unmodified routers. The purpose > of this document is to specify the re-ECN protocol at the IP layer > and to give guidelines on any consequent changes required to > transport protocols. It includes the changes required to TCP both as > an example and as a specification. It briefly gives examples of > mechanisms that can use the protocol to ensure data sources respond > sufficiently to congestion, but these are described more fully in a > companion document. > > Note concerning Intended Status: If this draft were ever published as > an RFC it would probably have historic status. There is limited > space in the IP header, so re-ECN had to compromise by requiring the > receiver to be ECN-enabled otherwise the sender could not use re-ECN. > Re-ECN was a precursor to chartering of the IETF's Congestion > Exposure (ConEx) working group, but during chartering there were > still too few ECN receivers enabled, therefore it was decided to > pursue other compromises in order to fit a similar capability into > the IP header. > > > > > >The IETF Secretariat ________________________________________________________________ Bob Briscoe, BT Innovate & Design