From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Feb 12 03:39:26 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820ED1A095E for ; Wed, 12 Feb 2014 03:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3ZqEFNv2zGa for ; Wed, 12 Feb 2014 03:39:24 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEF11A0969 for ; Wed, 12 Feb 2014 03:39:23 -0800 (PST) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 504A160247; Wed, 12 Feb 2014 12:39:21 +0100 (CET) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 4D2DA60246; Wed, 12 Feb 2014 12:39:21 +0100 (CET) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: conex@ietf.org Date: Wed, 12 Feb 2014 12:39:21 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201402121239.21145.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: [conex] Preferential Drop X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 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, 12 Feb 2014 11:39:26 -0000 Hi group, I'm currently integrating text from the re-ECN documents on preferential drop into the IPv6 CDO draft. Find the references from the re-ECN drafts here: http://tools.ietf.org/html/draft-briscoe-conex-re-ecn-tcp-02#section-5.3 http://tools.ietf.org/html/draft-briscoe-conex-re-ecn-motiv-02#section-5.1 Here is my current text: "7. DDoS mitigation by using preferential drop If a router queue experiences very high load so that it has to drop arriving packets, it MAY preferentially drop packets within the same Diffserv PHB using the preference order given in Table 1 (1 means drop first). Additionally, if a router implements preferential drop it SHOULD also support ECN-marking. Preferential dropping can be difficult to implement on some hardware, but if feasible it would discriminate against attack traffic if done as part of the overall policing framework as described in [RFC6789]. If nowhere else, routers at the egress of a network SHOULD implement preferential drop (stronger than the MAY above). +----------------------+------------+ | | Preference | +----------------------+------------+ | Not-ConEx or no CDO | 1 | | X (but not L,E or C) | 2 | | X and L,E or C | 3 | +----------------------+------------+ Table 1: Drop preference for ConEx packets A flooding attack is inherently about congestion of a resource. As load focuses on a victim, upstream queues grow, requiring honest sources to pre-load packets with a higher fraction of ConEx-marks. If ECN marking is supported by the downstream queues preferential dropping provides the most benefits because if the queue is so congested that it drops traffic, it will be CE-marking 100% of the forwarded traffic. Honest sources will therefore be sending 100% ConEx E-marked packets (and therefore being rate-limited at an ingress policer). Senders under malicious control can either do the same as honest sources, and be rate-limited at ingress, or they can understate congestion. If the preferential drop ranking is implemented on queues, these queues will preserve E/L-marked traffic until last. So, the traffic from malicious sources will all be automatically dropped first. Either way, the malicious sources cannot send more than honest sources." The text in the re-ECN drafts assumes that a ConEx/re-ECN-capable router will automatically also support ECN. The preferential drop works best if the router uses ECN, because such a router will mark all packets before anything gets dropped. If the router is not ECN-capable, it still might help but not that much. Thus I added the following sentence: "if a router implements preferential drop it SHOULD also support ECN-marking" Not sure if I should write something like this because requiring to support ECN might stop people from implementing the preferential drop. On the otherhand ECN support would be helpful for ConEx anyway. But without a deployed accurate ECN it's kind of useless.... Any thoughts? Mirja From Dirk.Kutscher@neclab.eu Wed Feb 12 04:37:20 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15351A0980 for ; Wed, 12 Feb 2014 04:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.85 X-Spam-Level: X-Spam-Status: No, score=-2.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfRW4afmN-qQ for ; Wed, 12 Feb 2014 04:37:16 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 378C71A094E for ; Wed, 12 Feb 2014 04:37:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id CC12C106C60; Wed, 12 Feb 2014 13:37:14 +0100 (CET) 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 vUHeFS0M1p0u; Wed, 12 Feb 2014 13:37:14 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id AE1D4106C5C; Wed, 12 Feb 2014 13:37:04 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.233]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 12 Feb 2014 13:37:03 +0100 From: Dirk Kutscher To: =?iso-8859-1?Q?Mirja_K=FChlewind?= , "conex@ietf.org" Thread-Topic: [conex] Preferential Drop Thread-Index: AQHPJ+cgXfcD/bG/90a7ixHqdnhgRJqxi3aQ Date: Wed, 12 Feb 2014 12:36:42 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F52496398E780@PALLENE.office.hd> References: <201402121239.21145.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201402121239.21145.mirja.kuehlewind@ikr.uni-stuttgart.de> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.204] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [conex] Preferential Drop X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 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, 12 Feb 2014 12:37:20 -0000 Hi, Thanks. Just a few comments: - it's probably useful to state in the table that "1" =3D=3D top priority - "... it MAY preferentially drop packets" -- I actually think this should = read "it SHOULD preferentially drop packet" -- we want to recommend it -- n= ot say that it is really optional. (You would need to change the parenthese= s later in the text then, too...) - I don't think we need "if a router implements preferential drop it SHOULD= also support ECN-marking" -- it's kind of implicit. The text later also se= ems to assume that ECN is implemented anyway. Dirk > -----Original Message----- > From: conex [mailto:conex-bounces@ietf.org] On Behalf Of Mirja K=FChlewin= d > Sent: Mittwoch, 12. Februar 2014 12:39 > To: conex@ietf.org > Subject: [conex] Preferential Drop >=20 > Hi group, >=20 > I'm currently integrating text from the re-ECN documents on preferential > drop into the IPv6 CDO draft. >=20 > Find the references from the re-ECN drafts here: > http://tools.ietf.org/html/draft-briscoe-conex-re-ecn-tcp-02#section-5.3 > http://tools.ietf.org/html/draft-briscoe-conex-re-ecn-motiv-02#section-5.= 1 >=20 > Here is my current text: > "7. DDoS mitigation by using preferential drop >=20 > If a router queue experiences very high load so that it has to drop > arriving packets, it MAY preferentially drop packets within the same > Diffserv PHB using the preference order given in Table 1 (1 means > drop first). Additionally, if a router implements preferential drop > it SHOULD also support ECN-marking. Preferential dropping can be > difficult to implement on some hardware, but if feasible it would > discriminate against attack traffic if done as part of the overall > policing framework as described in [RFC6789]. If nowhere else, > routers at the egress of a network SHOULD implement preferential drop > (stronger than the MAY above). >=20 > +----------------------+------------+ > | | Preference | > +----------------------+------------+ > | Not-ConEx or no CDO | 1 | > | X (but not L,E or C) | 2 | > | X and L,E or C | 3 | > +----------------------+------------+ >=20 > Table 1: Drop preference for ConEx packets >=20 > A flooding attack is inherently about congestion of a resource. As > load focuses on a victim, upstream queues grow, requiring honest > sources to pre-load packets with a higher fraction of ConEx-marks. >=20 > If ECN marking is supported by the downstream queues preferential > dropping provides the most benefits because if the queue is so > congested that it drops traffic, it will be CE-marking 100% of the > forwarded traffic. Honest sources will therefore be sending 100% > ConEx E-marked packets (and therefore being rate-limited at an > ingress policer). Senders under malicious control can either do the > same as honest sources, and be rate-limited at ingress, or they can > understate congestion. If the preferential drop ranking is > implemented on queues, these queues will preserve E/L-marked traffic > until last. So, the traffic from malicious sources will all be > automatically dropped first. Either way, the malicious sources > cannot send more than honest sources." >=20 > The text in the re-ECN drafts assumes that a ConEx/re-ECN-capable router > will automatically also support ECN. The preferential drop works best if = the > router uses ECN, because such a router will mark all packets before anyth= ing > gets dropped. If the router is not ECN-capable, it still might help but n= ot that > much. Thus I added the following sentence: > "if a router implements preferential drop it SHOULD also support ECN- > marking" >=20 > Not sure if I should write something like this because requiring to suppo= rt > ECN might stop people from implementing the preferential drop. On the > otherhand ECN support would be helpful for ConEx anyway. But without a > deployed accurate ECN it's kind of useless.... >=20 > Any thoughts? >=20 > Mirja >=20 >=20 > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From nobody Fri Feb 14 02:44:00 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722741A0201 for ; Fri, 14 Feb 2014 02:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wA9OUmh_FgO for ; Fri, 14 Feb 2014 02:43:55 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6AA1A013B for ; Fri, 14 Feb 2014 02:43:54 -0800 (PST) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 980FD602A0; Fri, 14 Feb 2014 11:43:52 +0100 (CET) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 94FCD6029F; Fri, 14 Feb 2014 11:43:52 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: Dirk Kutscher Date: Fri, 14 Feb 2014 11:43:52 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201402121239.21145.mirja.kuehlewind@ikr.uni-stuttgart.de> <82AB329A76E2484D934BBCA77E9F52496398E780@PALLENE.office.hd> In-Reply-To: <82AB329A76E2484D934BBCA77E9F52496398E780@PALLENE.office.hd> 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: <201402141143.52367.mirja.kuehlewind@ikr.uni-stuttgart.de> Archived-At: http://mailarchive.ietf.org/arch/msg/conex/bEF0hhlU_JXd5z8cvxvsvevdOK4 Cc: "conex@ietf.org" Subject: Re: [conex] Preferential Drop X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2014 10:43:58 -0000 Hi Dirk, thanks for your feedback. Please see in line... On Wednesday 12 February 2014 13:36:42 Dirk Kutscher wrote: > Hi, > > Thanks. Just a few comments: > > - it's probably useful to state in the table that "1" =3D=3D top priority It's in the text, but I will also but it in the table. > > - "... it MAY preferentially drop packets" -- I actually think this should > read "it SHOULD preferentially drop packet" -- we want to recommend it -- > not say that it is really optional. (You would need to change the > parentheses later in the text then, too...) That was intended to have to really optional. There is not need to implemen= t=20 preferential drop to have ConEx working. It only to potentially have some=20 additional benefits if desired be the operator...=20 Moreover, it might be quite complicated to implement preferential drop into= =20 existing architectures (we had this discussion recently on the rmcat list).= =20 And we definitely don't want to keep people from using the ConEx informatio= n=20 by requiring preferential drop. > > - I don't think we need "if a router implements preferential drop it SHOU= LD > also support ECN-marking" -- it's kind of implicit. The text later also > seems to assume that ECN is implemented anyway. No, you can have preferential drop without ECN. It is just more useful with= =20 ECN and that why the later text mostly relies on assuming ECN. Thus I think= =20 if we would like to have ECN, we have to write it in the text (as it is not= =20 implicit). The question is: do we want to push ECN deployment by this? Or=20 should the decision to use ECN be taken as independent. Because then, the=20 text would read like: "If ECN is also (already) supported, this mechanism=20 provides better DDoS migration..." or something like this.... Mirja > > Dirk > > > -----Original Message----- > > From: conex [mailto:conex-bounces@ietf.org] On Behalf Of Mirja K=FChlew= ind > > Sent: Mittwoch, 12. Februar 2014 12:39 > > To: conex@ietf.org > > Subject: [conex] Preferential Drop > > > > Hi group, > > > > I'm currently integrating text from the re-ECN documents on preferential > > drop into the IPv6 CDO draft. > > > > Find the references from the re-ECN drafts here: > > http://tools.ietf.org/html/draft-briscoe-conex-re-ecn-tcp-02#section-5.3 > > http://tools.ietf.org/html/draft-briscoe-conex-re-ecn-motiv-02#section-= 5. > >1 > > > > Here is my current text: > > "7. DDoS mitigation by using preferential drop > > > > If a router queue experiences very high load so that it has to drop > > arriving packets, it MAY preferentially drop packets within the same > > Diffserv PHB using the preference order given in Table 1 (1 means > > drop first). Additionally, if a router implements preferential drop > > it SHOULD also support ECN-marking. Preferential dropping can be > > difficult to implement on some hardware, but if feasible it would > > discriminate against attack traffic if done as part of the overall > > policing framework as described in [RFC6789]. If nowhere else, > > routers at the egress of a network SHOULD implement preferential drop > > (stronger than the MAY above). > > > > +----------------------+------------+ > > > > | | Preference | > > > > +----------------------+------------+ > > > > | Not-ConEx or no CDO | 1 | > > | X (but not L,E or C) | 2 | > > | X and L,E or C | 3 | > > > > +----------------------+------------+ > > > > Table 1: Drop preference for ConEx packets > > > > A flooding attack is inherently about congestion of a resource. As > > load focuses on a victim, upstream queues grow, requiring honest > > sources to pre-load packets with a higher fraction of ConEx-marks. > > > > If ECN marking is supported by the downstream queues preferential > > dropping provides the most benefits because if the queue is so > > congested that it drops traffic, it will be CE-marking 100% of the > > forwarded traffic. Honest sources will therefore be sending 100% > > ConEx E-marked packets (and therefore being rate-limited at an > > ingress policer). Senders under malicious control can either do the > > same as honest sources, and be rate-limited at ingress, or they can > > understate congestion. If the preferential drop ranking is > > implemented on queues, these queues will preserve E/L-marked traffic > > until last. So, the traffic from malicious sources will all be > > automatically dropped first. Either way, the malicious sources > > cannot send more than honest sources." > > > > The text in the re-ECN drafts assumes that a ConEx/re-ECN-capable router > > will automatically also support ECN. The preferential drop works best if > > the router uses ECN, because such a router will mark all packets before > > anything gets dropped. If the router is not ECN-capable, it still might > > help but not that much. Thus I added the following sentence: > > "if a router implements preferential drop it SHOULD also support ECN- > > marking" > > > > Not sure if I should write something like this because requiring to > > support ECN might stop people from implementing the preferential drop. = On > > the otherhand ECN support would be helpful for ConEx anyway. But without > > a deployed accurate ECN it's kind of useless.... > > > > Any thoughts? > > > > Mirja > > > > > > _______________________________________________ > > 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 nobody Fri Feb 14 06:07:45 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516C31A0255; Fri, 14 Feb 2014 06:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yg-31f7u6OFU; Fri, 14 Feb 2014 06:07:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3201A0250; Fri, 14 Feb 2014 06:07:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214140736.22981.78307.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 06:07:36 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/FZe50dk2TgYSNclvtolYO7PJoUc Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-mobile-03.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 14:07:42 -0000 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. Title : Mobile Communication Congestion Exposure Scenario Authors : Dirk Kutscher Faisal Ghias Mir Rolf Winter Suresh Krishnan Ying Zhang Carlos J. Bernardos Filename : draft-ietf-conex-mobile-03.txt Pages : 25 Date : 2014-02-14 Abstract: This memo describes a mobile communications use case for congestion exposure (CONEX) with a particular focus on mobile communication networks such as the 3GPP Evolved Packet System (EPS). The draft provides a brief overview of the architecture of these networks (both access and core networks), current QoS mechanisms and then discusses how congestion exposure concepts could be applied. Based on this, this memo suggests a set of requirements for CONEX mechanisms that particularly apply to mobile networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-conex-mobile/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-conex-mobile-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-conex-mobile-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 08:32:45 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2674A1A02D9; Fri, 14 Feb 2014 08:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aR4sHICUZWO3; Fri, 14 Feb 2014 08:32:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BBDC11A02FB; Fri, 14 Feb 2014 08:32:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214163236.6602.39157.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 08:32:36 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/W0xrTbLg4z55aj8CNT3G8K9MFEU Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-destopt-06.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 16:32:40 -0000 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. Title : IPv6 Destination Option for ConEx Authors : Suresh Krishnan Mirja Kuehlewind Carlos Ralli Ucendo Filename : draft-ietf-conex-destopt-06.txt Pages : 8 Date : 2014-02-14 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-conex-destopt/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-conex-destopt-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-conex-destopt-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 08:43:03 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FFD1A02CC; Fri, 14 Feb 2014 08:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veGdRzuzQz4v; Fri, 14 Feb 2014 08:42:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAA71A02D0; Fri, 14 Feb 2014 08:42:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214164253.28397.10349.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 08:42:53 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/wuqLF7Cwwc1FT_T2pBaebz4Urf8 Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-tcp-modifications-05.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 16:42:58 -0000 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. Title : TCP modifications for Congestion Exposure Authors : Mirja Kuehlewind Richard Scheffenegger Filename : draft-ietf-conex-tcp-modifications-05.txt Pages : 14 Date : 2014-02-14 Abstract: 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). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-conex-tcp-modifications/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-conex-tcp-modifications-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-conex-tcp-modifications-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 14:33:10 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60221A00A7; Fri, 14 Feb 2014 14:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tym68ORor1RJ; Fri, 14 Feb 2014 14:33:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9391A01DD; Fri, 14 Feb 2014 14:33:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214223302.19374.71847.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 14:33:02 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/QT0IYoBWuy7Qz-snhAHdtygwJY8 Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-abstract-mech-09.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 22:33:07 -0000 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. Title : Congestion Exposure (ConEx) Concepts and Abstract Mechanism Authors : Matt Mathis Bob Briscoe Filename : draft-ietf-conex-abstract-mech-09.txt Pages : 29 Date : 2014-02-14 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-conex-abstract-mech/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-conex-abstract-mech-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-conex-abstract-mech-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 17 02:56:36 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C200E1A0483 for ; Mon, 17 Feb 2014 02:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThsMRcaXYdce for ; Mon, 17 Feb 2014 02:56:31 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 33E911A0482 for ; Mon, 17 Feb 2014 02:56:29 -0800 (PST) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id AD54F600DA for ; Mon, 17 Feb 2014 11:56:26 +0100 (CET) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id AA78A600D9 for ; Mon, 17 Feb 2014 11:56:26 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: conex@ietf.org Date: Mon, 17 Feb 2014 11:56:26 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <20140214164253.28397.10349.idtracker@ietfa.amsl.com> In-Reply-To: <20140214164253.28397.10349.idtracker@ietfa.amsl.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: <201402171156.26472.mirja.kuehlewind@ikr.uni-stuttgart.de> Archived-At: http://mailarchive.ietf.org/arch/msg/conex/rNIk6eQ6BQ3ZGrndU6dR4btzkbc Subject: Re: [conex] I-D Action: draft-ietf-conex-tcp-modifications-05.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 10:56:35 -0000 Hi, we updated the TCP mods draft to comply with the new credit definition. The= re=20 are lots of changes in sections 3.1.2 (Classic ECN support), 3.2. (Loss=20 Detection) and 4.2 (Credit Bits). Thus would be great if people would have= =20 time to review this version! Thanks, Mirja On Friday 14 February 2014 17:42:53 internet-drafts@ietf.org wrote: > 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. > > Title : TCP modifications for Congestion Exposure > Authors : Mirja Kuehlewind > Richard Scheffenegger > Filename : draft-ietf-conex-tcp-modifications-05.txt > Pages : 14 > Date : 2014-02-14 > > Abstract: > 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). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-conex-tcp-modifications/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-conex-tcp-modifications-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-conex-tcp-modifications-05 > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 nobody Thu Feb 20 03:13:49 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090A61A00D1 for ; Thu, 20 Feb 2014 03:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKLS2PyThZs1 for ; Thu, 20 Feb 2014 03:13:45 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 97E7E1A00AB for ; Thu, 20 Feb 2014 03:13:44 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 1A0D518C72F; Thu, 20 Feb 2014 12:13:40 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id F41D335C05A; Thu, 20 Feb 2014 12:13:39 +0100 (CET) Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Thu, 20 Feb 2014 12:13:39 +0100 From: To: Mirja Kuehlewind , "conex@ietf.org" Thread-Topic: [conex] I-D Action: draft-ietf-conex-tcp-modifications-05.txt Thread-Index: AQHPKaPkPbfww6plCE6zRkfeaL6dEZq5OcMAgASsbbA= Date: Thu, 20 Feb 2014 11:13:39 +0000 Message-ID: <2926_1392894820_5305E364_2926_4613_1_2A32CB6629A19041BF4DB7796AD0F5E70A2318DA@PEXCVZYM14.corporate.adroot.infra.ftgroup> References: <20140214164253.28397.10349.idtracker@ietfa.amsl.com> <201402171156.26472.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201402171156.26472.mirja.kuehlewind@ikr.uni-stuttgart.de> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.20.100315 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/qrRd77WuFPzKUPej2ZVZvTGSahw Subject: Re: [conex] I-D Action: draft-ietf-conex-tcp-modifications-05.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 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, 20 Feb 2014 11:13:48 -0000 Hi, I think there might be a problem with the use of DeliveredData without SACK= to increase the CEG. DeliveredData is estimated as follows: DeliveredData =3D acked_bytes + SACK_diff + (is_dup)*1SMSS - (is_after_dup)= *num_dup*1SMSS is_dup =3D 1 if the current ACK is a duplicated ACK is_after_dup =3D 1 for the next full or partial ACK after a number of dupl= icated ACKs num_dup counts the number of duplicated ACKs in a row If a sender loses more than one packet in a row (let's suppose 2 dropped pa= ckets), the ACK he will receive from retransmitting the first dropped packe= t will be a partial ack (if no delayed acks are used or if this segment tri= ggered the ACK). We will then have: acked_bytes =3D 1 packet (Only the first retransmitted packet because it di= dn't fill the whole gap) SACK_diff =3D 0 (No SACK used) is_dup =3D 0 is_after_dup =3D 1 num_dup >=3D 3 packets (Let's suppose 4 duplicate ACKs) Hence DeliveredData =3D -3 and the operation CEG +=3D min(SMSS*D, Delivered= Data) will decrease the CEG. When the ACK for the second dropped packet will arrive, it will be a full A= CK because it will fill the gap there was. We will then have: acked_bytes =3D 5 packets (the second dropped packet + the packets from the= 4 duplicate ACKs) SACK_diff =3D 0 (No SACK used) is_dup =3D 0 is_after_dup =3D 0 num_dup =3D 0 packets Hence DeliveredData =3D 5 and the operation CEG +=3D min(SMSS*D, DeliveredD= ata) will limit CEG by SMSS*D which should cover the number of CE marks sin= ce the last ACK and in our case it shouldn't be more than 1 (in fact in sho= uld be 0 since the retransmitted packets mustn't be marked as specified in = RFC3168). When we sum up all the DeliveredData calculated, the result is coherent onc= e we receive the full ACK. DeliveredData then covers all data (-3+5 =3D 2 r= etransmitted packets). But because we do the min() operation on every ACK, = we may have a negative outcome on a partial ACK which will not be rebalance= d on the full ACK and we will potentially lose a number of marks, which cou= ld be substantial if the congestion window is big. We can solve this problem by subtracting num_dup from DeliveredData only on= full ACKs. This way, DeliveredData will be positive in every step and the = min() operation will not lose potential marks. But there is another case wh= ere this solution will lead us to the same problem as before. It's when we = have two or more losses in the same window that are noncontiguous. The rece= ipt of the ACK from the first retransmitted packet will give us a positive = DeliveredData if we don't subtract num_dup on partial ACKs, but if upon the= receipt of the full ACK, the number of acked bytes by this ACK is less tha= n num_dup*SMSS, we will get a negative DeliveredData once again. We have other solutions that we can apply. We can say that CEG +=3D min(D*S= MSS, max(0,DeliveredData)). We don't increase CEG if DeliveredData is negat= ive and hope we can retrieve the cumulative D*SMSS from the next ACK. The A= CK triggered from the arrival of a retransmitted packet shouldn't contain a= new congestion indication since a retransmitted packet can't be CE marked.= It can only contain the congestion marks from the previously received pack= ets. We can also, upon a partial ACK, subtract from acked_bytes only the number = of dups that are between a lost packet and the next lost packet, this numbe= r of dups should equal acked_bytes - 1*SMSS (1 for the retransmitted packet= ). I hope I didn't misunderstand the use of DeliveredData. I also have a remark about the credit bits in 4.2. You say that the sender = should send as much credits as there are packets in flight. This should avo= id sanctions in the auditor side indeed. But if we use a congestion policer= and we remove tokens when a credit packet is forwarded as described in dra= ft-ietf-conex-abstract-mech-09, the sender may consume many of his resource= s by sending credits even if there is no congestion ahead. This is penalizi= ng the sender even though he will not contribute to congestion. I understan= d that the credits are defined for auditing purposes and it shouldn't rely = on the design of the policer used to manage traffic. Nonetheless, policing = the senders is what makes ConEx useful. We can imagine that we may not use the credits in the policer. If we use, i= n the auditor side, a balance with CE marks in one side and Re-echo and Cre= dit in the other side, this will push the user to send credits rather than = re-echo marks to not consume tokens in the policer. The sender will eventua= lly get penalized by the auditor if we use two balances, the first with CE = marks and Re-echo marks and the second with CE marks and Credit, but the da= mage to the network will be done as the auditor should be placed after the = potential bottlenecks, and this misbehaving sender will have impacted the o= ther users with his traffic. With regards, Ali -----Message d'origine----- De=A0: conex [mailto:conex-bounces@ietf.org] De la part de Mirja Kuehlewind Envoy=E9=A0: lundi 17 f=E9vrier 2014 11:56 =C0=A0: conex@ietf.org Objet=A0: Re: [conex] I-D Action: draft-ietf-conex-tcp-modifications-05.txt Hi, we updated the TCP mods draft to comply with the new credit definition. The= re are lots of changes in sections 3.1.2 (Classic ECN support), 3.2. (Loss Detection) and 4.2 (Credit Bits). Thus would be great if people would have = time to review this version! Thanks, Mirja On Friday 14 February 2014 17:42:53 internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. This draft is a work item of the Congestion Exposure=20 > Working Group of the IETF. > > Title : TCP modifications for Congestion Exposure > Authors : Mirja Kuehlewind > Richard Scheffenegger > Filename : draft-ietf-conex-tcp-modifications-05.txt > Pages : 14 > Date : 2014-02-14 > > Abstract: > 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). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-conex-tcp-modifications/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-conex-tcp-modifications-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-conex-tcp-modifications-05 > > > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at=20 > tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex -- ------------------------------------------------------------------- Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) Universi= ty 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 ------------------------------------------------------------------- _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Fri Feb 28 04:47:20 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEE31A008D for ; Fri, 28 Feb 2014 04:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.697 X-Spam-Level: X-Spam-Status: No, score=-0.697 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekjrGsyC_Zcr for ; Fri, 28 Feb 2014 04:47:13 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3128E1A0068 for ; Fri, 28 Feb 2014 04:47:13 -0800 (PST) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 90674601CA for ; Fri, 28 Feb 2014 13:47:09 +0100 (CET) Received: from vpn-2-cl181 (vpn-2-cl181 [10.41.21.181]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 8D5C1601C9 for ; Fri, 28 Feb 2014 13:47:09 +0100 (CET) From: David Wagner Organization: University of Stuttgart (Germany), IKR To: conex@ietf.org Date: Fri, 28 Feb 2014 13:47:08 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201402281347.08978.david.wagner@ikr.uni-stuttgart.de> Archived-At: http://mailarchive.ietf.org/arch/msg/conex/PQ_taPHqTEWvPZx4sjcN_iZs29M Subject: [conex] Fwd: New Version Notification for draft-wagner-conex-audit-01.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 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, 28 Feb 2014 12:47:17 -0000 Hi, we also updated the draft on ConEx Auditing. We included a more detailed description on which flow state needs to be maintained by the auditor and on how penalities should be defined. Comments would be great! Thanks, David ---------- Forwarded Message ---------- Subject: New Version Notification for draft-wagner-conex-audit-01.txt Date: Friday 14 February 2014, 20:10:35 From: internet-drafts@ietf.org To: David Wagner , Mirja Kuehlewind , "David Wagner" , "Mirja Kuehlewind" A new version of I-D, draft-wagner-conex-audit-01.txt has been successfully submitted by Mirja Kuehlewind and posted to the IETF repository. Name: draft-wagner-conex-audit Revision: 01 Title: Auditing of Congestion Exposure (ConEx) signals Document date: 2014-02-14 Group: Individual Submission Pages: 9 URL: http://www.ietf.org/internet-drafts/draft-wagner-conex-audit-01.txt Status: https://datatracker.ietf.org/doc/draft-wagner-conex-audit/ Htmlized: http://tools.ietf.org/html/draft-wagner-conex-audit-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-wagner-conex-audit-01 Abstract: Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by previous packets on the same flow. Reliable auditing is necessary to provide a strong incentive to declare ConEx information honestly. This document defines how the signals are handled by an audit and lists requirements for an audit implementation. This document does not mandate a particular design but identifies state and functions that any auditor element must provide to fullfil the requirements stated in [draft-ietf-conex-abstract-mech]. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ------------------------------------------------------- -- Dipl.-Inf. David Wagner Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart Pfaffenwaldring 47, D-70569 Stuttgart, Germany web: www.ikr.uni-stuttgart.de email: david.wagner@ikr.uni-stuttgart.de phone: +49 711 685-67965 fax: +49 711 685-57965 -------------------------------------------------------------------