From acooper@cdt.org Tue Nov 1 14:32:52 2011 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 54A9C11E80F1 for ; Tue, 1 Nov 2011 14:32:52 -0700 (PDT) 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 8RHYj-gwdHcF for ; Tue, 1 Nov 2011 14:32:51 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 917C611E809C for ; Tue, 1 Nov 2011 14:32:51 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Tue, 1 Nov 2011 17:32:47 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alissa Cooper In-Reply-To: <20111025152523.GI57720@verdi> Date: Tue, 1 Nov 2011 21:32:45 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <09BA70F3-CB2D-43EF-B5CD-09276D1ADC98@cdt.org> References: <20111025104324.3865.89586.idtracker@ietfa.amsl.com> <1AE5704A-620C-46DA-B9DE-E42F9E7F356C@cdt.org> <20111025152523.GI57720@verdi> To: John Leslie X-Mailer: Apple Mail (2.1084) Cc: ConEx IETF list Subject: Re: [conex] I-D Action: draft-ietf-conex-concepts-uses-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: Tue, 01 Nov 2011 21:32:52 -0000 Hi John, Thanks for your comments. I have some responses inline and I've also = added the issues you raise to trac = (http://trac.tools.ietf.org/wg/conex/trac/report/1). On Oct 25, 2011, at 4:25 PM, John Leslie wrote: >>=20 > I have several issues which deserve discussion here. >=20 > concepts-uses still ventures farther into mechanism than I'd wish: >=20 > - "the ConEx Field" implies mechanism; I suggest "ConEx marking". Fine with me. > - "Network provider (or operator)" doesn't work as a definition: > I suggest defining "Network Operator (or Provider), and fixing > the various places which use these words ambiguously. Fine with me. >=20 > - The "User" definiton hides something a bit counter-intuitive: > that the sending user is known in some places, the receiving > user in others, and neither is knowable in the middle. While > the definiton here is probably as good as we can get, I'm > afraid our readers will be confused. If there are specific instances of "user" that you think might cause = confusion, that would be helpful to know. At least in 3.1 (where it = probably matters the most), I think it's fairly clear that the network = operator will be drawing conclusions about its own users. >=20 > - "Congestion Policer" is not defined. The editors had some discussion about whether this is necessary. If most = people think it is, we can add it. A suggestion: Congestion policer (discussed in 3.1): A logical entity that allows a = network operator to monitor each user's congestion-volume and enforce = congestion-volume limits. >=20 > - In Section 3.1, the general-case description of policer (the > second paragraph) is describing mechanism better left to a > different I-D. OTOH, the fourth and fifth paragraph are an > example appropriate for this document (especially since it > is the case found in our Charter). I think it's hard to understand the last paragraph without explaining at = a high level how a congestion policer might work. Perhaps we can split = the difference by making it more clear that the token bucket description = is an example (i.e., "one way to implement a congestion policer" instead = of "a congestion policer can be implemented"). Thanks, Alissa >=20 > -- > John Leslie >=20 From acooper@cdt.org Tue Nov 1 15:51:30 2011 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 149E41F0C6A for ; Tue, 1 Nov 2011 15:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.382 X-Spam-Level: X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 hl8mGkpOVASw for ; Tue, 1 Nov 2011 15:51:29 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC521F0C68 for ; Tue, 1 Nov 2011 15:51:27 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Tue, 1 Nov 2011 18:51:25 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alissa Cooper In-Reply-To: <20111025154215.GJ57720@verdi> Date: Tue, 1 Nov 2011 22:51:23 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7B551793-496A-406D-9E16-CC89CDA0EC2A@cdt.org> References: <20111025104324.3865.89586.idtracker@ietfa.amsl.com> <1AE5704A-620C-46DA-B9DE-E42F9E7F356C@cdt.org> <20111025154215.GJ57720@verdi> To: John Leslie X-Mailer: Apple Mail (2.1084) Cc: ConEx IETF list Subject: Re: [conex] "Congestion" vs. "Congestion Volume" 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, 01 Nov 2011 22:51:30 -0000 Hi John, Couple of comments inline -- On Oct 25, 2011, at 4:42 PM, John Leslie wrote: >>=20 >> http://www.ietf.org/id/draft-ietf-conex-concepts-uses-03.txt >=20 > This I-D defines "Congestion" and "Congestion Volume". While the > definitions are mostly right IMHO, there are inevitable problems as > the terms are used later in the document. >=20 > Inevitably we must use "level of congestion" in a few places. > Which does it refer to? I'd argue that it's not always one or the > other. In some places it's clearly bytes-on-the-wire dropped; in > others it's clearly percentage of packets dropped. I'd recommend > that we clarify that "level of congestion" may have different > meanings in different places along the path. I think there's a simpler solution -- delete "level of" in all the = places it appears. In the definition of congestion we say it _usually_ = is expressed as a percentage, therefore if we just use the term = "congestion" without "level of" I think it leaves open the possibility = of expressing it either way in all of those cases where "level of" is = currently used. >=20 > Also, we use "quotas" in a few places. The implementation of > quotas, IMHO, is unlikely to be the same everywhere. Some quotas > will count packets regardless of size; others may count bytes, > but are likely to count bytes differently: I doubt we can expect > the count to be bytes-on-the-wire consistently. This may be true but I don't think this document is the place to discuss = it. >=20 > In IPv6, bytes-on-the-wire can differ considerably from bytes > of payload, and I would expect some users to argue that they > shouldn't be charged for anything beyond payload. As an ISP, I > know "winning" such arguments is Pyrrhic. Same comment as above. Thanks, Alissa >=20 > (This much should suffice for starting the discussion. ;^) >=20 > -- > John Leslie > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex >=20 From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Nov 2 10:40:40 2011 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 2F24B11E8114 for ; Wed, 2 Nov 2011 10:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.004 X-Spam-Level: X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 bZQCLeX2OcjU for ; Wed, 2 Nov 2011 10:40:39 -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 9ED591F0C4B for ; Wed, 2 Nov 2011 10:40:39 -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 A1A13633B1 for ; Wed, 2 Nov 2011 18:40:36 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 9075759A8A for ; Wed, 2 Nov 2011 18:40:36 +0100 (CET) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: conex@ietf.org Date: Wed, 2 Nov 2011 18:40:35 +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: <201111021840.35849.mkuehle@ikr.uni-stuttgart.de> Subject: [conex] Fwd: New Version Notification for draft-kuehlewind-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: Wed, 02 Nov 2011 17:40:40 -0000 Hi folks, I've updated the document below; just to let you know. Mirja ---------- Forwarded Message ---------- Subject: New Version Notification for draft-kuehlewind-conex-tcp-modifications-01.txt Date: Monday 31 October 2011, 13:45:05 From: internet-drafts@ietf.org To: mirja.kuehlewind@ikr.uni-stuttgart.de CC: rs@netapp.com, mirja.kuehlewind@ikr.uni-stuttgart.de A new version of I-D, draft-kuehlewind-conex-tcp-modifications-01.txt has been successfully submitted by Mirja Kuehlewind and posted to the IETF repository. Filename: draft-kuehlewind-conex-tcp-modifications Revision: 01 Title: TCP modifications for Congestion Exposure Creation date: 2011-10-31 WG ID: Individual Submission Number of pages: 12 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 Secretariat ------------------------------------------------------- From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Nov 2 10:52:08 2011 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 47F181F0C9A for ; Wed, 2 Nov 2011 10:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 yRHhQxW8NrAb for ; Wed, 2 Nov 2011 10:52:07 -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 AAC4311E80F8 for ; Wed, 2 Nov 2011 10:51:56 -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 EDECE633B1; Wed, 2 Nov 2011 18:51:55 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id D83F559A8A; Wed, 2 Nov 2011 18:51:55 +0100 (CET) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: John Leslie Date: Wed, 2 Nov 2011 18:51:55 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201110261048.16356.mkuehle@ikr.uni-stuttgart.de> <201110261808.25587.mirja.kuehlewind@ikr.uni-stuttgart.de> <20111026163326.GM57720@verdi> In-Reply-To: <20111026163326.GM57720@verdi> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201111021851.55304.mkuehle@ikr.uni-stuttgart.de> Cc: conex@ietf.org Subject: Re: [conex] Expiration of credits 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, 02 Nov 2011 17:52:08 -0000 Hi, one more question: If I send a large number of credits in Slow Start, lets say 50, and than have a quite moderate TCP like Reno with drop tail. That means I usually see only on loss everytime my cwnd exceeds the link capacity. Lets say my max cwnd is 100 the i reduce to 50 after a loss and it takes another 50 RTT until I see the next loss. That means it take 50*50=2500 RTTs or 1500*50*50=3.75MByte until my credits are gone even if I don't send any further ConEx markings. Why should I send any real ConEx marking in this situation (and pay twice)? But with ConEx we actually would like to have the real ConEx signal because only this reveals the current congestion level on the link! Mirja On Wednesday 26 October 2011 18:33:26 John Leslie wrote: > Mirja Kuehlewind wrote: > > I guess a cap is even more complicated. An expiration would somehow > > depend on RTT but the num of credit you want to send (at once) > > depend on the congestion control mechanism in the endsystem. > > IMHO you should never depend upon a credit lasting more than one > RTT. > > That said, credits are intended for start-up -- and in many cases > currently, you will need more than one RTT to infer that a packet > was dropped (because ECN marking wasn't enabled at the bottleneck). > There may be cases where you should decide whether to issue additional > credits while waiting for a timeout -- and there are certainly cases > where you _don't_ want to issue such additional credits. > > > If I increase the cwnd by 100 packet in one RTT I might want to > > send 100 credits > > I cannot imagine such a case. Credits need never exceed the greatest > plausible loss. I cannot imagine increasing cwnd by 100 when I expect > 100% packet loss. > > IMHO, credits are not generally appropriate for any situation where > you are increasing cwnd -- but I'm sure _someone_ will find a case > where it would help... :^} > > -- > John Leslie From Dirk.Kutscher@neclab.eu Wed Nov 2 11:08:21 2011 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 E69101F0CAE for ; Wed, 2 Nov 2011 11:08:21 -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] 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 PyyuP3GaGMK9 for ; Wed, 2 Nov 2011 11:08:21 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 26AC41F0CA0 for ; Wed, 2 Nov 2011 11:08:21 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 94493280001DC for ; Wed, 2 Nov 2011 19:09:00 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vbj4d57GXj9i for ; Wed, 2 Nov 2011 19:09:00 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 6B560280001D9 for ; Wed, 2 Nov 2011 19:08:55 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.17]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 2 Nov 2011 19:08:15 +0100 From: Dirk Kutscher To: "conex@ietf.org" Thread-Topic: New Version Notification for draft-kutscher-conex-mobile-02.txt Thread-Index: AQHMmAhNv3NS8AQg2kytA9gKwO7UK5WZ5DXQ Date: Wed, 2 Nov 2011 18:08:14 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F524924B7AE4B@PALLENE.office.hd> References: <20111031200413.27911.16840.idtracker@ietfa.amsl.com> In-Reply-To: <20111031200413.27911.16840.idtracker@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.209] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [conex] FW: New Version Notification for draft-kutscher-conex-mobile-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: Wed, 02 Nov 2011 18:08:22 -0000 SGksDQoNCkpGWUkgLS0gd2UgaGF2ZSB1cGRhdGVkIHRoZSBjb25leC1tb2JpbGUgZHJhZnQ6DQoN Ci0gYWRkZWQgZGVzY3JpcHRpb24gb2YgUENSRi1UREYgaW50ZXJhY3Rpb24gKERQSS4uLikNCi0g YWRkZWQgcmVmZXJlbmNlIHRvIGRyYWZ0LWJyaXNjb2UtaW5pdGlhbC1kZXBsb3kNCi0gc2FpZCBz b21ldGhpbmcgYWJvdXQgY29uZ2VzdGlvbiBhY2NvdW50aW5nIG9wdGlvbnMgaW4gUENDIGluIHNl Yy4gMy4zDQotIG5ldyBzZWN0aW9uIDQuMi4xIG9uIGNvbmV4IHByb3RvY29sIG1lY2hhbmlzbXMs IHJlZmVyZW5jaW5nIGNvbmV4LWRlc3RvcHQgYW5kIGRyYWZ0LWJyaXNjb2UtZWNuLWVuY2FwLWd1 aWRlbGluZXMNCi0gbmV3IHNlY3Rpb24gNC4yLjIgb24gY29uZXggZnVuY3Rpb25zIGluIHRoZSBF UFMgKG9sZCB0ZXh0KQ0KLSBtaXNjIGZpeGVzLCBhZGRlZCBzb21lIHJlbGV2YW50IDNHUFAgc3Bl Y3MNCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1rdXRzY2hlci1jb25leC1tb2JpbGUt MDIudHh0DQoNCkJlc3QgcmVnYXJkcywNCg0KRGlyaw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmddIA0KU2VudDogTW9udGFnLCAzMS4gT2t0b2JlciAyMDExIDIxOjA0DQpU bzoga3V0c2NoZXJAbmVjbGFiLmV1DQpDYzogd2ludGVyQG5lY2xhYi5ldTsgRmFpc2FsIEdoaWFz IE1pcjsga3V0c2NoZXJAbmVjbGFiLmV1OyBzdXJlc2gua3Jpc2huYW5AZXJpY3Nzb24uY29tOyB5 aW5nLnpoYW5nQGVyaWNzc29uLmNvbQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC1rdXRzY2hlci1jb25leC1tb2JpbGUtMDIudHh0DQoNCkEgbmV3IHZlcnNpb24g b2YgSS1ELCBkcmFmdC1rdXRzY2hlci1jb25leC1tb2JpbGUtMDIudHh0IGhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgRGlyayBLdXRzY2hlciBhbmQgcG9zdGVkIHRvIHRoZSBJRVRG IHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQta3V0c2NoZXItY29uZXgtbW9iaWxlDQpS ZXZpc2lvbjoJIDAyDQpUaXRsZToJCSBNb2JpbGUgQ29tbXVuaWNhdGlvbiBDb25nZXN0aW9uIEV4 cG9zdXJlIFNjZW5hcmlvDQpDcmVhdGlvbiBkYXRlOgkgMjAxMS0xMC0zMQ0KV0cgSUQ6CQkgSW5k aXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDIyDQoNCkFic3RyYWN0Og0KICAg VGhpcyBtZW1vIGRlc2NyaWJlcyBhIG1vYmlsZSBjb21tdW5pY2F0aW9ucyB1c2UgY2FzZSBmb3Ig Y29uZ2VzdGlvbg0KICAgZXhwb3N1cmUgKENPTkVYKSB3aXRoIGEgcGFydGljdWxhciBmb2N1cyBv biBtb2JpbGUgY29tbXVuaWNhdGlvbg0KICAgbmV0d29ya3Mgc3VjaCBhcyAzR1BQIExURS4gIFRo ZSBkcmFmdCBkZXNjcmliZXMgdGhlIGFyY2hpdGVjdHVyZSBvZg0KICAgdGhlc2UgbmV0d29ya3Mg KGFjY2VzcyBhbmQgY29yZSBuZXR3b3JrcyksIGN1cnJlbnQgUW9TIG1lY2hhbmlzbXMgYW5kDQog ICB0aGVuIGRpc2N1c3NlcyBob3cgY29uZ2VzdGlvbiBleHBvc3VyZSBjb25jZXB0cyBjb3VsZCBi ZSBhcHBsaWVkLg0KICAgQmFzZWQgb24gdGhpcywgdGhpcyBtZW1vIHN1Z2dlc3RzIGEgc2V0IG9m IHJlcXVpcmVtZW50cyBmb3IgQ09ORVgNCiAgIG1lY2hhbmlzbXMgdGhhdCBwYXJ0aWN1bGFybHkg YXBwbHkgdG8gbW9iaWxlIG5ldHdvcmtzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoN Cg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg== From mattmathis@google.com Wed Nov 2 11:37:57 2011 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 2449A11E80C8 for ; Wed, 2 Nov 2011 11:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 Ds-0YekQxEJU for ; Wed, 2 Nov 2011 11:37:56 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id B7FA711E80FD for ; Wed, 2 Nov 2011 11:37:55 -0700 (PDT) Received: by eyg24 with SMTP id 24so472582eyg.31 for ; Wed, 02 Nov 2011 11:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=X5Q67zZ9dcVjjXEEvu+UpJsrlB3pFpedVthvlggMAIQ=; b=IS1nGR0KF20AnlYUinIpNqA0lrch5+eojrmZFd2vh0p8Z3V9AM1vZPJ0+h8rWaDaLy QYXDBDunDWSFKif3lzRA== Received: by 10.213.16.80 with SMTP id n16mr192981eba.127.1320259073321; Wed, 02 Nov 2011 11:37:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.16.80 with SMTP id n16mr192975eba.127.1320259073014; Wed, 02 Nov 2011 11:37:53 -0700 (PDT) Received: by 10.213.5.11 with HTTP; Wed, 2 Nov 2011 11:37:52 -0700 (PDT) In-Reply-To: <201111021851.55304.mkuehle@ikr.uni-stuttgart.de> References: <201110261048.16356.mkuehle@ikr.uni-stuttgart.de> <201110261808.25587.mirja.kuehlewind@ikr.uni-stuttgart.de> <20111026163326.GM57720@verdi> <201111021851.55304.mkuehle@ikr.uni-stuttgart.de> Date: Wed, 2 Nov 2011 11:37:52 -0700 Message-ID: From: Matt Mathis To: =?ISO-8859-1?Q?Mirja_K=FChlewind?= Content-Type: multipart/alternative; boundary=0015174c171a0efb0604b0c4c59a X-System-Of-Record: true Cc: ConEx IETF list Subject: Re: [conex] Expiration of credits 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, 02 Nov 2011 18:37:57 -0000 --0015174c171a0efb0604b0c4c59a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So there are some problems here. In a strictly conservative model you need to have credit for every packet in flight because the network can dump/mark (nearly) an entire window in a single event, for example due to somebody else's slowstart, re routing onto a slow link, etc. In fact the normal case for ending slow starting into a drop tail queue is expected to cause 30-50% losses. An auditor that treats these cases as serious violations is likely to be viewed as broken and a non-starter, because TCP or other protocols can not prevent these events, no matter how smart they are. Note that since the network triggered events (i.e. not slowstart) can happen at any point during a long running connection, the credit memory from the initial slowstart has to be "forever". If the audit function is designed with the understanding that it is intrinsically statistical: subject to false events and having a measured response to possible violations, then lower credit thresholds and levels make sense. But you are correct in your observation that you have to build a large credit to do slowstart(*) without a audit violation, and then to be TCP friendly, the steady state marking/loss probability has to be proportional to 1/(window^2), which is potentially infinitesimal by comparison. This is really a bug in the current "TCP friendly" paradigm that can not be fixed by ConEx. I predict it will change in time, ConEx or not. The simple answer is that this problem is scale dependent, and in those parts of the network where the fair share window size is small (say under 20), chances are good that reasonable heuristics (including decaying credits) will do well enough for auditing. In the long run we have to ditch AIMD congestion control, but that is way out of scope for ConEx. (*) Or whatever algorithm you use to prime the network without any knowledge about its capabilities or state. I hope this helps, --MM-- The best way to predict the future is to create it. - Alan Kay On Wed, Nov 2, 2011 at 10:51 AM, Mirja K=FChlewind < mirja.kuehlewind@ikr.uni-stuttgart.de> wrote: > Hi, > > one more question: > > If I send a large number of credits in Slow Start, lets say 50, and than > have > a quite moderate TCP like Reno with drop tail. That means I usually see > only > on loss everytime my cwnd exceeds the link capacity. Lets say my max cwnd > is > 100 the i reduce to 50 after a loss and it takes another 50 RTT until I s= ee > the next loss. > > That means it take 50*50=3D2500 RTTs or 1500*50*50=3D3.75MByte until my c= redits > are gone even if I don't send any further ConEx markings. Why should I se= nd > any real ConEx marking in this situation (and pay twice)? > > But with ConEx we actually would like to have the real ConEx signal becau= se > only this reveals the current congestion level on the link! > > Mirja > > > On Wednesday 26 October 2011 18:33:26 John Leslie wrote: > > Mirja Kuehlewind wrote: > > > I guess a cap is even more complicated. An expiration would somehow > > > depend on RTT but the num of credit you want to send (at once) > > > depend on the congestion control mechanism in the endsystem. > > > > IMHO you should never depend upon a credit lasting more than one > > RTT. > > > > That said, credits are intended for start-up -- and in many cases > > currently, you will need more than one RTT to infer that a packet > > was dropped (because ECN marking wasn't enabled at the bottleneck). > > There may be cases where you should decide whether to issue additional > > credits while waiting for a timeout -- and there are certainly cases > > where you _don't_ want to issue such additional credits. > > > > > If I increase the cwnd by 100 packet in one RTT I might want to > > > send 100 credits > > > > I cannot imagine such a case. Credits need never exceed the greatest > > plausible loss. I cannot imagine increasing cwnd by 100 when I expect > > 100% packet loss. > > > > IMHO, credits are not generally appropriate for any situation where > > you are increasing cwnd -- but I'm sure _someone_ will find a case > > where it would help... :^} > > > > -- > > John Leslie > > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex > --0015174c171a0efb0604b0c4c59a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So there are some problems here. =A0In a strictly conservative model you ne= ed to have credit for every packet in flight because the network can dump/m= ark (nearly) an entire window in a single event, for example due to somebod= y=A0else's=A0=A0slowstart, re routing onto a slow link, etc. =A0In fact= the normal case for ending slow starting into a drop tail queue is expecte= d to cause 30-50% losses. =A0An=A0auditor=A0that treats these cases as seri= ous violations is likely to be viewed as broken and a non-starter, because = TCP or other protocols can not prevent these events, no matter how smart th= ey are. =A0 Note that since the network triggered events (i.e. not slowstar= t) can happen at any point during a long running connection, the credit mem= ory from the initial slowstart has to be "forever".

If the=A0audit=A0function is designed with the understanding= that it is intrinsically statistical: subject to false events and having a= measured response to possible violations, then lower credit thresholds and= levels make sense.

But you are correct in your observation that you have t= o build a large credit to do slowstart(*) without a audit violation, and th= en to be TCP friendly, the steady state marking/loss=A0probability=A0has to= be=A0proportional=A0to 1/(window^2), which is potentially infinitesimal by= comparison. =A0This is really a bug in the current "TCP friendly"= ; paradigm that can not be fixed by ConEx.=A0I predict it will change in ti= me, ConEx or not.

The simple answer is that this problem is scale depende= nt, and in=A0those=A0parts of the network where the fair share window size = is small (say under 20), chances are good that reasonable heuristics (inclu= ding decaying credits) will do well enough for auditing. =A0 =A0In the long= run we have to ditch AIMD congestion control, but that is way out of scope= for ConEx.

(*) Or whatever algorithm you use to prime the net= work without any knowledge about its capabilities or state.

<= /div>
I hope this helps,
--MM--
The best way to pre= dict the future is to create it. =A0- Alan Kay



On Wed, Nov 2, 2011 at 10:51 AM, Mirja K= =FChlewind <mirja.kuehlewind@ikr.uni-stuttgart.de> wrote:<= br>
Hi,

one more question:

If I send a large number of credits in Slow Start, lets say 50, and than ha= ve
a quite moderate TCP like Reno with drop tail. That means I usually see onl= y
on loss everytime my cwnd exceeds the link capacity. Lets say my max cwnd i= s
100 the i reduce to 50 after a loss and it takes another 50 RTT until I see=
the next loss.

That means it take 50*50=3D2500 RTTs or 1500*50*50=3D3.75MByte until my cre= dits
are gone even if I don't send any further ConEx markings. Why should I = send
any real ConEx marking in this situation (and pay twice)?

But with ConEx we actually would like to have the real ConEx signal because=
only this reveals the current congestion level on the link!

Mirja


On Wednesday 26 October 2011 18:33:26 John Leslie wrote:
> Mirja Kuehlewind <mirja.kuehlewind@ikr.uni-stuttgart.de> wrote:
> > I guess a cap is even more complicated. An expiration would someh= ow
> > depend on RTT but the num of credit you want to send (at once) > > depend on the congestion control mechanism in the endsystem.
>
> =A0 =A0IMHO you should never depend upon a credit lasting more than on= e
> RTT.
>
> =A0 =A0That said, credits are intended for start-up -- and in many cas= es
> currently, you will need more than one RTT to infer that a packet
> was dropped (because ECN marking wasn't enabled at the bottleneck)= .
> There may be cases where you should decide whether to issue additional=
> credits while waiting for a timeout -- and there are certainly cases > where you _don't_ want to issue such additional credits.
>
> > If I increase the cwnd by 100 packet in one RTT I might want to > > send 100 credits
>
> =A0 =A0I cannot imagine such a case. Credits need never exceed the gre= atest
> plausible loss. I cannot imagine increasing cwnd by 100 when I expect<= br> > 100% packet loss.
>
> =A0 =A0IMHO, credits are not generally appropriate for any situation w= here
> you are increasing cwnd -- but I'm sure _someone_ will find a case=
> where it would help... :^}
>
> --
> John Leslie <john@jlc.net>

_______________________________________________
conex mailing list
conex@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/conex

--0015174c171a0efb0604b0c4c59a-- From john@jlc.net Wed Nov 2 14:34:46 2011 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 F231F1F0C80 for ; Wed, 2 Nov 2011 14:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.528 X-Spam-Level: X-Spam-Status: No, score=-106.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 fptcJ+FQvuCO for ; Wed, 2 Nov 2011 14:34:45 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 232731F0C63 for ; Wed, 2 Nov 2011 14:34:45 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 3350C33C26; Wed, 2 Nov 2011 17:34:44 -0400 (EDT) Date: Wed, 2 Nov 2011 17:34:44 -0400 From: John Leslie To: Matt Mathis Message-ID: <20111102213444.GA88646@verdi> References: <201110261048.16356.mkuehle@ikr.uni-stuttgart.de> <201110261808.25587.mirja.kuehlewind@ikr.uni-stuttgart.de> <20111026163326.GM57720@verdi> <201111021851.55304.mkuehle@ikr.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: ConEx IETF list Subject: Re: [conex] Expiration of credits 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, 02 Nov 2011 21:34:46 -0000 Matt makes several good points here. I mostly want to add that in the RealWorld, the node where congestion occurs is unlikely to be able to reliably differentiate which flow has built up a credit. Matt Mathis wrote: > > So there are some problems here. In a strictly conservative model you > need to have credit for every packet in flight because the network can > dump/mark (nearly) an entire window in a single event, for example due > to somebody else's slowstart, re routing onto a slow link, etc. We should be careful that we don't call such a rare event a ConEx "violation". (OK, so it's not as "rare" as all that...) The way I see it, it's important to build up at least one credit for slow-start, but that in the ordinary case you should be happy to get a single ECN congestion-experienced mark and back off in one RTT -- if the rest of your packets in flight get dropped, that's OK. OTOH, some uses might be paranoid about dropped packets and want a larger credit built up -- if they had reason to believe "credit" packets would get through with ECN marks. (I'm not sure it's in-scope to discuss why they might believe that.) > In fact the normal case for ending slow starting into a drop tail > queue is expected to cause 30-50% losses. Cite? (I do expect fairly nasty drop rates in that case -- and I agree it's plausible for startup traffic to an empty link.) I think the conventional wisdom is that one halving the rate is sufficient; and that drop-tail will drop that many packets quite regardless of ECN or ConEx marking. > An auditor that treats these cases as serious violations is likely > to be viewed as broken and a non-starter, because TCP or other > protocols can not prevent these events, no matter how smart they > are. A question we probably should address is whether it makes any sense to consider a single ConEx mark, followed by dozens of packet drops, to be a "violation". IMHO, it shouldn't be. > Note that since the network triggered events (i.e. not slowstart) > can happen at any point during a long running connection, the credit > memory from the initial slowstart has to be "forever". s/has to be/would have to be/ (I strongly believe we can't implement "forever" in the wild.) > If the audit function is designed with the understanding that it is > intrinsically statistical: subject to false events and having a > measured response to possible violations, then lower credit > thresholds and levels make sense. Agreed. (And I feel stronly that we must define it to be that way.) > But you are correct in your observation that you have to build a > large credit to do slowstart(*) without a audit violation, and > then to be TCP friendly, the steady state marking/loss probability > has to be proportional to 1/(window^2), which is potentially > infinitesimal by comparison. Agreed. > This is really a bug in the current "TCP friendly" paradigm that > can not be fixed by ConEx. I predict it will change in time, ConEx > or not. (I wish I were as confident...) > The simple answer is that this problem is scale dependent, and > in those parts of the network where the fair share window size is > small (say under 20), chances are good that reasonable heuristics > (including decaying credits) will do well enough for auditing. I doubt that will be true for even the average total-path in today's Internet. Nor do I believe the situation will improve by itself. :^( > In the long run we have to ditch AIMD congestion control, but that > is way out of scope for ConEx. Agreed, it's out of scope. However, I believe that sufficient ConEx deployment will make it more acceptable to use alternatives to AIMD... -- John Leslie From john@jlc.net Mon Nov 7 08:01:36 2011 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 09FE721F8B05 for ; Mon, 7 Nov 2011 08:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.53 X-Spam-Level: X-Spam-Status: No, score=-106.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 fJfSk4DLfH6F for ; Mon, 7 Nov 2011 08:01:35 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 7074F21F8B01 for ; Mon, 7 Nov 2011 08:01:35 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 4B5F533C27; Mon, 7 Nov 2011 11:01:35 -0500 (EST) Date: Mon, 7 Nov 2011 11:01:35 -0500 From: John Leslie To: conex@ietf.org Message-ID: <20111107160135.GA45061@verdi> References: <20111030141755.21962.83789.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111030141755.21962.83789.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.4.1i Subject: [conex] draft-ietf-conex-destopt-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, 07 Nov 2011 16:01:36 -0000 internet-drafts@ietf.org wrote: > > http://www.ietf.org/internet-drafts/draft-ietf-conex-destopt-01.txt The changes are all additions at the end of Section 4. In this post, I ask for clarification of the first added sentence: ] ] All packets of a ConEx-capable connection MUST carry the CDO. I'm guessing the intention is that "all packets" must include this ConEx Destination Option. But I don't want to venture too far before getting a yes or no... Also, we should clarify whether we mean "in both directions". Perhaps we should even clarify when we start counting "all". (Presumably not the first ACK of SYN-ACK; what about the second?) Regardless, I'll venture so far as to ask "Why should _all_ packets carry this option?" I'd like to see a _lot_ more justification for adding this much overhead. -- John Leslie From john@jlc.net Mon Nov 7 09:05:18 2011 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 2C22621F8C65 for ; Mon, 7 Nov 2011 09:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.533 X-Spam-Level: X-Spam-Status: No, score=-106.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 XFOi2dSNQcsb for ; Mon, 7 Nov 2011 09:05:17 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id D3AB021F8C5E for ; Mon, 7 Nov 2011 09:05:16 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id C659B33C26; Mon, 7 Nov 2011 12:05:15 -0500 (EST) Date: Mon, 7 Nov 2011 12:05:15 -0500 From: John Leslie To: conex@ietf.org Message-ID: <20111107170515.GB45061@verdi> References: <20111030141755.21962.83789.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111030141755.21962.83789.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.4.1i Subject: [conex] byte-counting in conex-destopt 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, 07 Nov 2011 17:05:18 -0000 internet-drafts@ietf.org wrote: > > http://www.ietf.org/internet-drafts/draft-ietf-conex-destopt-01.txt In this post I treat the byte-count language added. ] ] If the X bit is set, all three other bit (L, E, C) MAY be set. When ] ever one if this bits is set, I'm guessing the intent is "Whenever one of these bits is set". ] the number of bytes carried by this IP packet (incl. IP header) ] SHOULD be accounted when determining congestion or credit information. Implicit byte-count, IMHO, is a bad idea. Inevitably it leads to different parties counting differently. And, we have a synchronization problem too, where sometimes we're counting bytes in this packet and sometimes we're counting bytes in a previous packet (at least one RTT ago). There's plenty of room for an _explicit_ byte count; and IMHO if we want to go down this path of auditing congestion volume in bytes, we owe it to implementors to be explicit. ] In IPv6 the length can easily be calculated by the value given in ] the Payload Length header field (payload length + option space) ] plus a fixed value of 40 Bytes for the IP header itself. Yes, this is explicit about counting bytes-on-the-wire at IP layer; but even so, I see room for confusion: I'd reword slightly (again, if we want to go down this path at all). ] In principle all of these three bits (L, E, C) MAY be set in the ] same packet. In this case the packet size MUST be accounted more ] than once for each respective ConEx information counter. This is confusing. There's no justification given for keeping three separate counters, nor an algorithm for how to relate them. ] In practice loss and ECN marks can not occur at the same time, Actually, this isn't quite true. Loss must be detected by timeout or funky ACKs, while ECN marks are known at packet receipt. Thus, both loss and ECN could be detected at the same time. ] so there should usually be a way to signal the respective ConEx ] information in different packets. "Where there's a will, there's a way..." ] In many cases if congestion occurs the sender will not sent ] additional credit bit, I think there's a typo there, but I'm not sure what it is... ] but if e.g. a sender assumes losses because of an audit function I'm not clear what is intended by "losses because of an audit function": some proposed audit functions may actually drop packets due to the audit information... ] or needs to maintain a certain sending rate to make an application ] layer service work, the occurrence of credit bits (c) in parallel ] to congestion exposure bit (L, E) is reasonable. I'm not sure I'd go as far as "reasonable", but it's certainly "plausible". However, there's really no reason to believe that a sender will desire _exactly_ the same byte-count of "credit" as "loss". Again, there's plenty of room for an explicit byte-count _if_ we want to go down that path. ] If a network node extracts the ConEx information from a connection, ] this node is usually supposed to hold this information byte-wise, ] e.g. comparing the total number of bytes sent with the number of ] bytes sent with ConEx congestion mark (L, E) to determine the current ] whole path congestion level. There's that "congestion level" term again. I'm hoping we can avoid it... I remain unconvinced that _I_ want to go down the path of counting bytes. I'd argue that in the case of packet loss, we're tending to a active-queue-managment paradigm where drop is correlated to packet count. (Agreed, for ECN there's a "cost" correlated to bytes allowed through with ECN marks.) It's _hard_ to cure ISPs of thinking in terms of percent of packets lost when they consider "congestion". The argument in favor of counting bytes seems to rest on "academic purity", which IMHO will always lose to "pragmatic" in the RealWorld. ] When equally sized packets can be assumed accounting the number of ] packets (and comparing the total number to marked once) should ] deliver the same result. One can _always_ "assume"... :^( ] But a network node MUST be aware that this estimation can be quite ] wrong (That's not a correct use of 2119 MUSTard.) "wrong" is in the eye of the beholder. We can at most talk of "compliant" with a standard. (And I don't believe this is the right document for that.) ] and thus is not reliable if e.g. different sized packed are send. (Presumably "sent" is intended.) "reliable" doesn't seem the right word here. ==== Let me argue a bit about the difficulties of synchronizing byte counts. If we insist on implicit byte counts, at some point we will force the sending of small packets to get byte counts right. (IMHO this will lead to greater packet drops.) And, we can't drive the byte count near zero because of IPv6 overhead. Indeed, the sender will have to guess at IPv6 overhead, because the OS composes the actual packet. Worse yet, no amount of jawboning in RFCs will prevent middleboxes from fidddling with packets. :^( :^( :^( The smaller the packet, the greater the problem of miscounting bytes-on-the-wire. And we can't count bytes-on-the-wire accurately except at the node in question. Even if we could count accurately, we don't know an appropriate estimate of byte-overhead per packet _beyond_ bytes-on-the-wire. Necessarily, any useful audit function must try to match actual congestion to congestion-expected marks. These _cannot_ happen at the identical time: typically they're one RTT apart. But in the 'Net we work in, RTT is unknowabble except to end-points. We must, therefore, work in approximations. IMHO, approximating as packet-count is much easier and not significantly less useful. I'd really appreciate if we could stop arguing "academic purity" and instead list problems of utility. -- John Leslie From marcelo@it.uc3m.es Tue Nov 8 13:46:12 2011 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 2FD2C11E80B1 for ; Tue, 8 Nov 2011 13:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 lyRlMkdFX-3Q for ; Tue, 8 Nov 2011 13:46:11 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 41F9111E80A6 for ; Tue, 8 Nov 2011 13:46:00 -0800 (PST) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (249.30.18.95.dynamic.jazztel.es [95.18.30.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 7475476102A for ; Tue, 8 Nov 2011 22:45:58 +0100 (CET) Message-ID: <4EB9A316.2050507@it.uc3m.es> Date: Tue, 08 Nov 2011 22:45:58 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 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-18502.002 Subject: [conex] draft agenda posted 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, 08 Nov 2011 21:46:12 -0000 see it at: http://www.ietf.org/proceedings/82/agenda/conex.txt regards, marcelo From philip.eardley@bt.com Wed Nov 9 01:11:45 2011 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 0F1D921F8464 for ; Wed, 9 Nov 2011 01:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.232 X-Spam-Level: X-Spam-Status: No, score=-103.232 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 zGMkvnVPPYD8 for ; Wed, 9 Nov 2011 01:11:44 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD8221F8AF0 for ; Wed, 9 Nov 2011 01:11:44 -0800 (PST) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 9 Nov 2011 09:11:42 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.176]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Wed, 9 Nov 2011 09:11:42 +0000 From: To: Date: Wed, 9 Nov 2011 09:11:41 +0000 Thread-Topic: comments on draft-briscoe-conex-initial-deploy Thread-Index: AcyeX9l+BVsGibcjSn+LYFbzC75/2wAXvGEQ Message-ID: <9510D26531EF184D9017DF24659BB87F330E144547@EMV65-UKRD.domain1.systemhost.net> References: <4EB9A316.2050507@it.uc3m.es> In-Reply-To: <4EB9A316.2050507@it.uc3m.es> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [conex] comments on draft-briscoe-conex-initial-deploy 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, 09 Nov 2011 09:11:45 -0000 http://tools.ietf.org/id/draft-briscoe-conex-initial-deploy-00.txt=20 Bob, thanks for the draft, think it's important to have started this. some comme= nts. I think you could start at S4. the earlier sections stop the reader getting= rapidly to the main bit of the doc. You start by saying that the initial step is a ledbat source is conex enabl= ed; the second step is the network becomes conex-enabled. personally i woul= dn't call this "unilateral deploymet by a single network" (scope of draft i= n S1). Talk of this ledbat-conex source somewhat disappears later on. if th= is is the deployment path, it also raises the question of what's the deploy= ment incentive for ledbat, is this clear-cut? I attempted to re-draw figure 1, see below, see if you think it's clearer. I think it would be clearer if the conex-ISP just ran the network - dividin= g into core and access seems unnecessary detail [at least until the basic d= eployment scenario is clear] I think the initial deployment step is where the ISP runs the network & a d= ata centre - the DC has conex-enabled conex sources (which are trusted abou= t their conex markings, since they're under ISP's control). you need to men= tion how other traffic is handled. a step beyond the initial one is where o= ther senders are conex-enabled, but not trusted (i wouldn't include them on= fig 1) - only at that stage might ledbat become relevant. I think the scenario is that the DC-ISP offers a premium service to content= providers, which internally it implements using conex. anyway, i think the WG should decide whether the initial deployment case is= via ledbat or a conex-core also running a DC. or via mobile network or int= ernal to data centre. thanks, phil ---- <---- Single ISP operates ---->=20 data centre & core & access networks all are ConEx-enabled _________ _______ ____ | CORE | |ACCESS | |HOME| | NETWORK |NETWORK| |NET | _________ | | | | | | | ISP's | | | | | | | | data | | | | | | | | centre | | | | | | | | | | | | | | | | +-------+ +-------+ | | | | | | |trusted| | ConEx | | | | | | | | ConEx | =3D> | | | | | | | | |sender | |monitor| | =3D> | | =3D> | | | +-------+ +-------+ | | | | | | | | | | | | | |_________| | | | | | | _________ | | | | | | | ConEx- | ___ | | | | | | |enabled | | | | CORE | |ACCESS | |HOME| | CDN | | | | NETWORK | |NETWORK| |NET | | | | I | | | | | | | | +-------+ | | | | | | | | | | Non- | | N | +-------+ | | | | | | |trusted| | | | Non- | | | | | | | | ConEx | =3D> |=3D=3D>| =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> | Co= nEx | | =3D> | | =3D> | | | |sender | | | |policer| | | | | | | +-------+ | T | +-------+ | | | | | |_________| | | | | | | | | | E | | | | | | | | | | | | | | | _________ | R | | | | | | | |'legacy' | | | | | | | | | | | | N | | | | | | | | +-------+ | | +-------+ | +-----+ | | | | | Non- | | E | | ConEx | | |ConEx| | | | | | ConEx | =3D> |=3D=3D>| =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> | = | | =3D> | | | =3D> | | | |sender | | | |policer| | |audit| | | | | +-------+ | T | +-------+ | +-----+ | | | | | | | | | | | | | |_________| |___| | | | | | | | | | | | | |_________| |_______| |____| Philip Eardley=A0=A0=A0 Research and Technology Strategy This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We m= onitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Nov 9 08:20:03 2011 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 141D621F8C48 for ; Wed, 9 Nov 2011 08:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, 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 dq29zzS7l9Ih for ; Wed, 9 Nov 2011 08:19:58 -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 989B821F8C44 for ; Wed, 9 Nov 2011 08:19:58 -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 21B7D633B1; Wed, 9 Nov 2011 17:19:56 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 100F159A8A; Wed, 9 Nov 2011 17:19:56 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: conex@ietf.org Date: Wed, 9 Nov 2011 17:19:54 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <20111030141755.21962.83789.idtracker@ietfa.amsl.com> <20111107160135.GA45061@verdi> In-Reply-To: <20111107160135.GA45061@verdi> 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: <201111091719.54931.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: Re: [conex] draft-ietf-conex-destopt-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: Wed, 09 Nov 2011 16:20:03 -0000 Hi John, first of all: I added some text to this draft about how exactly the ConEx b= its=20 need to be interpreted and which kind of packets should/can have which=20 markings, because there is some more specific text need in this draft. What= =20 every is written there is of cause open for discussion. So thanks for your= =20 feedback so far. Now to your point: The idea behind the MUST below was that a network node c= an=20 figure out based on just one packet if the connection is ConEx-capable or n= ot=20 even though the packet itself might not have any ConEx bit set. I'm not sur= e=20 if this is requirement. If not it might be unnecessary overhead and we coul= d=20 remove this. If we remove this we don't need the X bit neither anymore. But= =20 in fact I believe most packets will still need to have a CDO (except pure=20 ACKs...?). Another good point is, if it is possible to have one half-connection=20 ConEx-enable and the other not? Maybe it might make sense if e.g. use data= =20 only flow in one direction and the other direction which sends only pure AC= Ks=20 is not ConEx-capable...? Don't no... further options here? Mirja=20 On Monday 07 November 2011 17:01:35 John Leslie wrote: > internet-drafts@ietf.org wrote: > > http://www.ietf.org/internet-drafts/draft-ietf-conex-destopt-01.txt > > The changes are all additions at the end of Section 4. > > In this post, I ask for clarification of the first added sentence: > ] > ] All packets of a ConEx-capable connection MUST carry the CDO. > > I'm guessing the intention is that "all packets" must include this > ConEx Destination Option. But I don't want to venture too far before > getting a yes or no... > > Also, we should clarify whether we mean "in both directions". > > Perhaps we should even clarify when we start counting "all". > (Presumably not the first ACK of SYN-ACK; what about the second?) > > Regardless, I'll venture so far as to ask "Why should _all_ packets > carry this option?" I'd like to see a _lot_ more justification for > adding this much overhead. > > -- > John Leslie > _______________________________________________ > 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 mirja.kuehlewind@ikr.uni-stuttgart.de Wed Nov 9 08:59:38 2011 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 7199B21F8C4B for ; Wed, 9 Nov 2011 08:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.015 X-Spam-Level: X-Spam-Status: No, score=-2.015 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 ogaPaSZa9Y00 for ; Wed, 9 Nov 2011 08:59:34 -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 1BA5B21F8C49 for ; Wed, 9 Nov 2011 08:59:34 -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 0F4BE633B1; Wed, 9 Nov 2011 17:59:32 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id F38AE59A8A; Wed, 9 Nov 2011 17:59:31 +0100 (CET) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: conex@ietf.org Date: Wed, 9 Nov 2011 17:59:31 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <20111030141755.21962.83789.idtracker@ietfa.amsl.com> <20111107170515.GB45061@verdi> In-Reply-To: <20111107170515.GB45061@verdi> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201111091759.31110.mkuehle@ikr.uni-stuttgart.de> Subject: Re: [conex] byte-counting in conex-destopt 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, 09 Nov 2011 16:59:38 -0000 Hi John, I guess there is some more discussion needed on this issue (in the next meeting). For now, my understanding was that the abstract mechanism draft says that ConEx bits should be accounted byte-wise and I just try to reflect this here. Some more points see below. Mirja On Monday 07 November 2011 18:05:15 John Leslie wrote: > internet-drafts@ietf.org wrote: > > http://www.ietf.org/internet-drafts/draft-ietf-conex-destopt-01.txt > > In this post I treat the byte-count language added. > ] > ] If the X bit is set, all three other bit (L, E, C) MAY be set. When > ] ever one if this bits is set, > > I'm guessing the intent is "Whenever one of these bits is set". > > ] the number of bytes carried by this IP packet (incl. IP header) > ] SHOULD be accounted when determining congestion or credit information. > > Implicit byte-count, IMHO, is a bad idea. Inevitably it leads to > different parties counting differently. And, we have a synchronization > problem too, where sometimes we're counting bytes in this packet and > sometimes we're counting bytes in a previous packet (at least one RTT > ago). > > There's plenty of room for an _explicit_ byte count; and IMHO if > we want to go down this path of auditing congestion volume in bytes, > we owe it to implementors to be explicit. What do you mean by 'explicit'? You want to put the number of bytes in the CDO? > > ] In IPv6 the length can easily be calculated by the value given in > ] the Payload Length header field (payload length + option space) > ] plus a fixed value of 40 Bytes for the IP header itself. > > Yes, this is explicit about counting bytes-on-the-wire at IP layer; > but even so, I see room for confusion: I'd reword slightly (again, > if we want to go down this path at all). Feel free to make a text proposal here! Its all open for discussion and re-wording! > > ] In principle all of these three bits (L, E, C) MAY be set in the > ] same packet. In this case the packet size MUST be accounted more > ] than once for each respective ConEx information counter. > > This is confusing. There's no justification given for keeping > three separate counters, nor an algorithm for how to relate them. I though the justification was given in the abstract mechanism draft. Basically these signals are not related... > > ] In practice loss and ECN marks can not occur at the same time, > > Actually, this isn't quite true. Loss must be detected by > timeout or funky ACKs, while ECN marks are known at packet receipt. > Thus, both loss and ECN could be detected at the same time. That's really true! I will change this! Was just a quick first effort to get some text here. > > ] so there should usually be a way to signal the respective ConEx > ] information in different packets. > > "Where there's a will, there's a way..." > > ] In many cases if congestion occurs the sender will not sent > ] additional credit bit, > > I think there's a typo there, but I'm not sure what it is... > > ] but if e.g. a sender assumes losses because of an audit function > > I'm not clear what is intended by "losses because of an audit > function": some proposed audit functions may actually drop packets > due to the audit information... Yes and the receiver/sender will not be able to distinguish if there was a loss because of congestion or if the audit was dropping something. > > ] or needs to maintain a certain sending rate to make an application > ] layer service work, the occurrence of credit bits (c) in parallel > ] to congestion exposure bit (L, E) is reasonable. > > I'm not sure I'd go as far as "reasonable", but it's certainly > "plausible". > > However, there's really no reason to believe that a sender will > desire _exactly_ the same byte-count of "credit" as "loss". No, a sender should try to have at least as much credit as loss is expected. I guess usually there will be (slightly) more credits. > > Again, there's plenty of room for an explicit byte-count _if_ > we want to go down that path. > > ] If a network node extracts the ConEx information from a connection, > ] this node is usually supposed to hold this information byte-wise, > ] e.g. comparing the total number of bytes sent with the number of > ] bytes sent with ConEx congestion mark (L, E) to determine the current > ] whole path congestion level. > > There's that "congestion level" term again. I'm hoping we can > avoid it... I would actually prefer 'congestion level' against only 'congestion' to make sure that this time not 'congestion volume' was meant. But of course I will go in line with the use case draft... > > I remain unconvinced that _I_ want to go down the path of counting > bytes. I'd argue that in the case of packet loss, we're tending to > a active-queue-managment paradigm where drop is correlated to packet > count. (Agreed, for ECN there's a "cost" correlated to bytes allowed > through with ECN marks.) It's _hard_ to cure ISPs of thinking in > terms of percent of packets lost when they consider "congestion". If you drop every _packet_ with the same probability, that's perfectly right. Assume two senders that send the same amount of data (e.g. 150kbyte), but sender A sends only 10 packets and sender B sends 100. Now there is a congestion (level) of 10%, so 10% of all packets get a marking. sender A -> 1 packet marked sender B -> 10 packets marked But both have the same amount of data/bytes marked! packet size of A: 1500 byte packet size of B: 150 byte sender A -> 1 * 1500byte = 1500byte sender B -> 10 * 150byte = 1500byte If all packets are equal sized (as implicitly assumed above) and you count the number of marked packets, you will see on both connections a congestion level of 1/10 = 10/100 = 10%. Now let's calculate the congestion (level) on a per byte base: (1500 * 1)/(1500*10) = 10% (150 *10)/(150*100) = 10% Works as well! Great! The only problem occurs now, if you do not have equal sized packets. In this case byte-wise accounting gives still the right congestion level but packet-wise accounting not. > The argument in favor of counting bytes seems to rest on "academic > purity", which IMHO will always lose to "pragmatic" in the RealWorld. I understand this. I still would like to put in the draft that conex is defined byte-wise (because its the only way to do this correctly and otherwise there are ways to cheat by playing with the packet sizes) but to also make clear in the draft that in the usually case of equal sized packets it doesn't make a different. Thus it might be sufficient in many cases to count packets (depending on what you gone use the ConEx infos for). > > ] When equally sized packets can be assumed accounting the number of > ] packets (and comparing the total number to marked once) should > ] deliver the same result. > > One can _always_ "assume"... :^( > > ] But a network node MUST be aware that this estimation can be quite > ] wrong > > (That's not a correct use of 2119 MUSTard.) > > "wrong" is in the eye of the beholder. We can at most talk of > "compliant" with a standard. (And I don't believe this is the right > document for that.) > > ] and thus is not reliable if e.g. different sized packed are send. > > (Presumably "sent" is intended.) > > "reliable" doesn't seem the right word here. > > ==== > > Let me argue a bit about the difficulties of synchronizing byte > counts. > > If we insist on implicit byte counts, at some point we will force > the sending of small packets to get byte counts right. No, ConEx is not indented to change the packet size. In the TCP mod draft we currently basically say that you can send more bytes as ConEx marked than needed and store this information (for a certain time) such that you basically have sent those marked bytes in advance. In fact there is no need to get the conex marked bytes absolutely accurate (only make sure to send enough bytes such that the audit will be happy). > (IMHO this > will lead to greater packet drops.) And, we can't drive the byte > count near zero because of IPv6 overhead. Indeed, the sender will > have to guess at IPv6 overhead, because the OS composes the actual > packet. Worse yet, no amount of jawboning in RFCs will prevent > middleboxes from fidddling with packets. :^( :^( :^( > > The smaller the packet, the greater the problem of miscounting > bytes-on-the-wire. And we can't count bytes-on-the-wire accurately > except at the node in question. Even if we could count accurately, > we don't know an appropriate estimate of byte-overhead per packet > _beyond_ bytes-on-the-wire. > > Necessarily, any useful audit function must try to match actual > congestion to congestion-expected marks. These _cannot_ happen at > the identical time: typically they're one RTT apart. But in the > 'Net we work in, RTT is unknowabble except to end-points. We must, > therefore, work in approximations. We still work on approximations. The RTT is a totally different issue with the audit device... > > IMHO, approximating as packet-count is much easier and not > significantly less useful. I'd really appreciate if we could stop > arguing "academic purity" and instead list problems of utility. > > -- > John Leslie > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Nov 9 11:58:31 2011 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 60E1021F851A for ; Wed, 9 Nov 2011 11:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, 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 12YJvr4QWZoG for ; Wed, 9 Nov 2011 11:58: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 D36D321F84CB for ; Wed, 9 Nov 2011 11:58:30 -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 EBB62633B1 for ; Wed, 9 Nov 2011 20:58:28 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id CDF8459A8A for ; Wed, 9 Nov 2011 20:58:28 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: conex@ietf.org Date: Wed, 9 Nov 2011 20:58:27 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <20111030141755.21962.83789.idtracker@ietfa.amsl.com> <20111107160135.GA45061@verdi> <201111091719.54931.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201111091719.54931.mirja.kuehlewind@ikr.uni-stuttgart.de> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201111092058.28029.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: Re: [conex] draft-ietf-conex-destopt-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: Wed, 09 Nov 2011 19:58:31 -0000 Hi again, I just want to quickly answer/rephrase my own question: > Another good point is, if it is possible to have one half-connection > ConEx-enable and the other not? Maybe it might make sense if e.g. use data > only flow in one direction and the other direction which sends only pure > ACKs is not ConEx-capable...? Don't no... further options here? As ConEx requires only sender-side modifications, it is possible to one half-connection ConEx-enabled and the other direction not. But the question would be: Should a sender that is generally ConEx-capable not enable ConEx on a (half-)connection that does not send any use data (but e.g. just pure ACKs), as no congestion feedback is available for those packets...? Mirja From nanditad@google.com Sun Nov 13 08:24:13 2011 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 EB7EF21F8B08 for ; Sun, 13 Nov 2011 08:24:13 -0800 (PST) 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 Jwm-tC1xXr5c for ; Sun, 13 Nov 2011 08:24:13 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0DD21F8ABE for ; Sun, 13 Nov 2011 08:24:13 -0800 (PST) Received: by ggnr5 with SMTP id r5so160137ggn.31 for ; Sun, 13 Nov 2011 08:24:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-system-of-record; bh=Ftqidt6DyqrtMaaNbbjnCSoOqsj0MEe22GlBZF6Ctsg=; b=pXy9MKlwtuvSI5QAJKj481zcok5fKKkX86NWC8S4ZMe9ERTnjZOV87i3sd4xtUSUFB 0FTW3TL0L3QE2/xHEEOg== Received: by 10.236.156.5 with SMTP id l5mr8965624yhk.29.1321201454328; Sun, 13 Nov 2011 08:24:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.156.5 with SMTP id l5mr8965603yhk.29.1321201454151; Sun, 13 Nov 2011 08:24:14 -0800 (PST) Received: by 10.150.148.3 with HTTP; Sun, 13 Nov 2011 08:24:14 -0800 (PST) Date: Sun, 13 Nov 2011 08:24:14 -0800 Message-ID: From: Nandita Dukkipati To: Alissa Cooper , Bob Briscoe , "Woundy, Richard" Content-Type: multipart/alternative; boundary=20cf30426d9859f75304b1a02f4b X-System-Of-Record: true Cc: conex@ietf.org Subject: [conex] Sec 3.1 deserves an example 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: Sun, 13 Nov 2011 16:24:14 -0000 --20cf30426d9859f75304b1a02f4b Content-Type: text/plain; charset=ISO-8859-1 Alissa, Bob, Richard, How about putting a simple example with numbers for the core use case described in Sec 3.1, similar to what you did in Sec. 2.2 to describe congestion volume. Nandita --20cf30426d9859f75304b1a02f4b Content-Type: text/html; charset=ISO-8859-1 Alissa, Bob, Richard,

How about putting a simple example with numbers for the core use case described in Sec 3.1, similar to what you did in Sec. 2.2 to describe congestion volume.

Nandita
--20cf30426d9859f75304b1a02f4b-- From marcelo@it.uc3m.es Mon Nov 14 01:06:59 2011 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 4938C21F8CFD for ; Mon, 14 Nov 2011 01:06:57 -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 R4RINFJbPWf4 for ; Mon, 14 Nov 2011 01:06:55 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 84A2021F8ABB for ; Mon, 14 Nov 2011 01:06:50 -0800 (PST) X-uc3m-safe: yes Received: from dhcp-17e7.meeting.ietf.org (dhcp-17e7.meeting.ietf.org [130.129.23.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id A83C49C6210 for ; Mon, 14 Nov 2011 10:06:47 +0100 (CET) Message-ID: <4EC0DA23.8030909@it.uc3m.es> Date: Mon, 14 Nov 2011 10:06:43 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 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-18516.006 Subject: [conex] presentations for thursday 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, 14 Nov 2011 09:06:59 -0000 X-List-Received-Date: Mon, 14 Nov 2011 09:06:59 -0000 Please send the slides for the meeting before wed evening. Regards, marcelo From ingemar.s.johansson@ericsson.com Mon Nov 14 02:16:08 2011 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 5D84221F8CFB for ; Mon, 14 Nov 2011 02:16:08 -0800 (PST) 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=[BAYES_00=-2.599, 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 HF42s45Lsu7P for ; Mon, 14 Nov 2011 02:16:07 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id C8E3521F8CCB for ; Mon, 14 Nov 2011 02:16:06 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-6c-4ec0ea6511c4 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 54.A7.09514.56AE0CE4; Mon, 14 Nov 2011 11:16:05 +0100 (CET) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.53]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 14 Nov 2011 11:16:05 +0100 From: Ingemar Johansson S To: "conex@ietf.org" Date: Mon, 14 Nov 2011 11:16:04 +0100 Thread-Topic: ConEx as sender side only modification Thread-Index: AcydiB6mfQJtxVvXSG29LXyPUk4DtQFLPAPQ Message-ID: References: <20111030141755.21962.83789.idtracker@ietfa.amsl.com> <20111107160135.GA45061@verdi> In-Reply-To: <20111107160135.GA45061@verdi> 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== Subject: [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: Mon, 14 Nov 2011 10:16:08 -0000 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 normal server clien= t architecture as it is easier to modify a million servers than a zillion c= lients. 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.=20 Does this then mean that a TCP flow (unmodified TCP) will state a higher co= ngestion 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.=20 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 From bob.briscoe@bt.com Mon Nov 14 05:07:53 2011 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 9E4CA11E82C0 for ; Mon, 14 Nov 2011 05:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.756 X-Spam-Level: X-Spam-Status: No, score=-2.756 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 nI+Fi11p+gQN for ; Mon, 14 Nov 2011 05:07:52 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by ietfa.amsl.com (Postfix) with ESMTP id 19C5311E82B7 for ; Mon, 14 Nov 2011 05:07:51 -0800 (PST) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Nov 2011 13:07:42 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Nov 2011 13:07:42 +0000 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 1321276060905; Mon, 14 Nov 2011 13:07:40 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.131.152]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id pAED7Zi2019728; Mon, 14 Nov 2011 13:07:35 GMT Message-Id: <201111141307.pAED7Zi2019728@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 14 Nov 2011 13:07:41 +0000 To: From: Bob Briscoe In-Reply-To: <9510D26531EF184D9017DF24659BB87F330E144552@EMV65-UKRD.doma in1.systemhost.net> References: <9510D26531EF184D9017DF24659BB87F330E144552@EMV65-UKRD.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 14 Nov 2011 13:07:42.0444 (UTC) FILETIME=[64C422C0:01CCA2CE] Cc: ConEx IETF list Subject: Re: [conex] FW: comments on draft-briscoe-conex-initial-deploy 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, 14 Nov 2011 13:07:53 -0000 Phil, [I didn't get the first email. Don't know what happened there, cos I'm registered with my bt.com address for this draft, not jungle. Did you get a bounce message?] Thanks for this - very useful (as your reviews always are). Responses inline. At 09:14 09/11/2011, philip.eardley@bt.com wrote: >In case email distorts, here is the pic It was OK in email, but useful to see how different ASCII editors and email display the same ASCII differently! I'm not entirely happy with either diag, but yours gives me food for thought - I'll ruminate on it. >- also the paper which ruminated on the isp runs cdn & nw scenario. >Not sure i completely believe it, but might be useful text? I will refer to this paper as an alternative scenario. I find this scenario less believable, because the benefit is small and the effort large. In the I-D I'm trying to show that there is a ConEx deployment path with clear benefits for all. More... >phil > > >-----Original Message----- >From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On >Behalf Of philip.eardley@bt.com >Sent: 09 November 2011 09:12 >To: conex@ietf.org >Subject: [conex] comments on draft-briscoe-conex-initial-deploy > >http://tools.ietf.org/id/draft-briscoe-conex-initial-deploy-00.txt > > >Bob, >thanks for the draft, think it's important to have started this. >some comments. > >I think you could start at S4. the earlier sections stop the reader >getting rapidly to the main bit of the doc. My judgement is that only a very few people have ConEx sufficiently in their head not to need a recap. I will move 3.2 to later (or delete it). However, I would rather put a note at the end of the Intro saying that a page of recap bullets follows, and the reader can jump to the meat if they don't need recap. Then I would keep the page of abstract-mech recap where it is (currently sections 2 & 3.1). >You start by saying that the initial step is a ledbat source is >conex enabled; the second step is the network becomes conex-enabled. >personally i wouldn't call this "unilateral deploymet by a single >network" (scope of draft in S1). Talk of this ledbat-conex source >somewhat disappears later on. if this is the deployment path, it >also raises the question of what's the deployment incentive for >ledbat, is this clear-cut? True. I should expand the para about incentives to deploy ConEx for end-hosts at the end of the first para of S.4 (before any of the use-cases 4.1-4.3). There is more to say about this: - Examples of other cases where end-hosts have deployed a protocol speculatively, in the expectation the network will deploy something in response (e.g. uTP). - The protocol must have near-zero probability of causing negative side-effects (e.g. getting snarled in certain middleboxes). Even a v low probability will tip the scales against speculative deployment. - Some of the later scenarios involve a more co-ordinated deployment on end-hosts and network (e.g. mobile and data centre). S.4.1.2 talks about operator incentives to deploy. I wanted to say what it is that an operator deploys before talking about incentives to deploy it. However, you're right that readers need motivation before detail, rather than the other way round. I'll rethink. >I attempted to re-draw figure 1, see below, see if you think it's clearer. > >I think it would be clearer if the conex-ISP just ran the network - >dividing into core and access seems unnecessary detail [at least >until the basic deployment scenario is clear] The reason for the division is not to do with ownership, but to do with where congestion is most likely. I don't know whether you got down to my detailed description, but the BRAS encapsulates congestion in multiple places. This makes audit feasible without needing ECN deployment. This is why the diag must have the BRAS on it IMO. I need to say that the incentive for one network to deploy is: a) to be able to coordinate its response to all the different inputs when there is no single place where all incoming traffic passes through. ConEx gives the network info to be able to do distributed traffic management without tromboning all traffic through one box. b) to encourage scavenger behaviour >I think the initial deployment step is where the ISP runs the >network & a data centre - the DC has conex-enabled conex sources >(which are trusted about their conex markings, since they're under >ISP's control). Isn't that a pointless scenario? What is the beneficial effect of deploying ConEx that couldn't be achieved with trust anyway? I'd rather stick with the scavenger motivation and mention your scenario as an alternative and cite your paper for details. >you need to mention how other traffic is handled. S.4.1.2 covers this. I agree it could be mentioned earlier then referred forward to S4.1.2. >a step beyond the initial one is where other senders are >conex-enabled, but not trusted (i wouldn't include them on fig 1) - >only at that stage might ledbat become relevant. As above, isn't it pointless before scavenger becomes relevant? What was the beneficial effect before scavenger? >I think the scenario is that the DC-ISP offers a premium service to >content providers, which internally it implements using conex. You're wanting to write a different scenario. Why would a network use a new protocol (ConEx) in order to do something it can do with an existing one (Diffserv)? Or am I misunderstanding what you mean by premium? >anyway, i think the WG should decide whether the initial deployment >case is via ledbat or a conex-core also running a DC. or via mobile >network or internal to data centre. Certainly. I'll get Andrea to ask that in the presentation on Thu. And I'll ask in a focused posting to the ML. However, the charter already says we have to focus on the receiving network scenario (whatever that means). Mobile and data centre are brought in, because they are other believable scenarios. Thank you again. Bob >thanks, >phil > >---- > <---- Single ISP operates ----> > data centre & core & access networks > all are ConEx-enabled > > _________ _______ ____ > | CORE | |ACCESS | |HOME| > | NETWORK |NETWORK| |NET | > _________ | | | | | | > | ISP's | | | | | | | > | data | | | | | | | > | centre | | | | | | | > | | | | | | | | > | +-------+ +-------+ | | | | | > | |trusted| | ConEx | | | | | | > | | ConEx | => | | | | | | | > | |sender | |monitor| | => | | => | | > | +-------+ +-------+ | | | | | > | | | | | | | | > |_________| | | | | | | > _________ | | | | | | >| ConEx- | ___ | | | | | | >|enabled | | | | CORE | |ACCESS | |HOME| >| CDN | | | | NETWORK | |NETWORK| |NET | >| | | I | | | | | | | >| +-------+ | | | | | | | | >| | Non- | | N | +-------+ | | | | | >| |trusted| | | | Non- | | | | | | >| | ConEx | => |==>| ==============> | ConEx | | => | | => | | >| |sender | | | |policer| | | | | | >| +-------+ | T | +-------+ | | | | | >|_________| | | | | | | | | > | E | | | | | | | > | | | | | | | | > _________ | R | | | | | | | >|'legacy' | | | | | | | | | >| | | N | | | | | | | >| +-------+ | | +-------+ | +-----+ | | | >| | Non- | | E | | ConEx | | |ConEx| | | | >| | ConEx | => |==>| ==============> | | | => | | | => | | >| |sender | | | |policer| | |audit| | | | >| +-------+ | T | +-------+ | +-----+ | | | >| | | | | | | | | | >|_________| |___| | | | | | | > | | | | | | > |_________| |_______| |____| > > > > >Philip Eardley >Research and Technology Strategy > >This email contains BT information, which may be privileged or >confidential. It's meant only for the individual(s) or entity named >above. If you're not the intended recipient, note that disclosing, >copying, distributing or using this information is prohibited. If >you've received this email in error, please let me know immediately >on the email address above. Thank you. We monitor our email system, >and may record your emails. >British Telecommunications plc >Registered office: 81 Newgate Street London EC1A 7AJ >Registered in England no: 1800000 >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex > > ________________________________________________________________ Bob Briscoe, BT Innovate & Design From mirja.kuehlewind@ikr.uni-stuttgart.de Mon Nov 14 08:42:43 2011 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 CF26D1F0C78 for ; Mon, 14 Nov 2011 08:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, 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 8PNsqStMCXMX for ; Mon, 14 Nov 2011 08:42:42 -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 B95571F0C73 for ; Mon, 14 Nov 2011 08:42:42 -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 7A09B633B1; Mon, 14 Nov 2011 17:42:40 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 1783559A8A; Mon, 14 Nov 2011 17:42:40 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: conex@ietf.org Date: Mon, 14 Nov 2011 17:42:38 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <20111030141755.21962.83789.idtracker@ietfa.amsl.com> <20111107160135.GA45061@verdi> In-Reply-To: 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: <201111141742.38336.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: Ingemar Johansson S 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: Mon, 14 Nov 2011 16:42:43 -0000 Hi Ingemar, yes there are only sender-side modification needed. If you only have=20 the 'classic' ECN, you will only be able to get (at max) one congestion=20 notification per RTT. If there is more than one CE marking per RTT you will= =20 underestimate the congestion. Mirja On Monday 14 November 2011 11:16:04 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 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 =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 ingemar.s.johansson@ericsson.com Tue Nov 15 00:26:02 2011 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 C8E9621F8D30 for ; Tue, 15 Nov 2011 00:26:02 -0800 (PST) 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=[BAYES_00=-2.599, 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 a+rql-trzlir for ; Tue, 15 Nov 2011 00:26:01 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 99DFF21F8D1F for ; Tue, 15 Nov 2011 00:26:01 -0800 (PST) X-AuditID: c1b4fb3d-b7c26ae0000035b9-a0-4ec2221862df Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 68.29.13753.81222CE4; Tue, 15 Nov 2011 09:26:00 +0100 (CET) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.53]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 15 Nov 2011 09:25:59 +0100 From: Ingemar Johansson S To: Mirja Kuehlewind , "conex@ietf.org" Date: Tue, 15 Nov 2011 09:25:57 +0100 Thread-Topic: [conex] ConEx as sender side only modification Thread-Index: Acyi7G1lvsYaNDVfT3ugbT7K+KHp6wAgr58g Message-ID: References: <20111030141755.21962.83789.idtracker@ietfa.amsl.com> <20111107160135.GA45061@verdi> <201111141742.38336.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201111141742.38336.mirja.kuehlewind@ikr.uni-stuttgart.de> 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== 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: Tue, 15 Nov 2011 08:26:02 -0000 Thanks This then means that a policer need to give some extra slack for normal TCP= . It is perhaps doable with a policer that somehow has access to the TCP ac= ks in the reverse direction and then can determine both RTT with a reasonab= le accuracy and also if TCP ECE is modified according to (http://tools.ietf= .org/id/draft-kuehlewind-conex-tcp-modifications-01.txt)=20 Or is this perhaps simpler ? /Ingemar PS Realized that I got things a bit backwards in my question below, thought th= at ECE is clamped to 1 for an RTT... > -----Original Message----- > From: Mirja Kuehlewind [mailto:mirja.kuehlewind@ikr.uni-stuttgart.de]=20 > Sent: den 14 november 2011 17:43 > To: conex@ietf.org > Cc: Ingemar Johansson S > Subject: Re: [conex] ConEx as sender side only modification >=20 > Hi Ingemar, >=20 > yes there are only sender-side modification needed. If you=20 > only have the 'classic' ECN, you will only be able to get (at=20 > max) one congestion notification per RTT. If there is more=20 > than one CE marking per RTT you will underestimate the congestion. >=20 > Mirja >=20 >=20 > On Monday 14 November 2011 11:16:04 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 a=20 > > 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 to=20 > > the server. Does this then mean that a TCP flow (unmodified=20 > TCP) will=20 > > 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 >=20 >=20 >=20 > -- > ------------------------------------------------------------------- > Dipl.-Ing. Mirja K=FChlewind > Institute of Communication Networks and Computer Engineering=20 > (IKR) University of Stuttgart, Germany Pfaffenwaldring 47,=20 > D-70569 Stuttgart >=20 > tel: +49(0)711/685-67973 > email: mirja.kuehlewind@ikr.uni-stuttgart.de > web: www.ikr.uni-stuttgart.de > ------------------------------------------------------------------- > = From marcelo@it.uc3m.es Wed Nov 16 17:52:31 2011 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 85BE91F0C57 for ; Wed, 16 Nov 2011 17:52:31 -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 rdW5zrT4mSvh for ; Wed, 16 Nov 2011 17:52:31 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 13DD51F0C61 for ; Wed, 16 Nov 2011 17:52:28 -0800 (PST) X-uc3m-safe: yes Received: from dhcp-17e7.meeting.ietf.org (dhcp-17e7.meeting.ietf.org [130.129.23.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id F40649CB43A for ; Thu, 17 Nov 2011 02:52:25 +0100 (CET) Message-ID: <4EC468D5.5040009@it.uc3m.es> Date: Thu, 17 Nov 2011 02:52:21 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 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-18524.003 Subject: [conex] WGLC for draft-ietf-conex-abstract-mech-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, 17 Nov 2011 01:52:31 -0000 This note issues the WGLC for draft-ietf-conex-abstract-mech-03.txt. (http://www.ietf.org/id/draft-ietf-conex-abstract-mech-03.txt) Please review the document and send comments before the 5th december. Thanks, marcelo From marcelo@it.uc3m.es Wed Nov 16 17:54:12 2011 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 9F18D1F0C98 for ; Wed, 16 Nov 2011 17:54: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 rz+uLMv3Dzjt for ; Wed, 16 Nov 2011 17:54:12 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6641F0C6D for ; Wed, 16 Nov 2011 17:53:22 -0800 (PST) X-uc3m-safe: yes Received: from dhcp-17e7.meeting.ietf.org (dhcp-17e7.meeting.ietf.org [130.129.23.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 484D09CB3E3 for ; Thu, 17 Nov 2011 02:53:19 +0100 (CET) Message-ID: <4EC4690C.2060707@it.uc3m.es> Date: Thu, 17 Nov 2011 02:53:16 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 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-18524.003 Subject: [conex] WGLC for draft-ietf-conex-concepts-uses-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, 17 Nov 2011 01:54:12 -0000 This note issues the WGLC for draft-ietf-conex-concepts-uses-03.txt. (http://www.ietf.org/id/draft-ietf-conex-concepts-uses-03.txt) Please review the document and send comments before the 5th december. Thanks, marcelo From john@jlc.net Thu Nov 17 06:22:35 2011 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 1974611E813D for ; Thu, 17 Nov 2011 06:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.538 X-Spam-Level: X-Spam-Status: No, score=-106.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 qYSrxXdVS+U6 for ; Thu, 17 Nov 2011 06:22:34 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2F311E813B for ; Thu, 17 Nov 2011 06:22:34 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id E8B3533C21; Thu, 17 Nov 2011 09:22:30 -0500 (EST) Date: Thu, 17 Nov 2011 09:22:30 -0500 From: John Leslie To: marcelo bagnulo braun Message-ID: <20111117142230.GD8483@verdi> References: <4EC468D5.5040009@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EC468D5.5040009@it.uc3m.es> User-Agent: Mutt/1.4.1i Cc: 'ConEx IETF list' Subject: Re: [conex] WGLC for draft-ietf-conex-abstract-mech-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, 17 Nov 2011 14:22:35 -0000 marcelo bagnulo braun wrote: > > This note issues the WGLC for draft-ietf-conex-abstract-mech-03.txt. > (http://www.ietf.org/id/draft-ietf-conex-abstract-mech-03.txt) This LastCall seems way premature. abstract-mech as it stands depends heavily on ReECN, which is quite outside our charter. I believe it should instead discuss mechanism such as the Destination Option we seem to be headed to (unless someone can convince me there are other mechanisms being seriously considered). YMMV, I suppose... > Please review the document and send comments before the 5th december. I am willing to go into particulars; but that seems a bit pointless until we get some consensus on whether ReECN is the proper primary focus. -- John Leslie From bob.briscoe@bt.com Thu Nov 17 10:50:29 2011 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 410B611E80A6 for ; Thu, 17 Nov 2011 10:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.087 X-Spam-Level: X-Spam-Status: No, score=-3.087 tagged_above=-999 required=5 tests=[AWL=0.513, 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 f2MVrlRhjEEp for ; Thu, 17 Nov 2011 10:50:28 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by ietfa.amsl.com (Postfix) with ESMTP id 75F1011E8095 for ; Thu, 17 Nov 2011 10:50:28 -0800 (PST) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Nov 2011 18:50:26 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Nov 2011 18:50: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 1321555824174; Thu, 17 Nov 2011 18:50:24 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.80.227]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id pAHIoM2P008433; Thu, 17 Nov 2011 18:50:22 GMT Message-Id: <201111171850.pAHIoM2P008433@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 17 Nov 2011 18:50:09 +0000 To: John Leslie From: Bob Briscoe In-Reply-To: <20111117142230.GD8483@verdi> References: <4EC468D5.5040009@it.uc3m.es> <20111117142230.GD8483@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 17 Nov 2011 18:50:25.0601 (UTC) FILETIME=[C49A2310:01CCA559] Cc: 'ConEx IETF list' Subject: Re: [conex] WGLC for draft-ietf-conex-abstract-mech-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, 17 Nov 2011 18:50:29 -0000 John, You've correctly pointed out a hang-over from when the doc started from re-ECN. We intended to change it to start from destopt, before justifying a generalisation to abstract requirements. See the start of S.3 " the experimental ConEx encoding chosen for IPv6 [I-D.ietf-conex-destopt] had to make compromises on tunnelling. The abstract encoding requirements that follow still stand despite this choice, in case experience shows these were not the best compromises to make." However, you're right that we haven't toned down the re-ECN-based entry-point to the doc that follows just after this, before it again justifies generalising out to abstract requirements. Re-ECN does rather act as the anchor throughout the rest of S3. Nonetheless, this is surely a wrinkle to remove, not something that causes everyone to have to stop in their tracks, stop the WGLC, press the PANIC button and prevent the sky from falling. I don't believe it leads to any /technical/ problems with the draft. Bob At 14:22 17/11/2011, John Leslie wrote: >marcelo bagnulo braun wrote: > > > > This note issues the WGLC for draft-ietf-conex-abstract-mech-03.txt. > > (http://www.ietf.org/id/draft-ietf-conex-abstract-mech-03.txt) > > This LastCall seems way premature. > > abstract-mech as it stands depends heavily on ReECN, which is quite >outside our charter. I believe it should instead discuss mechanism >such as the Destination Option we seem to be headed to (unless someone >can convince me there are other mechanisms being seriously considered). > > YMMV, I suppose... > > > Please review the document and send comments before the 5th december. > > I am willing to go into particulars; but that seems a bit pointless >until we get some consensus on whether ReECN is the proper primary >focus. > >-- >John Leslie >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design From mattmathis@google.com Fri Nov 18 13:41:02 2011 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 EFCE91F0C81 for ; Fri, 18 Nov 2011 13:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.993 X-Spam-Level: X-Spam-Status: No, score=-101.993 tagged_above=-999 required=5 tests=[AWL=-0.683, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, 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 WmAiVu+99WIT for ; Fri, 18 Nov 2011 13:41:02 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id C6A391F0C7D for ; Fri, 18 Nov 2011 13:41:01 -0800 (PST) Received: by eyg24 with SMTP id 24so4609193eyg.31 for ; Fri, 18 Nov 2011 13:41:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=CHo7NxMlsnX4UrImbw/sCE6ZS8BBOkQw52jCQC077QE=; b=nvmICCHG0QqyPrQxuOjqqjSwTeXImrxx/kWZ5Yi7NB6vtRyh+7ErRzVRcKSUcV6zgm 8lfADQ6dD9gm6Eia0Ygg== Received: by 10.14.11.131 with SMTP id 3mr364613eex.232.1321652459254; Fri, 18 Nov 2011 13:40:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.14.11.131 with SMTP id 3mr364608eex.232.1321652458935; Fri, 18 Nov 2011 13:40:58 -0800 (PST) Received: by 10.213.112.147 with HTTP; Fri, 18 Nov 2011 13:40:58 -0800 (PST) In-Reply-To: <201111171850.pAHIoM2P008433@bagheera.jungle.bt.co.uk> References: <4EC468D5.5040009@it.uc3m.es> <20111117142230.GD8483@verdi> <201111171850.pAHIoM2P008433@bagheera.jungle.bt.co.uk> Date: Fri, 18 Nov 2011 13:40:58 -0800 Message-ID: From: Matt Mathis To: John Leslie Content-Type: multipart/alternative; boundary=001485f5b1b654d5ee04b2093166 X-System-Of-Record: true Cc: ConEx IETF list Subject: Re: [conex] WGLC for draft-ietf-conex-abstract-mech-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: Fri, 18 Nov 2011 21:41:03 -0000 --001485f5b1b654d5ee04b2093166 Content-Type: text/plain; charset=ISO-8859-1 John I don't understand your point at all. -destopt- is an example of a specific encoding that is consistent with abstract mech. I actually have a different problem with that text: abstract mech is likely to be done long before the final publication for -destopt- ready, which means that it might be held up by dangling references. At the last IETF it was suggested that abstract mech needs to reference more of the current ConEx documents. However after re-reviewing the text I realized that to be the best possible foundation for future work -abstract-mech- should strongly site already completed (past) work but only hint at the future. And it certainly should not comment on documents that will not be completed until after it is done. (Part of the problem is the citation is really for the specific version of the ID, but during the rfc editor process, citation will be (incorrectly) updated to point to future drafts or even the final version of destopt, at which point the text will no longer be correct, furthermore this process will delay publication of abstract mech.) Circular references between RFCs need to be deliberate and carefully managed. Sorry I didn't catch this earlier. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay On Thu, Nov 17, 2011 at 10:50 AM, Bob Briscoe wrote: > John, > > You've correctly pointed out a hang-over from when the doc started from > re-ECN. > > We intended to change it to start from destopt, before justifying a > generalisation to abstract requirements. See the start of S.3 > > " the experimental ConEx encoding chosen for IPv6 > [I-D.ietf-conex-destopt] had to make compromises on tunnelling. The > abstract encoding requirements that follow still stand despite this > choice, in case experience shows these were not the best compromises > to make." > > However, you're right that we haven't toned down the re-ECN-based > entry-point to the doc that follows just after this, before it again > justifies generalising out to abstract requirements. Re-ECN does rather act > as the anchor throughout the rest of S3. > > Nonetheless, this is surely a wrinkle to remove, not something that causes > everyone to have to stop in their tracks, stop the WGLC, press the PANIC > button and prevent the sky from falling. I don't believe it leads to any > /technical/ problems with the draft. > > > Bob > > > At 14:22 17/11/2011, John Leslie wrote: > >> marcelo bagnulo braun wrote: >> > >> > This note issues the WGLC for draft-ietf-conex-abstract-**mech-03.txt. >> > (http://www.ietf.org/id/draft-**ietf-conex-abstract-mech-03.**txt >> ) >> >> This LastCall seems way premature. >> >> abstract-mech as it stands depends heavily on ReECN, which is quite >> outside our charter. I believe it should instead discuss mechanism >> such as the Destination Option we seem to be headed to (unless someone >> can convince me there are other mechanisms being seriously considered). >> >> YMMV, I suppose... >> >> > Please review the document and send comments before the 5th december. >> >> I am willing to go into particulars; but that seems a bit pointless >> until we get some consensus on whether ReECN is the proper primary >> focus. >> >> -- >> John Leslie >> ______________________________**_________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/**listinfo/conex >> > > ______________________________**______________________________**____ > Bob Briscoe, BT Innovate & Design > ______________________________**_________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/**listinfo/conex > --001485f5b1b654d5ee04b2093166 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable John I don't understand your point at all. =A0-destopt- is an example o= f a specific encoding that is consistent with abstract mech.

=
I actually have a different problem with that text: abstract mech is= =A0likely to be done long before=A0the final publication for -destopt- read= y, which means that it might be held up by=A0dangling=A0references. =A0 =A0= At the last IETF it was suggested that abstract mech needs to reference mor= e of the current ConEx documents. =A0However after re-reviewing the text I = realized that to be the best possible=A0foundation=A0for future work -abstr= act-mech- should strongly site already completed (past) work but only hint = at the=A0future. =A0And it=A0certainly=A0should not comment on documents th= at will not be completed until after it is done.

(Part of the problem is the citation is really for the = specific version of the ID, but during the rfc editor process, citation wil= l be (incorrectly) updated to point to future drafts or even the final vers= ion of destopt, at which point the text will no longer be correct, furtherm= ore this process will delay publication of abstract mech.)

Circular references between RFCs need to be deliberate = and carefully managed.

Sorry I didn't catch th= is earlier.

Thanks,
--M= M--
The best way to predict the future is to create it. =A0- Alan Kay



On Thu, Nov 17, 2011 at 10:50 AM, Bob Br= iscoe <bob.brisc= oe@bt.com> wrote:
John,

You've correctly pointed out a hang-over from when the doc started from= re-ECN.

We intended to change it to start from destopt, before justifying a general= isation to abstract requirements. See the start of S.3
" =A0 the experimental ConEx encoding chosen for IPv6
=A0 [I-D.ietf-conex-destopt] had to make compromises on tunnelling. =A0The=
=A0 abstract encoding requirements that follow still stand despite this =A0 choice, in case experience shows these were not the best compromises =A0 to make."

However, you're right that we haven't toned down the re-ECN-based e= ntry-point to the doc that follows just after this, before it again justifi= es generalising out to abstract requirements. Re-ECN does rather act as the= anchor throughout the rest of S3.

Nonetheless, this is surely a wrinkle to remove, not something that causes = everyone to have to stop in their tracks, stop the WGLC, press the PANIC bu= tton and prevent the sky from falling. I don't believe it leads to any = /technical/ problems with the draft.


Bob


At 14:22 17/11/2011, John Leslie wrote:
marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:
>
> This note issues the WGLC for draft-ietf-conex-abstract-mech-03= .txt.
> (http://www.ietf.org/id/draft-ietf-conex-abstra= ct-mech-03.txt)

=A0 This LastCall seems way premature.

=A0 abstract-mech as it stands depends heavily on ReECN, which is quite outside our charter. I believe it should instead discuss mechanism
such as the Destination Option we seem to be headed to (unless someone
can convince me there are other mechanisms being seriously considered).

=A0 YMMV, I suppose...

> Please review the document and send comments before the 5th december.<= br>
=A0 I am willing to go into particulars; but that seems a bit pointless until we get some consensus on whether ReECN is the proper primary
focus.

--
John Leslie <john@jlc.= net>
_______________________________________________
conex mailing list
conex@ietf.org
h= ttps://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
h= ttps://www.ietf.org/mailman/listinfo/conex

--001485f5b1b654d5ee04b2093166-- From bob.briscoe@bt.com Sun Nov 20 11:56:32 2011 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 0682221F8672 for ; Sun, 20 Nov 2011 11:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.843 X-Spam-Level: X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=-0.845, BAYES_50=0.001, HTML_MESSAGE=0.001, 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 AiYRiwKpn5vA for ; Sun, 20 Nov 2011 11:56:30 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by ietfa.amsl.com (Postfix) with ESMTP id 5890B21F8663 for ; Sun, 20 Nov 2011 11:56:30 -0800 (PST) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 20 Nov 2011 19:56:27 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 20 Nov 2011 19:56:27 +0000 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 1321818986587; Sun, 20 Nov 2011 19:56:26 +0000 Received: from MUT.jungle.bt.co.uk ([10.142.208.72]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id pAKJuJSQ007421; Sun, 20 Nov 2011 19:56:21 GMT Message-Id: <201111201956.pAKJuJSQ007421@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 20 Nov 2011 19:56:14 +0000 To: Matt Mathis From: Bob Briscoe In-Reply-To: References: <201111171402.pAHE26tB006646@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_632751959==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 20 Nov 2011 19:56:27.0386 (UTC) FILETIME=[7D3FCDA0:01CCA7BE] Cc: ConEx IETF list Subject: Re: [conex] byte vs packet 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: Sun, 20 Nov 2011 19:56:32 -0000 --=====================_632751959==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Matt, [Adding the ConEx list back in] I think we're both now agreeing that the /goal/ should be byte-balance for ConEx auditing. Correct? I am also in full agreement that this goal isn't always easy to meet if retrofitting ConEx onto an existing transport like TCP. It works if the packet sizes are regular, but if they are lumpy, the sender is likely to understate or overstate. And I agree that these aren't necessarily just corner-cases (well, I guess there is a large set of cases with regular packet sizes, but the corner is also quite large). You ask what I think we should do about this. My view, we should: a) state what the goal should be for all transports (byte-balance) b) give advice on how to implement a TCP sender to do as well as it can c) run experiments and see whether the outcome is good enough, or if further protocol mechanism is needed. Concerning (b) advice on the best that TCP implementations can do: - the TCP receiver (if optionally supporting ConEx) should suppress ACK delay whenever it detects congestion and instead give immediate feedback - TCP sender can use ack sequence numbers to improve its guess of the required size of an re-echo-loss or re-echo-ECN - If the receiver is not ConEx-aware, a sender that knows it is sending lumpy packet sizes can introduce additional credit to cover any mistakes. If a ConEx sender does unintentionally understate bytes of congestion, the auditor will discard some packets, then the sender will redress the balance with some more re-echo-loss and it should all heal itself, albeit having suffered some losses in the process. Do you think this is sufficient (at least to run experiments to test whether it is)? Bob At 20:55 18/11/2011, Matt Mathis wrote: >So here is a pathology: I have an application that sends 15001 bytes >(10 segments + 1 byte), followed by 1 byte beacons every 10 second >for 100 seconds and then the entire pattern repeats (total of >10*1500 + 10*1 segments every 100 seconds). > >Now suppose there are ECN marks near the end of the burst on every >repeat. How does this get signaled, and what is the correct sender >response? Due to delayed ACKs it may be ambiguous exactly which >segment was marked (e.g. was it 1500 or 1 bytes?) Even if the >sender knows for sure that it was the 1500 byte segment that was >marked, it has to wait until the next burst to send the proper feedback. > >The problem is the ACKs carry the count of the number of marked >segments, not marked bytes. Also the re-feed itself has no size, >except the length of the segments carrying it. > >What do you think should happen in this case? >(BTW modern persistent web protocols, such as SPDY do stuff like >this all the time, although perhaps not as extreme as my >example. BGP also has streaming data with very irregular message sizes.) > >This would be completely clear if the ACKs and re-feedback were >counts of bytes. > >Thanks, >--MM-- >The best way to predict the future is to create it. - Alan Kay > > > >On Thu, Nov 17, 2011 at 7:07 PM, Matt Mathis ><mattmathis@google.com> wrote: > >I'm sorry I did not make my self clear. I understand and agree with >your argument. > >The problem is when the forward path is carrying lumpy data : highly >irregular segment sizes, typical of streaming media, p-http, or bgp >at edge of the onset of congestion. When there is an ecn mark the >ack only indicates that a segment was marked and not its size. If >the sender has a choice of segments to re-feedback it has has no >idea which to choose. Worse it >may not have a choice. Furthermore under pathological conditions >it will persistently get it wrong. > >I can explain better when I have a real. Keyboard. >On Nov 17, 2011 10:02 PM, "Bob Briscoe" ><bob.briscoe@bt.com> wrote: >Matt, > >This issue has come up in at least two threads recently: >"Congestion" vs. "Congestion Volume" and "byte-counting in conex-destopt" > >Consider the buffer into the high speed line you were talking about >this morning - it holds packets in equal MTU-sized packet buffers, >whatever the packet size. > >When it buffers packets, we need to ask what exactly is congested: >the line or the buffer? In this case, the line is congested. Packets >are temporarily in the buffer because more bits arrived than >departed. The queue is merely a symptom of how congested the line >is. Certainly, once the buffer gets full, we could say the buffer >has become congested too. But the root of the problem is how fast >the line can carry away the bits. > >If the queue was building up behind forwarding look-ups or a >firewall, then the problem would be the number of packets headers, >not bits. But if it's a queue into a transmission line, the problem is bits. > >The point is, whether to count bits or packets depends on the >process /in front/ of the queue (whether its a bit transmission line >or processing packet headers). The internals of the buffer itself >are irrelevant. > >Then the question is how prevalent are per-packet processes as >sources of congestion? Answer: There seems to be good reason why >per-packet congestion will remain in the minority relative to per-byte... > >During the process of writing draft-ietf-byte-pkt-congest, all the >machine design folk who were consulted said that machines are >generally designed so that any per-packet-processing can cope with a >workload at line rate consisting mostly of small packets. > >IOW, machine designs tend to use bit-congestion to protect the >packet-processor from congestion. > >____________________ >For those who prefer an example, assume: >MTU, M = 1,500B = 12,000b >Line rate, X = 48Gbps > >[The numbers are chosen to make the maths easy, not to reflect >typical scenarios. I'm going to work in bits not bytes from now on.] > >Imagine at some time that 260 of these fixed-size packet buffers are >full, with 10 large and 250 small packets. > >packet size | S | 12,000b | 480b | >no. pkts buffered | N | 10 | 250 | >buffer space used | NM | 120kb | 3Mb | >pkt bits buffered | NS | 120kb | 120kb | >time to drain all | NS/X | 2,500ns | 2,500ns | > >Although each small packet takes up the same space in the buffer as >a large packet, it's faster to get rid of it. 250 small packets take >as long to drain as 10 large packets. > > >Bob > > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design > ________________________________________________________________ Bob Briscoe, BT Innovate & Design --=====================_632751959==.ALT Content-Type: text/html; charset="us-ascii" Matt,

[Adding the ConEx list back in]

I think we're both now agreeing that the /goal/ should be byte-balance for ConEx auditing. Correct?

I am also in full agreement that this goal isn't always easy to meet if retrofitting ConEx onto an existing transport like TCP. It works if the packet sizes are regular, but if they are lumpy, the sender is likely to understate or overstate. And I agree that these aren't necessarily just corner-cases (well, I guess there is a large set of cases with regular packet sizes, but the corner is also quite large).

You ask what I think we should do about this. My view, we should:
a) state what the goal should be for all transports (byte-balance)
b) give advice on how to implement a TCP sender to do as well as it can
c) run experiments and see whether the outcome is good enough, or if further protocol mechanism is needed.

Concerning (b) advice on the best that TCP implementations can do:
- the TCP receiver (if optionally supporting ConEx) should suppress ACK delay whenever it detects congestion and instead give immediate feedback
- TCP sender can use ack sequence numbers to improve its guess of the required size of an re-echo-loss or re-echo-ECN
- If the receiver is not ConEx-aware, a sender that knows it is sending lumpy packet sizes can introduce additional credit to cover any mistakes.

If a ConEx sender does unintentionally understate bytes of congestion, the auditor will discard some packets, then the sender will redress the balance with some more re-echo-loss and it should all heal itself, albeit having suffered some losses in the process.

Do you think this is sufficient (at least to run experiments to test whether it is)?



Bob

At 20:55 18/11/2011, Matt Mathis wrote:
So here is a pathology: I have an application that sends 15001 bytes (10 segments + 1 byte), followed by 1 byte beacons every 10 second for 100 seconds and then the entire pattern repeats (total of 10*1500 + 10*1 segments every 100 seconds). 

Now suppose there are ECN marks near the end of the burst on every repeat.   How does this get signaled, and what is the correct sender response?   Due to delayed ACKs it may be ambiguous exactly which segment was marked (e.g. was it 1500 or 1 bytes?)   Even if the sender knows for sure that it was the 1500 byte segment that was marked, it has to wait until the next burst to send the proper feedback.

The problem is the ACKs carry the count of the number of marked segments, not marked bytes.  Also the re-feed itself has no size, except the length of the segments carrying it.

What do you think should happen in this case?
(BTW modern persistent web protocols, such as SPDY do stuff like this all the time, although perhaps not as extreme as my example.   BGP also has streaming data with very irregular message sizes.)

This would be completely clear if the ACKs and re-feedback were counts of bytes.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay



On Thu, Nov 17, 2011 at 7:07 PM, Matt Mathis <mattmathis@google.com> wrote:

I'm sorry I did not make my self clear. I understand and agree with your argument.

The problem is when the forward path is carrying lumpy data : highly irregular segment sizes, typical of streaming media, p-http, or bgp at edge of the onset of congestion. When there is an ecn mark the ack  only indicates that a segment was marked and not its size. If the sender has a choice of segments to re-feedback it has has no idea which to choose.  Worse it
may not have a choice.   Furthermore under pathological conditions it will persistently get it wrong. 

I can explain better when I have a real. Keyboard.
On Nov 17, 2011 10:02 PM, "Bob Briscoe" <bob.briscoe@bt.com> wrote:
Matt,

This issue has come up in at least two threads recently: "Congestion" vs. "Congestion Volume" and "byte-counting in conex-destopt"

Consider the buffer into the high speed line you were talking about this morning - it holds packets in equal MTU-sized packet buffers, whatever the packet size.

When it buffers packets, we need to ask what exactly is congested: the line or the buffer? In this case, the line is congested. Packets are temporarily in the buffer because more bits arrived than departed. The queue is merely a symptom of how congested the line is. Certainly, once the buffer gets full, we could say the buffer has become congested too. But the root of the problem is how fast the line can carry away the bits.

If the queue was building up behind forwarding look-ups or a firewall, then the problem would be the number of packets headers, not bits. But if it's a queue into a transmission line, the problem is bits.

The point is, whether to count bits or packets depends on the process /in front/ of the queue (whether its a bit transmission line or processing packet headers). The internals of the buffer itself are irrelevant.

Then the question is how prevalent are per-packet processes as sources of congestion? Answer: There seems to be good reason why per-packet congestion will remain in the minority relative to per-byte...

During the process of writing draft-ietf-byte-pkt-congest, all the machine design folk who were consulted said that machines are generally designed so that any per-packet-processing can cope with a workload at line rate consisting mostly of small packets.

IOW, machine designs tend to use bit-congestion to protect the packet-processor from congestion.

____________________
For those who prefer an example, assume:
MTU,       M = 1,500B = 12,000b
Line rate, X =    48Gbps

[The numbers are chosen to make the maths easy, not to reflect typical scenarios. I'm going to work in bits not bytes from now on.]

Imagine at some time that 260 of these fixed-size packet buffers are full, with 10 large and 250 small packets.

packet size       | S    | 12,000b  |   480b   |
no. pkts buffered | N    |     10   |   250    |
buffer space used | NM   |    120kb |     3Mb  |
pkt bits buffered | NS   |    120kb |   120kb  |
time to drain all | NS/X |  2,500ns | 2,500ns  |

Although each small packet takes up the same space in the buffer as a large packet, it's faster to get rid of it. 250 small packets take as long to drain as 10 large packets.


Bob


________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design --=====================_632751959==.ALT-- From john@jlc.net Sun Nov 20 13:40:14 2011 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 647AA21F85B1 for ; Sun, 20 Nov 2011 13:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.54 X-Spam-Level: X-Spam-Status: No, score=-106.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 DiDiEjxE1oax for ; Sun, 20 Nov 2011 13:40:13 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6D01021F8564 for ; Sun, 20 Nov 2011 13:40:13 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 8CA9833C20; Sun, 20 Nov 2011 16:40:12 -0500 (EST) Date: Sun, 20 Nov 2011 16:40:12 -0500 From: John Leslie To: Bob Briscoe Message-ID: <20111120214012.GE22465@verdi> References: <201111171402.pAHE26tB006646@bagheera.jungle.bt.co.uk> <201111201956.pAKJuJSQ007421@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201111201956.pAKJuJSQ007421@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Cc: ConEx IETF list Subject: Re: [conex] byte vs packet 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: Sun, 20 Nov 2011 21:40:14 -0000 Bob Briscoe wrote: > > Matt, (I do understand that Bob is addressing Matt...) > [Adding the ConEx list back in] I do not agree that this is a discussion which should gate on the opinions of Bob and Matt. I do understand that both of these folks think they understand the mathematical issues involved better than the rest of us. They may well be right. But this is an IETF Working Group, not an academic paper review board. I'm not interested in arguing mathematics -- I believe we need to discuss how to get a protocol which enough operators will implement. And I'm interested in arguments of what will harm our chances of widespread implementation. > I think we're both now agreeing that the /goal/ should be > byte-balance for ConEx auditing. Correct? Hopefully it's no surpprise to anyone that _I_ don't agree. > I am also in full agreement that this goal isn't always easy to meet > if retrofitting ConEx onto an existing transport like TCP. It works > if the packet sizes are regular, but if they are lumpy, the sender is > likely to understate or overstate. I can agree with that. (It seems to me that that's a potential barrier to implementation.) > And I agree that these aren't necessarily just corner-cases (well, I > guess there is a large set of cases with regular packet sizes, but > the corner is also quite large). Again, I agree. > You ask what I think we should do about this. My view, we should: > a) state what the goal should be for all transports (byte-balance) > b) give advice on how to implement a TCP sender to do as well as it can > c) run experiments and see whether the outcome is good enough, or if > further protocol mechanism is needed. a) I see no benefit in _merely_ stating a goal: if indeed the goal is worthwhile (of which I remain unconvinced), we need to justify the additional effort which may be required to meet it. b) I see danger (not benefit) from asking implementors to do much in the way of modifications to TCP. I believe our goal is unattainable unless we can demonstrate benefit for flows where no TCP modifications are needed. (Our charter clearly allows for modification to the _receiver_ TCP implementations; but we should promote that, if at all, as an _additional_ benefit of ConEx with receiver modifications.) c) I have _no_ problem with running experiments with sender modifications to see if there _is_ a benefit from byte-balance. My problem is with jawboning about the abstruse benefits of byte-balance in our _initial_ documents. > Concerning (b) advice on the best that TCP implementations can do: > - the TCP receiver (if optionally supporting ConEx) should suppress > ACK delay whenever it detects congestion and instead give immediate > feedback > - TCP sender can use ack sequence numbers to improve its guess of the > required size of an re-echo-loss or re-echo-ECN > - If the receiver is not ConEx-aware, a sender that knows it is > sending lumpy packet sizes can introduce additional credit to cover > any mistakes. - I support anything to encourage a faster feedback loop for reacting to congestion signals. I only suggest that asking for any particular changes to TCP _at_this_point_ may be counterproductive. - I believe that what a modified TCP sender might do in reaction to congestion should follow from widespread experimental experience. - I have a problem with asking a sender to _guess_ at what ConEx signal is needed in response to a congestion event. > If a ConEx sender does unintentionally understate bytes of > congestion, the auditor will discard some packets, then the sender > will redress the balance with some more re-echo-loss and it should > all heal itself, albeit having suffered some losses in the process. IMHO, we're not ready to prescribe any particular _policing_ actions. "Auditor" to me means a point of collection of information, not a point of enforcement. Enforcement, to me, is premature in our primary documents now being LastCalled. No doubt Bob feels confident he can prescribe enforcement actions which are mathematically correct. Perhaps he can. But to me, describing _any_ policing at this time is dangerous. Folks _will_ implement policing according to their _own_ interpretation of the information available -- not necessarily the way we describe. :^( > Do you think this is sufficient (at least to run experiments to test > whether it is)? I think we would do well to run experiments an that basis. (I do not think we should publish initial documents claiming the "rightness" of what such experiments seek to confirm.) -- John Leslie From bob.briscoe@bt.com Sun Nov 20 15:27:28 2011 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 6B73121F888A for ; Sun, 20 Nov 2011 15:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.059 X-Spam-Level: X-Spam-Status: No, score=-3.059 tagged_above=-999 required=5 tests=[AWL=0.540, 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 iFXXOkc8jomX for ; Sun, 20 Nov 2011 15:27:27 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE8A21F877F for ; Sun, 20 Nov 2011 15:27:26 -0800 (PST) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 20 Nov 2011 23:27:24 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 20 Nov 2011 23:27:24 +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 1321831643332; Sun, 20 Nov 2011 23:27:23 +0000 Received: from MUT.jungle.bt.co.uk ([10.142.208.72]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id pAKNRJPT008060; Sun, 20 Nov 2011 23:27:20 GMT Message-Id: <201111202327.pAKNRJPT008060@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 20 Nov 2011 23:26:11 +0000 To: John Leslie From: Bob Briscoe In-Reply-To: <20111120214012.GE22465@verdi> References: <201111171402.pAHE26tB006646@bagheera.jungle.bt.co.uk> <201111201956.pAKJuJSQ007421@bagheera.jungle.bt.co.uk> <20111120214012.GE22465@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 20 Nov 2011 23:27:24.0128 (UTC) FILETIME=[F5415E00:01CCA7DB] Cc: ConEx IETF list Subject: Re: [conex] byte vs packet 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: Sun, 20 Nov 2011 23:27:28 -0000 John, Terminology for this email [abstract-mech]: i) Policing /based on/ ConEx information and ii) Audit /of/ ConEx information are distinct functions. I fully agree that policing will be done how operators want to do it, and we have no need to standardise anything about it. But audit is about checking one stream of signals against another. It is a factual function, not a policy-related function. Without audit, ConEx information is unreliable for policing, monitoring or anything. I will now show that, if we don't define what fact the audit function is meant to be checking, ConEx cannot work. Imagine an Internet where it is undefined whether ConEx and congestion signals should balance per packet or per byte. Then both types of audit and both types of transport will be implemented. Let's assume some byte-based audit devices will discard traffic that understates ConEx bytes. And some packet-based audit devices will discard understatement in packets. Then these packet-balanced auditors will drop byte-balanced transports. And vice-versa. ConEx audit will become a machine for dropping large proportions of packets. Please explain how you propose to prevent this disaster if we leave the byte-packet question open. I am all for allowing flexibility in standards wherever possible, in order to encourage diversity and innovation. There can certainly be all sorts of implementations of the audit function, but we have to minimally define whether audit is per byte or per packet - for interoperability. Can we find some way of resolving this argument, rather than keep revisiting it? Bob At 21:40 20/11/2011, John Leslie wrote: >Bob Briscoe wrote: > > > > Matt, > > (I do understand that Bob is addressing Matt...) > > > [Adding the ConEx list back in] > > I do not agree that this is a discussion which should gate on the >opinions of Bob and Matt. > > I do understand that both of these folks think they understand the >mathematical issues involved better than the rest of us. They may well >be right. > > But this is an IETF Working Group, not an academic paper review >board. I'm not interested in arguing mathematics -- I believe we need >to discuss how to get a protocol which enough operators will implement. >And I'm interested in arguments of what will harm our chances of >widespread implementation. > > > I think we're both now agreeing that the /goal/ should be > > byte-balance for ConEx auditing. Correct? > > Hopefully it's no surpprise to anyone that _I_ don't agree. > > > I am also in full agreement that this goal isn't always easy to meet > > if retrofitting ConEx onto an existing transport like TCP. It works > > if the packet sizes are regular, but if they are lumpy, the sender is > > likely to understate or overstate. > > I can agree with that. (It seems to me that that's a potential >barrier to implementation.) > > > And I agree that these aren't necessarily just corner-cases (well, I > > guess there is a large set of cases with regular packet sizes, but > > the corner is also quite large). > > Again, I agree. > > > You ask what I think we should do about this. My view, we should: > > a) state what the goal should be for all transports (byte-balance) > > b) give advice on how to implement a TCP sender to do as well as it can > > c) run experiments and see whether the outcome is good enough, or if > > further protocol mechanism is needed. > >a) I see no benefit in _merely_ stating a goal: if indeed the goal is > worthwhile (of which I remain unconvinced), we need to justify the > additional effort which may be required to meet it. > >b) I see danger (not benefit) from asking implementors to do much in > the way of modifications to TCP. I believe our goal is unattainable > unless we can demonstrate benefit for flows where no TCP modifications > are needed. (Our charter clearly allows for modification to the > _receiver_ TCP implementations; but we should promote that, if at > all, as an _additional_ benefit of ConEx with receiver modifications.) > >c) I have _no_ problem with running experiments with sender modifications > to see if there _is_ a benefit from byte-balance. My problem is with > jawboning about the abstruse benefits of byte-balance in our _initial_ > documents. > > > Concerning (b) advice on the best that TCP implementations can do: > > - the TCP receiver (if optionally supporting ConEx) should suppress > > ACK delay whenever it detects congestion and instead give immediate > > feedback > > - TCP sender can use ack sequence numbers to improve its guess of the > > required size of an re-echo-loss or re-echo-ECN > > - If the receiver is not ConEx-aware, a sender that knows it is > > sending lumpy packet sizes can introduce additional credit to cover > > any mistakes. > >- I support anything to encourage a faster feedback loop for reacting > to congestion signals. I only suggest that asking for any particular > changes to TCP _at_this_point_ may be counterproductive. > >- I believe that what a modified TCP sender might do in reaction to > congestion should follow from widespread experimental experience. > >- I have a problem with asking a sender to _guess_ at what ConEx signal > is needed in response to a congestion event. > > > If a ConEx sender does unintentionally understate bytes of > > congestion, the auditor will discard some packets, then the sender > > will redress the balance with some more re-echo-loss and it should > > all heal itself, albeit having suffered some losses in the process. > > IMHO, we're not ready to prescribe any particular _policing_ actions. >"Auditor" to me means a point of collection of information, not a point >of enforcement. > > Enforcement, to me, is premature in our primary documents now being >LastCalled. No doubt Bob feels confident he can prescribe enforcement >actions which are mathematically correct. Perhaps he can. > > But to me, describing _any_ policing at this time is dangerous. >Folks _will_ implement policing according to their _own_ interpretation >of the information available -- not necessarily the way we describe. :^( > > > Do you think this is sufficient (at least to run experiments to test > > whether it is)? > > I think we would do well to run experiments an that basis. > > (I do not think we should publish initial documents claiming the >"rightness" of what such experiments seek to confirm.) > >-- >John Leslie ________________________________________________________________ Bob Briscoe, BT Innovate & Design From fred@cisco.com Sun Nov 20 15:41:16 2011 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 A348A21F877F for ; Sun, 20 Nov 2011 15:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.44 X-Spam-Level: X-Spam-Status: No, score=-109.44 tagged_above=-999 required=5 tests=[AWL=1.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 Jny7jbdzExYJ for ; Sun, 20 Nov 2011 15:41:15 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 640AF21F8753 for ; Sun, 20 Nov 2011 15:41:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=18624; q=dns/txt; s=iport; t=1321832474; x=1323042074; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=Uo0cOmmC+849LxN+sNrwOERkF3eqG5O+DHD3cKZ/BaM=; b=gUO1alLNThC2QJgxMM63B/2vIltNave1NOTnF5Pk3AA9aSeH+DsEcfac opGXOFDBboIqC+coTDjIl+2nT70TUtBosO5BeW/l9V/W2Jkguz0m3dxz8 PrGDmqG0QjMBZzq0LmX8UOwvlSKAmRkUGU0ZOWJEmJV7T5PyhsPhQC8bo s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAFqPyU5Io8UQ/2dsb2JhbABDqj+BBYFyAQEBAwEBAQELBAFSCQIJBQsLGC4nMAYTIodhCJUpAZ0nBIk0YwSIGIwkhT2MVQ X-IronPort-AV: E=Sophos;i="4.69,544,1315180800"; d="scan'208,217";a="60088954" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 20 Nov 2011 23:41:12 +0000 Received: from [10.88.5.185] (sin-vpn-client-20-220.cisco.com [10.68.20.220]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAKNfBGU019112; Sun, 20 Nov 2011 23:41:11 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-129--72112536 From: Fred Baker In-Reply-To: <201111201956.pAKJuJSQ007421@bagheera.jungle.bt.co.uk> Date: Mon, 21 Nov 2011 07:41:10 +0800 Message-Id: References: <201111171402.pAHE26tB006646@bagheera.jungle.bt.co.uk> <201111201956.pAKJuJSQ007421@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1084) Cc: ConEx IETF list Subject: Re: [conex] byte vs packet 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: Sun, 20 Nov 2011 23:41:16 -0000 --Apple-Mail-129--72112536 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii on the matter of bytes and packets, as I tried (apparently = unsuccessfully) to say in the other email, what I am worried about first = is time, which both bytes and packets are a readily-measured analog to. = When I probed to see what interface someone knew about that sent = messages as messages rather than a string of bits, I was told that WiFi = measurably operates with an upper bound packet rate and is the poster = child for packet-based interfaces. Great, but there is no single device = that can perceive or measure it that way - wonderful academic = observation, but I have no idea how to use it in an implementation. The = point on a WiFi interface is neither that I have too many bytes or = packets queued up; the point is that one of those is true in the context = of a congested shared medium, and we *also* have to get control of the = medium. I find myself interested in bytes-as-an-analog-for-time on a non-shared = interface and time on a shared interface, in both cases because I can = measure them in an implementation. On Nov 21, 2011, at 3:56 AM, Bob Briscoe wrote: > Matt, >=20 > [Adding the ConEx list back in] >=20 > I think we're both now agreeing that the /goal/ should be byte-balance = for ConEx auditing. Correct? >=20 > I am also in full agreement that this goal isn't always easy to meet = if retrofitting ConEx onto an existing transport like TCP. It works if = the packet sizes are regular, but if they are lumpy, the sender is = likely to understate or overstate. And I agree that these aren't = necessarily just corner-cases (well, I guess there is a large set of = cases with regular packet sizes, but the corner is also quite large). >=20 > You ask what I think we should do about this. My view, we should: > a) state what the goal should be for all transports (byte-balance) > b) give advice on how to implement a TCP sender to do as well as it = can > c) run experiments and see whether the outcome is good enough, or if = further protocol mechanism is needed. >=20 > Concerning (b) advice on the best that TCP implementations can do: > - the TCP receiver (if optionally supporting ConEx) should suppress = ACK delay whenever it detects congestion and instead give immediate = feedback=20 > - TCP sender can use ack sequence numbers to improve its guess of the = required size of an re-echo-loss or re-echo-ECN > - If the receiver is not ConEx-aware, a sender that knows it is = sending lumpy packet sizes can introduce additional credit to cover any = mistakes. >=20 > If a ConEx sender does unintentionally understate bytes of congestion, = the auditor will discard some packets, then the sender will redress the = balance with some more re-echo-loss and it should all heal itself, = albeit having suffered some losses in the process. >=20 > Do you think this is sufficient (at least to run experiments to test = whether it is)? >=20 >=20 >=20 > Bob >=20 > At 20:55 18/11/2011, Matt Mathis wrote: >> So here is a pathology: I have an application that sends 15001 bytes = (10 segments + 1 byte), followed by 1 byte beacons every 10 second for = 100 seconds and then the entire pattern repeats (total of 10*1500 + 10*1 = segments every 100 seconds). =20 >>=20 >> Now suppose there are ECN marks near the end of the burst on every = repeat. How does this get signaled, and what is the correct sender = response? Due to delayed ACKs it may be ambiguous exactly which = segment was marked (e.g. was it 1500 or 1 bytes?) Even if the sender = knows for sure that it was the 1500 byte segment that was marked, it has = to wait until the next burst to send the proper feedback. >>=20 >> The problem is the ACKs carry the count of the number of marked = segments, not marked bytes. Also the re-feed itself has no size, except = the length of the segments carrying it. >>=20 >> What do you think should happen in this case? >> (BTW modern persistent web protocols, such as SPDY do stuff like this = all the time, although perhaps not as extreme as my example. BGP also = has streaming data with very irregular message sizes.) >>=20 >> This would be completely clear if the ACKs and re-feedback were = counts of bytes. >>=20 >> Thanks, >> --MM-- >> The best way to predict the future is to create it. - Alan Kay >>=20 >>=20 >>=20 >> On Thu, Nov 17, 2011 at 7:07 PM, Matt Mathis = wrote: >>=20 >> I'm sorry I did not make my self clear. I understand and agree with = your argument. >>=20 >> The problem is when the forward path is carrying lumpy data : highly = irregular segment sizes, typical of streaming media, p-http, or bgp at = edge of the onset of congestion. When there is an ecn mark the ack only = indicates that a segment was marked and not its size. If the sender has = a choice of segments to re-feedback it has has no idea which to choose. = Worse it >> may not have a choice. Furthermore under pathological conditions it = will persistently get it wrong. =20 >>=20 >> I can explain better when I have a real. Keyboard.=20 >> On Nov 17, 2011 10:02 PM, "Bob Briscoe" wrote: >> Matt, >>=20 >> This issue has come up in at least two threads recently: "Congestion" = vs. "Congestion Volume" and "byte-counting in conex-destopt" >>=20 >> Consider the buffer into the high speed line you were talking about = this morning - it holds packets in equal MTU-sized packet buffers, = whatever the packet size. >>=20 >> When it buffers packets, we need to ask what exactly is congested: = the line or the buffer? In this case, the line is congested. Packets are = temporarily in the buffer because more bits arrived than departed. The = queue is merely a symptom of how congested the line is. Certainly, once = the buffer gets full, we could say the buffer has become congested too. = But the root of the problem is how fast the line can carry away the = bits. >>=20 >> If the queue was building up behind forwarding look-ups or a = firewall, then the problem would be the number of packets headers, not = bits. But if it's a queue into a transmission line, the problem is bits. >>=20 >> The point is, whether to count bits or packets depends on the process = /in front/ of the queue (whether its a bit transmission line or = processing packet headers). The internals of the buffer itself are = irrelevant. >>=20 >> Then the question is how prevalent are per-packet processes as = sources of congestion? Answer: There seems to be good reason why = per-packet congestion will remain in the minority relative to = per-byte... >>=20 >> During the process of writing draft-ietf-byte-pkt-congest, all the = machine design folk who were consulted said that machines are generally = designed so that any per-packet-processing can cope with a workload at = line rate consisting mostly of small packets. >>=20 >> IOW, machine designs tend to use bit-congestion to protect the = packet-processor from congestion. >>=20 >> ____________________ >> For those who prefer an example, assume: >> MTU, M =3D 1,500B =3D 12,000b >> Line rate, X =3D 48Gbps >>=20 >> [The numbers are chosen to make the maths easy, not to reflect = typical scenarios. I'm going to work in bits not bytes from now on.] >>=20 >> Imagine at some time that 260 of these fixed-size packet buffers are = full, with 10 large and 250 small packets. >>=20 >> packet size | S | 12,000b | 480b | >> no. pkts buffered | N | 10 | 250 | >> buffer space used | NM | 120kb | 3Mb | >> pkt bits buffered | NS | 120kb | 120kb | >> time to drain all | NS/X | 2,500ns | 2,500ns | >>=20 >> Although each small packet takes up the same space in the buffer as a = large packet, it's faster to get rid of it. 250 small packets take as = long to drain as 10 large packets. >>=20 >>=20 >> Bob >>=20 >>=20 >> ________________________________________________________________ >> Bob Briscoe, BT Innovate & Design=20 >>=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design >=20 > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex --Apple-Mail-129--72112536 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Matt,

[Adding the ConEx list back in]

I think we're both now agreeing that the /goal/ should be byte-balance for ConEx auditing. Correct?

I am also in full agreement that this goal isn't always easy to meet if retrofitting ConEx onto an existing transport like TCP. It works if the packet sizes are regular, but if they are lumpy, the sender is likely to understate or overstate. And I agree that these aren't necessarily just corner-cases (well, I guess there is a large set of cases with regular packet sizes, but the corner is also quite large).

You ask what I think we should do about this. My view, we should:
a) state what the goal should be for all transports (byte-balance)
b) give advice on how to implement a TCP sender to do as well as it can
c) run experiments and see whether the outcome is good enough, or if further protocol mechanism is needed.

Concerning (b) advice on the best that TCP implementations can do:
- the TCP receiver (if optionally supporting ConEx) should suppress ACK delay whenever it detects congestion and instead give immediate feedback
- TCP sender can use ack sequence numbers to improve its guess of the required size of an re-echo-loss or re-echo-ECN
- If the receiver is not ConEx-aware, a sender that knows it is sending lumpy packet sizes can introduce additional credit to cover any mistakes.

If a ConEx sender does unintentionally understate bytes of congestion, the auditor will discard some packets, then the sender will redress the balance with some more re-echo-loss and it should all heal itself, = albeit having suffered some losses in the process.

Do you think this is sufficient (at least to run experiments to test whether it is)?



Bob

At 20:55 18/11/2011, Matt Mathis wrote:
So here = is a pathology: I have an application that sends 15001 bytes (10 segments + 1 byte), followed = by 1 byte beacons every 10 second for 100 seconds and then the entire pattern repeats (total of 10*1500 + 10*1 segments every 100 seconds). 

Now suppose there are ECN marks near the end of the burst on every repeat.   How does this get signaled, and what is the correct sender response?   Due to delayed ACKs it may be ambiguous exactly which segment was marked (e.g. was it 1500 or 1 bytes?)   Even if the sender knows for sure that it was the 1500 byte segment that was marked, it has to wait until the next burst = to send the proper feedback.

The problem is the ACKs carry the count of the number of marked = segments, not marked bytes.  Also the re-feed itself has no size, except the length of the segments carrying it.

What do you think should happen in this case?
(BTW modern persistent web protocols, such as SPDY do stuff like this = all the time, although perhaps not as extreme as my example.   BGP also has streaming data with very irregular message sizes.)

This would be completely clear if the ACKs and re-feedback were counts = of bytes.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay



On Thu, Nov 17, 2011 at 7:07 PM, Matt Mathis <mattmathis@google.com>= wrote:

I'm sorry I did not make my self clear. I understand and agree with your argument.

The problem is when the forward path is carrying lumpy data : = highly irregular segment sizes, typical of streaming media, p-http, or bgp at edge of the onset of congestion. When there is an ecn mark the ack  only indicates that a segment was marked and not its size. If the sender has a choice of segments to re-feedback it has has no idea which to choose.  Worse it
may not have a choice.   Furthermore under = pathological conditions it will persistently get it wrong. 

I can explain better when I have a real. Keyboard.
On Nov 17, 2011 10:02 PM, "Bob Briscoe" <bob.briscoe@bt.com> wrote:
Matt,

This issue has come up in at least two threads recently: "Congestion" vs. "Congestion Volume" and "byte-counting in conex-destopt"

Consider the buffer into the high speed line you were talking = about this morning - it holds packets in equal MTU-sized packet buffers, whatever the packet size.

When it buffers packets, we need to ask what exactly is = congested: the line or the buffer? In this case, the line is congested. Packets are temporarily in the buffer because more bits arrived than departed. The queue is merely a symptom of how congested the line is. Certainly, once the buffer gets full, we could say the buffer has become congested too. But the root of the problem is how fast the line can carry away the bits.

If the queue was building up behind forwarding look-ups or a firewall, then the problem would be the number of packets headers, not bits. But if it's a queue into a transmission line, the problem is bits.

The point is, whether to count bits or packets depends on the = process /in front/ of the queue (whether its a bit transmission line or processing packet headers). The internals of the buffer itself are irrelevant.

Then the question is how prevalent are per-packet processes as sources of congestion? Answer: There seems to be good reason why per-packet congestion will remain in the minority relative to per-byte...

During the process of writing draft-ietf-byte-pkt-congest, all = the machine design folk who were consulted said that machines are generally designed so that any per-packet-processing can cope with a workload at line rate consisting mostly of small packets.

IOW, machine designs tend to use bit-congestion to protect the packet-processor from congestion.

____________________
For those who prefer an example, assume:
MTU,       M =3D 1,500B =3D = 12,000b
Line rate, X =3D    48Gbps

[The numbers are chosen to make the maths easy, not to reflect typical scenarios. I'm going to work in bits not bytes from now on.]

Imagine at some time that 260 of these fixed-size packet = buffers are full, with 10 large and 250 small packets.

packet size       | = S    | 12,000b  |   480b   |
no. pkts buffered | N    = |     10   |   250    |
buffer space used | NM   |    120kb |     3Mb  |
pkt bits buffered | NS   |    120kb |   120kb  |
time to drain all | NS/X |  2,500ns | 2,500ns  = |

Although each small packet takes up the same space in the = buffer as a large packet, it's faster to get rid of it. 250 small packets take as long to drain as 10 large packets.


Bob


=
________________________________________________________________<= br>
Bob = Briscoe,           =             &n= bsp;        BT Innovate & Design

________________________________________________________________
Bob = Briscoe,           =             &n= bsp;        BT Innovate & Design

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

= --Apple-Mail-129--72112536-- From bob.briscoe@bt.com Mon Nov 21 01:22:23 2011 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 E8C2521F8B48 for ; Mon, 21 Nov 2011 01:22:23 -0800 (PST) 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.490, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 IksZqO2kX-wp for ; Mon, 21 Nov 2011 01:22:22 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by ietfa.amsl.com (Postfix) with ESMTP id CE19421F8B44 for ; Mon, 21 Nov 2011 01:22:21 -0800 (PST) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Nov 2011 09:22:20 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Nov 2011 09:22:20 +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 1321867339513; Mon, 21 Nov 2011 09:22:19 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.144.50]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id pAL9MFC6010070; Mon, 21 Nov 2011 09:22:15 GMT Message-Id: <201111210922.pAL9MFC6010070@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 21 Nov 2011 09:22:12 +0000 To: Fred Baker From: Bob Briscoe In-Reply-To: References: <201111171402.pAHE26tB006646@bagheera.jungle.bt.co.uk> <201111201956.pAKJuJSQ007421@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_681109994==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 21 Nov 2011 09:22:20.0226 (UTC) FILETIME=[11C9AA20:01CCA82F] Cc: ConEx IETF list Subject: Re: [conex] byte vs packet 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: Mon, 21 Nov 2011 09:22:24 -0000 --=====================_681109994==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Fred, Thanks for this. Yes time is a useful metric to think of. When you say the upper bound to the WiFi sending rate is in pkt /sec, is this the upper bound of one interface, or of the shared medium (spectrum)? When we implemented a measure of WiFi congestion (in the RTS/CTS style of 802.11), we used the rate of not getting back a CTS as an indication of congestion of the shared spectrum. The underlying congestion of the spectrum that led to it not being clear-to-send came from bits per second. But the interface controls this on a per-packet basis. Is this what you mean? In infrastructure mode, the uplink is congested by interference at the receiving antenna, which depends on the intensity of bits in the air. The downlink gets congested when the antenna hits its power limit, and power depends on bits sent. So in both cases, the shared medium gets congested by bits. But the particular protocol used can consume the shared medium somewhat with signalling which creates a slight per-packet base load. Bob At 23:41 20/11/2011, Fred Baker wrote: >on the matter of bytes and packets, as I tried (apparently >unsuccessfully) to say in the other email, what I am worried about >first is time, which both bytes and packets are a readily-measured >analog to. When I probed to see what interface someone knew about >that sent messages as messages rather than a string of bits, I was >told that WiFi measurably operates with an upper bound packet rate >and is the poster child for packet-based interfaces. Great, but >there is no single device that can perceive or measure it that way - >wonderful academic observation, but I have no idea how to use it in >an implementation. The point on a WiFi interface is neither that I >have too many bytes or packets queued up; the point is that one of >those is true in the context of a congested shared medium, and we >*also* have to get control of the medium. > >I find myself interested in bytes-as-an-analog-for-time on a >non-shared interface and time on a shared interface, in both cases >because I can measure them in an implementation. > >On Nov 21, 2011, at 3:56 AM, Bob Briscoe wrote: > >>Matt, >> >>[Adding the ConEx list back in] >> >>I think we're both now agreeing that the /goal/ should be >>byte-balance for ConEx auditing. Correct? >> >>I am also in full agreement that this goal isn't always easy to >>meet if retrofitting ConEx onto an existing transport like TCP. It >>works if the packet sizes are regular, but if they are lumpy, the >>sender is likely to understate or overstate. And I agree that these >>aren't necessarily just corner-cases (well, I guess there is a >>large set of cases with regular packet sizes, but the corner is >>also quite large). >> >>You ask what I think we should do about this. My view, we should: >>a) state what the goal should be for all transports (byte-balance) >>b) give advice on how to implement a TCP sender to do as well as it can >>c) run experiments and see whether the outcome is good enough, or >>if further protocol mechanism is needed. >> >>Concerning (b) advice on the best that TCP implementations can do: >>- the TCP receiver (if optionally supporting ConEx) should suppress >>ACK delay whenever it detects congestion and instead give immediate feedback >>- TCP sender can use ack sequence numbers to improve its guess of >>the required size of an re-echo-loss or re-echo-ECN >>- If the receiver is not ConEx-aware, a sender that knows it is >>sending lumpy packet sizes can introduce additional credit to cover >>any mistakes. >> >>If a ConEx sender does unintentionally understate bytes of >>congestion, the auditor will discard some packets, then the sender >>will redress the balance with some more re-echo-loss and it should >>all heal itself, albeit having suffered some losses in the process. >> >>Do you think this is sufficient (at least to run experiments to >>test whether it is)? >> >> >> >>Bob >> >>At 20:55 18/11/2011, Matt Mathis wrote: >>>So here is a pathology: I have an application that sends 15001 >>>bytes (10 segments + 1 byte), followed by 1 byte beacons every 10 >>>second for 100 seconds and then the entire pattern repeats (total >>>of 10*1500 + 10*1 segments every 100 seconds). >>> >>>Now suppose there are ECN marks near the end of the burst on every >>>repeat. How does this get signaled, and what is the correct >>>sender response? Due to delayed ACKs it may be ambiguous exactly >>>which segment was marked (e.g. was it 1500 or 1 bytes?) Even if >>>the sender knows for sure that it was the 1500 byte segment that >>>was marked, it has to wait until the next burst to send the proper feedback. >>> >>>The problem is the ACKs carry the count of the number of marked >>>segments, not marked bytes. Also the re-feed itself has no size, >>>except the length of the segments carrying it. >>> >>>What do you think should happen in this case? >>>(BTW modern persistent web protocols, such as SPDY do stuff like >>>this all the time, although perhaps not as extreme as my >>>example. BGP also has streaming data with very irregular message sizes.) >>> >>>This would be completely clear if the ACKs and re-feedback were >>>counts of bytes. >>> >>>Thanks, >>>--MM-- >>>The best way to predict the future is to create it. - Alan Kay >>> >>> >>> >>>On Thu, Nov 17, 2011 at 7:07 PM, Matt Mathis >>><mattmathis@google.com> wrote: >>>I'm sorry I did not make my self clear. I understand and agree >>>with your argument. >>>The problem is when the forward path is carrying lumpy data : >>>highly irregular segment sizes, typical of streaming media, >>>p-http, or bgp at edge of the onset of congestion. When there is >>>an ecn mark the ack only indicates that a segment was marked and >>>not its size. If the sender has a choice of segments to >>>re-feedback it has has no idea which to choose. Worse it >>>may not have a choice. Furthermore under pathological conditions >>>it will persistently get it wrong. >>>I can explain better when I have a real. Keyboard. >>>On Nov 17, 2011 10:02 PM, "Bob Briscoe" >>><bob.briscoe@bt.com> wrote: >>>Matt, >>>This issue has come up in at least two threads recently: >>>"Congestion" vs. "Congestion Volume" and "byte-counting in conex-destopt" >>>Consider the buffer into the high speed line you were talking >>>about this morning - it holds packets in equal MTU-sized packet >>>buffers, whatever the packet size. >>>When it buffers packets, we need to ask what exactly is congested: >>>the line or the buffer? In this case, the line is congested. >>>Packets are temporarily in the buffer because more bits arrived >>>than departed. The queue is merely a symptom of how congested the >>>line is. Certainly, once the buffer gets full, we could say the >>>buffer has become congested too. But the root of the problem is >>>how fast the line can carry away the bits. >>>If the queue was building up behind forwarding look-ups or a >>>firewall, then the problem would be the number of packets headers, >>>not bits. But if it's a queue into a transmission line, the problem is bits. >>>The point is, whether to count bits or packets depends on the >>>process /in front/ of the queue (whether its a bit transmission >>>line or processing packet headers). The internals of the buffer >>>itself are irrelevant. >>>Then the question is how prevalent are per-packet processes as >>>sources of congestion? Answer: There seems to be good reason why >>>per-packet congestion will remain in the minority relative to per-byte... >>> >>>During the process of writing draft-ietf-byte-pkt-congest, all the >>>machine design folk who were consulted said that machines are >>>generally designed so that any per-packet-processing can cope with >>>a workload at line rate consisting mostly of small packets. >>>IOW, machine designs tend to use bit-congestion to protect the >>>packet-processor from congestion. >>>____________________ >>>For those who prefer an example, assume: >>>MTU, M = 1,500B = 12,000b >>>Line rate, X = 48Gbps >>>[The numbers are chosen to make the maths easy, not to reflect >>>typical scenarios. I'm going to work in bits not bytes from now on.] >>>Imagine at some time that 260 of these fixed-size packet buffers >>>are full, with 10 large and 250 small packets. >>>packet size | S | 12,000b | 480b | >>>no. pkts buffered | N | 10 | 250 | >>>buffer space used | NM | 120kb | 3Mb | >>>pkt bits buffered | NS | 120kb | 120kb | >>>time to drain all | NS/X | 2,500ns | 2,500ns | >>>Although each small packet takes up the same space in the buffer >>>as a large packet, it's faster to get rid of it. 250 small packets >>>take as long to drain as 10 large packets. >>> >>>Bob >>> >>>________________________________________________________________ >>>Bob Briscoe, BT Innovate & Design >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design >>_______________________________________________ >>conex mailing list >>conex@ietf.org >>https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design --=====================_681109994==.ALT Content-Type: text/html; charset="us-ascii" Fred,

Thanks for this. Yes time is a useful metric to think of.

When you say the upper bound to the WiFi sending rate is in pkt /sec, is this the upper bound of one interface, or of the shared medium (spectrum)?

When we implemented a measure of WiFi congestion (in the RTS/CTS style of 802.11), we used the rate of not getting back a CTS as an indication of congestion of the shared spectrum. The underlying congestion of the spectrum that led to it not being clear-to-send came from bits per second. But the interface controls this on a per-packet basis. Is this what you mean?

In infrastructure mode, the uplink is congested by interference at the receiving antenna, which depends on the intensity of bits in the air. The downlink gets congested when the antenna hits its power limit, and power depends on bits sent. So in both cases, the shared medium gets congested by bits. But the particular protocol used can consume the shared medium somewhat with signalling which creates a slight per-packet base load.


Bob


At 23:41 20/11/2011, Fred Baker wrote:

on the matter of bytes and packets, as I tried (apparently unsuccessfully) to say in the other email, what I am worried about first is time, which both bytes and packets are a readily-measured analog to. When I probed to see what interface someone knew about that sent messages as messages rather than a string of bits, I was told that WiFi measurably operates with an upper bound packet rate and is the poster child for packet-based interfaces. Great, but there is no single device that can perceive or measure it that way - wonderful academic observation, but I have no idea how to use it in an implementation. The point on a WiFi interface is neither that I have too many bytes or packets queued up; the point is that one of those is true in the context of a congested shared medium, and we *also* have to get control of the medium.

I find myself interested in bytes-as-an-analog-for-time on a non-shared interface and time on a shared interface, in both cases because I can measure them in an implementation.

On Nov 21, 2011, at 3:56 AM, Bob Briscoe wrote:

Matt,

[Adding the ConEx list back in]

I think we're both now agreeing that the /goal/ should be byte-balance for ConEx auditing. Correct?

I am also in full agreement that this goal isn't always easy to meet if retrofitting ConEx onto an existing transport like TCP. It works if the packet sizes are regular, but if they are lumpy, the sender is likely to understate or overstate. And I agree that these aren't necessarily just corner-cases (well, I guess there is a large set of cases with regular packet sizes, but the corner is also quite large).

You ask what I think we should do about this. My view, we should:
a) state what the goal should be for all transports (byte-balance)
b) give advice on how to implement a TCP sender to do as well as it can
c) run experiments and see whether the outcome is good enough, or if further protocol mechanism is needed.

Concerning (b) advice on the best that TCP implementations can do:
- the TCP receiver (if optionally supporting ConEx) should suppress ACK delay whenever it detects congestion and instead give immediate feedback
- TCP sender can use ack sequence numbers to improve its guess of the required size of an re-echo-loss or re-echo-ECN
- If the receiver is not ConEx-aware, a sender that knows it is sending lumpy packet sizes can introduce additional credit to cover any mistakes.

If a ConEx sender does unintentionally understate bytes of congestion, the auditor will discard some packets, then the sender will redress the balance with some more re-echo-loss and it should all heal itself, albeit having suffered some losses in the process.

Do you think this is sufficient (at least to run experiments to test whether it is)?



Bob

At 20:55 18/11/2011, Matt Mathis wrote:
So here is a pathology: I have an application that sends 15001 bytes (10 segments + 1 byte), followed by 1 byte beacons every 10 second for 100 seconds and then the entire pattern repeats (total of 10*1500 + 10*1 segments every 100 seconds). 

Now suppose there are ECN marks near the end of the burst on every repeat.   How does this get signaled, and what is the correct sender response?   Due to delayed ACKs it may be ambiguous exactly which segment was marked (e.g. was it 1500 or 1 bytes?)   Even if the sender knows for sure that it was the 1500 byte segment that was marked, it has to wait until the next burst to send the proper feedback.

The problem is the ACKs carry the count of the number of marked segments, not marked bytes.  Also the re-feed itself has no size, except the length of the segments carrying it.

What do you think should happen in this case?
(BTW modern persistent web protocols, such as SPDY do stuff like this all the time, although perhaps not as extreme as my example.   BGP also has streaming data with very irregular message sizes.)

This would be completely clear if the ACKs and re-feedback were counts of bytes.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay



On Thu, Nov 17, 2011 at 7:07 PM, Matt Mathis <mattmathis@google.com> wrote:
I'm sorry I did not make my self clear. I understand and agree with your argument.
The problem is when the forward path is carrying lumpy data : highly irregular segment sizes, typical of streaming media, p-http, or bgp at edge of the onset of congestion. When there is an ecn mark the ack  only indicates that a segment was marked and not its size. If the sender has a choice of segments to re-feedback it has has no idea which to choose.  Worse it
may not have a choice.   Furthermore under pathological conditions it will persistently get it wrong. 
I can explain better when I have a real. Keyboard.
On Nov 17, 2011 10:02 PM, "Bob Briscoe" <bob.briscoe@bt.com> wrote:
Matt,
This issue has come up in at least two threads recently: "Congestion" vs. "Congestion Volume" and "byte-counting in conex-destopt"
Consider the buffer into the high speed line you were talking about this morning - it holds packets in equal MTU-sized packet buffers, whatever the packet size.
When it buffers packets, we need to ask what exactly is congested: the line or the buffer? In this case, the line is congested. Packets are temporarily in the buffer because more bits arrived than departed. The queue is merely a symptom of how congested the line is. Certainly, once the buffer gets full, we could say the buffer has become congested too. But the root of the problem is how fast the line can carry away the bits.
If the queue was building up behind forwarding look-ups or a firewall, then the problem would be the number of packets headers, not bits. But if it's a queue into a transmission line, the problem is bits.
The point is, whether to count bits or packets depends on the process /in front/ of the queue (whether its a bit transmission line or processing packet headers). The internals of the buffer itself are irrelevant.
Then the question is how prevalent are per-packet processes as sources of congestion? Answer: There seems to be good reason why per-packet congestion will remain in the minority relative to per-byte...

During the process of writing draft-ietf-byte-pkt-congest, all the machine design folk who were consulted said that machines are generally designed so that any per-packet-processing can cope with a workload at line rate consisting mostly of small packets.
IOW, machine designs tend to use bit-congestion to protect the packet-processor from congestion.
____________________
For those who prefer an example, assume:
MTU,       M = 1,500B = 12,000b
Line rate, X =    48Gbps
[The numbers are chosen to make the maths easy, not to reflect typical scenarios. I'm going to work in bits not bytes from now on.]
Imagine at some time that 260 of these fixed-size packet buffers are full, with 10 large and 250 small packets.
packet size       | S    | 12,000b  |   480b   |
no. pkts buffered | N    |     10   |   250    |
buffer space used | NM   |    120kb |     3Mb  |
pkt bits buffered | NS   |    120kb |   120kb  |
time to drain all | NS/X |  2,500ns | 2,500ns  |
Although each small packet takes up the same space in the buffer as a large packet, it's faster to get rid of it. 250 small packets take as long to drain as 10 large packets.

Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design
________________________________________________________________
Bob Briscoe,                                BT Innovate & Design
_______________________________________________
conex mailing list
conex@ietf.org
https://www.ietf.org/mailman/listinfo/conex

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design --=====================_681109994==.ALT-- From mirja.kuehlewind@ikr.uni-stuttgart.de Mon Nov 21 07:18:48 2011 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 5D9A61F0C56 for ; Mon, 21 Nov 2011 07:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, 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 O1ov13hfhWuC for ; Mon, 21 Nov 2011 07:18:43 -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 7DAB91F0C36 for ; Mon, 21 Nov 2011 07:18:43 -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 5CB4F633B1; Mon, 21 Nov 2011 16:18:41 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 46F2D59A8A; Mon, 21 Nov 2011 16:18:41 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: Ingemar Johansson S Date: Mon, 21 Nov 2011 16:18:40 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <20111030141755.21962.83789.idtracker@ietfa.amsl.com> <201111141742.38336.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: 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: <201111211618.40328.mirja.kuehlewind@ikr.uni-stuttgart.de> 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: Mon, 21 Nov 2011 15:18:48 -0000 Hi Ingemar, that sounds really complicated. From point of view, a policer should not do= =20 anything like this. The ConEx sender should be aware of the risk of=20 underestimating congestion. The current document on TCP modification propos= es=20 two 'hacks' how to get better feedback from a classic ECN receiver. Moreove= r,=20 the draft says in the section about credits that when a sender which=20 experiences on-going losses/ECN marks even though the sending rate was=20 reduced due to congestion control, it should think about sending credits as= =20 those losses might be introduced by an audit device.=20 In the meeting there was already a comment/question why more than one=20 possibility is needed to cope with classic ECN. The answer is all variants= =20 have draw-backs (e.g. risk of information loss when ACK loss occurs). But I= =20 guess some further advisement is needed here what the sender should do to=20 avoid underestimating the congestion and/or in which situation which action= =20 is the right one. But actually I'm not really sure what the right advise=20 would be.... Mirja On Tuesday 15 November 2011 09:25:57 Ingemar Johansson S wrote: > Thanks > > This then means that a policer need to give some extra slack for normal > TCP. It is perhaps doable with a policer that somehow has access to the T= CP > acks in the reverse direction and then can determine both RTT with a > reasonable accuracy and also if TCP ECE is modified according to > (http://tools.ietf.org/id/draft-kuehlewind-conex-tcp-modifications-01.txt) > Or is this perhaps simpler ? > > /Ingemar > > PS > Realized that I got things a bit backwards in my question below, thought > that ECE is clamped to 1 for an RTT... > > > -----Original Message----- > > From: Mirja Kuehlewind [mailto:mirja.kuehlewind@ikr.uni-stuttgart.de] > > Sent: den 14 november 2011 17:43 > > To: conex@ietf.org > > Cc: Ingemar Johansson S > > Subject: Re: [conex] ConEx as sender side only modification > > > > Hi Ingemar, > > > > yes there are only sender-side modification needed. If you > > only have the 'classic' ECN, you will only be able to get (at > > max) one congestion notification per RTT. If there is more > > than one CE marking per RTT you will underestimate the congestion. > > > > Mirja > > > > On Monday 14 November 2011 11:16:04 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 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 > > > > -- > > ------------------------------------------------------------------- > > 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-=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 john@jlc.net Mon Nov 21 12:33:58 2011 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 256A211E80F6 for ; Mon, 21 Nov 2011 12:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.542 X-Spam-Level: X-Spam-Status: No, score=-106.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 kysSUlqeZEsP for ; Mon, 21 Nov 2011 12:33:57 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 642E411E80E1 for ; Mon, 21 Nov 2011 12:33:57 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 80A5933C29; Mon, 21 Nov 2011 15:33:56 -0500 (EST) Date: Mon, 21 Nov 2011 15:33:56 -0500 From: John Leslie To: Bob Briscoe Message-ID: <20111121203356.GG22465@verdi> References: <201111171402.pAHE26tB006646@bagheera.jungle.bt.co.uk> <201111201956.pAKJuJSQ007421@bagheera.jungle.bt.co.uk> <20111120214012.GE22465@verdi> <201111202327.pAKNRJPT008060@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201111202327.pAKNRJPT008060@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Cc: ConEx IETF list Subject: Re: [conex] byte vs packet 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: Mon, 21 Nov 2011 20:33:58 -0000 Bob Briscoe wrote: > > Terminology for this email [abstract-mech]: > i) Policing /based on/ ConEx information and > ii) Audit /of/ ConEx information > are distinct functions. Agreed. > I fully agree that policing will be done how operators want to do it, > and we have no need to standardise anything about it. Good! > But audit is about checking one stream of signals against another. "Audit" tends to imply sampling and verifying an approximate match of things sampled. I'm afraid we've been a bit too vague about the sampling ratio... > It is a factual function, not a policy-related function. Umm... the sampling is somewhat policy-related... > Without audit, ConEx information is unreliable for policing, Actually, I don't agree with this. It's perfectly reasonable to design a policing function based on allowances, without reference to the accuracy of congestion prediction/responses. > monitoring or anything. Oh, hardly: monitoring is the first function of research; it need not depend on any particular balance of the things monitored. > Imagine an Internet where it is undefined whether ConEx and > congestion signals should balance per packet or per byte. Then both > types of audit and both types of transport will be implemented. So stipulated... > Let's assume some byte-based audit devices will discard traffic that > understates ConEx bytes. And some packet-based audit devices will > discard understatement in packets. Then these packet-balanced > auditors will drop byte-balanced transports. And vice-versa. I don't agree. Knowing that some implementations count packets and others count bytes, it would be somewhat stupid to punish based upon your personal preference between these two. > ConEx audit will become a machine for dropping large proportions of > packets. I don't follow... how could "audit" be a "machine for dropping" anything? > Please explain how you propose to prevent this disaster if we leave > the byte-packet question open. Actually, that's simplicity personified -- define ConEx marking with a byte-count field: if left blank the sender is byte-agnostic. (Though, to tell truth, I believe such a field SHOULD be optional, and I see no particular reason we need it at all...) > I am all for allowing flexibility in standards wherever possible, in > order to encourage diversity and innovation. There can certainly be > all sorts of implementations of the audit function, but we have to > minimally define whether audit is per byte or per packet - for > interoperability. I'm quite happy to define it "per packet", for now... > Can we find some way of resolving this argument, rather than keep > revisiting it? I believe _we_ could... -- John Leslie From bob.briscoe@bt.com Mon Nov 21 15:14:50 2011 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 74DBF11E80D5 for ; Mon, 21 Nov 2011 15:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 VMEU7Es+CObb for ; Mon, 21 Nov 2011 15:14:49 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3DF11E8119 for ; Mon, 21 Nov 2011 15:14:48 -0800 (PST) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Nov 2011 23:14:46 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Nov 2011 23:14:46 +0000 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 1321917285937; Mon, 21 Nov 2011 23:14:45 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.131.152]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id pALNEhvZ013554; Mon, 21 Nov 2011 23:14:43 GMT Message-Id: <201111212314.pALNEhvZ013554@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 21 Nov 2011 23:14:31 +0000 To: John Leslie From: Bob Briscoe In-Reply-To: <20111121203356.GG22465@verdi> References: <201111171402.pAHE26tB006646@bagheera.jungle.bt.co.uk> <201111201956.pAKJuJSQ007421@bagheera.jungle.bt.co.uk> <20111120214012.GE22465@verdi> <201111202327.pAKNRJPT008060@bagheera.jungle.bt.co.uk> <20111121203356.GG22465@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 21 Nov 2011 23:14:46.0309 (UTC) FILETIME=[5BF91D50:01CCA8A3] Cc: ConEx IETF list Subject: Re: [conex] byte vs packet 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: Mon, 21 Nov 2011 23:14:50 -0000 John, At 20:33 21/11/2011, John Leslie wrote: >Bob Briscoe wrote: > > > > But audit is about checking one stream of signals against another. > > "Audit" tends to imply sampling and verifying an approximate match >of things sampled. I'm afraid we've been a bit too vague about the >sampling ratio... [BB]: You're thinking of random audit. There is no implication of randomness or sampling in the word audit alone AFAIK. > > It is a factual function, not a policy-related function. > > Umm... the sampling is somewhat policy-related... [BB]: This debate is over whether we must define /what/ is being audited. Sampling is about /how/: we all agree that ConEx docs should not constrain the 'how'. > > Without audit, ConEx information is unreliable for policing, > > Actually, I don't agree with this. It's perfectly reasonable to >design a policing function based on allowances, without reference to >the accuracy of congestion prediction/responses. [BB]: This assertion is missing one hugely important piece of context. ConEx information is volunteered by the sender. As soon as the sender knows the info could be used against its interests, it has no reason to speak the truth. So the network will only use the sender's info for policing if it can verify its correctness. > > monitoring or anything. > > Oh, hardly: monitoring is the first function of research; it need >not depend on any particular balance of the things monitored. [BB]: As above. The situation changes drastically, as soon as monitored info might be used against the interests of the sender volunteering the information. > > > Imagine an Internet where it is undefined whether ConEx and > > congestion signals should balance per packet or per byte. Then both > > types of audit and both types of transport will be implemented. > > So stipulated... > > > Let's assume some byte-based audit devices will discard traffic that > > understates ConEx bytes. And some packet-based audit devices will > > discard understatement in packets. Then these packet-balanced > > auditors will drop byte-balanced transports. And vice-versa. > > I don't agree. Knowing that some implementations count packets and >others count bytes, it would be somewhat stupid to punish based upon >your personal preference between these two. [BB]: Then each type of audit function has to allow so much leeway that it opens a security hole the size of a bus. Even if byte-balance is the rule, audit security is balanced on a knife edge. Taking away this rule makes the security collapse. I suggest you go away and implement your proposed audit function, or at least produce a pseudocode design, then evaluate its security and bring it to the list if it passes muster. I can assure you, there is absolutely no value in inventing piecemeal in this space. The value of the whole ConEx system depends on the integrity of the signals that audit assures. It's extremely tricky to get right. There is value in brainstorming, but there is a time and place for such research. This ML is for standardisation. And we're late. > > ConEx audit will become a machine for dropping large proportions of > > packets. > > I don't follow... how could "audit" be a "machine for dropping" >anything? [BB]: ...by the assumption above that operators use their audit devices to discard traffic that does not cross-check. As you yourself said, we cannot tell operators what to do or not to do. We have to assume many will discard non-compliant traffic. > > Please explain how you propose to prevent this disaster if we leave > > the byte-packet question open. > > Actually, that's simplicity personified -- define ConEx marking >with a byte-count field: if left blank the sender is byte-agnostic. [BB]: OK, now you're switching to a different argument. The integrity of this flag would then need to be protected, to prevent it being changed enroute (and so far ConEx integrity works without any crypto, implying no key management complexity). (Give the list a little more time and I'm sure we will be able to think up a number of other security problems. Because the more flexibility, the larger the space of possible vulnerabilities.) Flexibility is fine if it's needed, but the burden is on you to prove a choice between packet and byte balance is necessary. >(Though, to tell truth, I believe such a field SHOULD be optional, >and I see no particular reason we need it at all...) So, that little excursion was just a waste of my time. > > I am all for allowing flexibility in standards wherever possible, in > > order to encourage diversity and innovation. There can certainly be > > all sorts of implementations of the audit function, but we have to > > minimally define whether audit is per byte or per packet - for > > interoperability. > > I'm quite happy to define it "per packet", for now... You have to argue against the reasons given why this is the wrong choice. The others in this discussion have all agreed that bytes is the correct choice. It is not sufficient to dismiss everyone else's arguments as irrelevant by calling them mathematical (I didn't see any explicit maths in the discussion, so perhaps you are objecting to the use of logical reasoning?). > > Can we find some way of resolving this argument, rather than keep > > revisiting it? > > I believe _we_ could... The only thing we agree on is that deployment must be possible. The drafts on the table are deployable. They are based on implementation experience. What you're really objecting to is stating the goal as byte-balance, even if we allow some implementers to do it approximately as packet-balance. Instead you want us to say the goal should be packet-balance, purely because it's easier to implement (in the case of TCP). However, altho your argument is only over what we state the goal as, you're not prepared to have that argument, because you reject what you call 'mathematical' argument. You have no implementation, no proposed design and you don't agree with arguing scientifically. I think it's time to ask the chairs to intervene. Bob >-- >John Leslie ________________________________________________________________ Bob Briscoe, BT Innovate & Design From john@jlc.net Mon Nov 21 16:19:36 2011 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 318F221F88B6 for ; Mon, 21 Nov 2011 16:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.544 X-Spam-Level: X-Spam-Status: No, score=-106.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 XEb+g5VVl8eI for ; Mon, 21 Nov 2011 16:19:35 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id A8E1321F88AB for ; Mon, 21 Nov 2011 16:19:34 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id C9CD633C21; Mon, 21 Nov 2011 19:19:28 -0500 (EST) Date: Mon, 21 Nov 2011 19:19:28 -0500 From: John Leslie To: Bob Briscoe Message-ID: <20111122001928.GH22465@verdi> References: <201111171402.pAHE26tB006646@bagheera.jungle.bt.co.uk> <201111201956.pAKJuJSQ007421@bagheera.jungle.bt.co.uk> <20111120214012.GE22465@verdi> <201111202327.pAKNRJPT008060@bagheera.jungle.bt.co.uk> <20111121203356.GG22465@verdi> <201111212314.pALNEhvZ013554@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201111212314.pALNEhvZ013554@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Cc: ConEx IETF list Subject: Re: [conex] byte vs packet 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: Tue, 22 Nov 2011 00:19:36 -0000 Bob Briscoe wrote: > At 20:33 21/11/2011, John Leslie wrote: >>Bob Briscoe wrote: >>> >>> But audit is about checking one stream of signals against another. >> >> "Audit" tends to imply sampling and verifying an approximate match >> of things sampled. I'm afraid we've been a bit too vague about the >> sampling ratio... > > [BB]: You're thinking of random audit. There is no implication of > randomness or sampling in the word audit alone AFAIK. (Usually it's easy to goad me into dictionary quotes, but today I shall resist.) I sincerely hope Bob isn't saying that an audit function has to evaluate _every_ packet which passes it! >>> It is a factual function, not a policy-related function. >> >> Umm... the sampling is somewhat policy-related... > > [BB]: This debate is over whether we must define /what/ is being > audited. Sampling is about /how/: we all agree that ConEx docs should > not constrain the 'how'. I'd prefer we didn't cast this discussion as a "debate". >>> Without audit, ConEx information is unreliable for policing, >> >> Actually, I don't agree with this. It's perfectly reasonable to >> design a policing function based on allowances, without reference >> to the accuracy of congestion prediction/responses. > > [BB]: This assertion is missing one hugely important piece of > context. ConEx information is volunteered by the sender. I don't follow. Whether or not ConEx information is "volunteered" by the sender, it is unreasonable to allow an unlimited number of ConEx congestion- expected marks without some cost recovery. > As soon as the sender knows the info could be used against its > interests, it has no reason to speak the truth. Good lord, Bob: all senders already know that anything they send "could be used against" them. And the truly critical piece of information is whether the sender, knowing of congestion, chooses to send more before the congestion has cleared. Standard TCP does. Less-than-best-effort transports try not to. Not all senders are evil. > So the network will only use the sender's info for policing if it > can verify its correctness. "Verify its correctness" sounds like handwaving to me. IMHO research is needed into what heuristics would help... >>> monitoring or anything. >> >> Oh, hardly: monitoring is the first function of research; it need >> not depend on any particular balance of the things monitored. > > [BB]: As above. The situation changes drastically, as soon as > monitored info might be used against the interests of the sender > volunteering the information. Research doesn't _need_ to work against the interests of the sender. >>> Let's assume some byte-based audit devices will discard traffic that >>> understates ConEx bytes. And some packet-based audit devices will >>> discard understatement in packets. Then these packet-balanced >>> auditors will drop byte-balanced transports. And vice-versa. >> >> I don't agree. Knowing that some implementations count packets and >> others count bytes, it would be somewhat stupid to punish based upon >> your personal preference between these two. > > [BB]: Then each type of audit function has to allow so much leeway > that it opens a security hole the size of a bus. Even if byte-balance > is the rule, audit security is balanced on a knife edge. Taking away > this rule makes the security collapse. "Audit security" had better not be "balanced on a knife edge!" Whether it is, IMHO, depends far more on what you choose to punish than what it is the sender intends to signal. (If we really need to argue "security", I'd advise seeking help from the Security Directorate.) > I suggest you go away and implement your proposed audit function, or > at least produce a pseudocode design, then evaluate its security and > bring it to the list if it passes muster. I can assure you, there is > absolutely no value in inventing piecemeal in this space. The value > of the whole ConEx system depends on the integrity of the signals > that audit assures. It's extremely tricky to get right. That would be foolish. Before going into that much detail, we should seek WG agreement on what we're trying to accomplish. For myself, I'd like to see folks _want_ to turn on ECN notifications instead of drops. The WG discussion so far doesn't seem to be considering that a goal. :^( > There is value in brainstorming, but there is a time and place for > such research. This ML is for standardisation. And we're late. Yes, we're late. No, we're not doing "standardization". We're producing an Experimental Track specification. Hopefully we'll design experiments and report on them, in due course. >>> ConEx audit will become a machine for dropping large proportions of >>> packets. >> >> I don't follow... how could "audit" be a "machine for dropping" >> anything? > > [BB]: ...by the assumption above that operators use their audit > devices to discard traffic that does not cross-check. As you yourself > said, we cannot tell operators what to do or not to do. We have to > assume many will discard non-compliant traffic. I don't have to assume that. And I don't assume that operators will do much of anything at first. We will define ConEx signals which will be blithely ignored by the substantial majority of operators unless they see a _substantial_ problem or are intrigued by a significant perceived benefit. There will be a few who go off on a tangent, preferentially dropping ConEx congestion-expected-marked packets. In our research, hopefully we will discover these misguided folks; and in an ideal world we'd convince them to preferentially ECN-mark-and-forward some limited amount of it. (This will not be trivial!) >>> Please explain how you propose to prevent this disaster if we leave >>> the byte-packet question open. >> >> Actually, that's simplicity personified -- define ConEx marking >> with a byte-count field: if left blank the sender is byte-agnostic. > > [BB]: OK, now you're switching to a different argument. No, I'm merely responding to your request. I didn't even "argue" how it can work... > The integrity of this flag would then need to be protected, to > prevent it being changed enroute (and so far ConEx integrity works > without any crypto, implying no key management complexity). That would be counter-productive. No operator can afford to verify cryptographic signatures for every packet in time of congestion. > (Give the list a little more time and I'm sure we will be able to > think up a number of other security problems. Because the more > flexibility, the larger the space of possible vulnerabilities.) I can think of quite enough security issues already, thank you. > Flexibility is fine if it's needed, but the burden is on you to prove > a choice between packet and byte balance is necessary. I think _you're_ the one arguing such a choice is needed now. >> (Though, to tell truth, I believe such a field SHOULD be optional, >> and I see no particular reason we need it at all...) > > So, that little excursion was just a waste of my time. I'm sorry if you think so... >>> I am all for allowing flexibility in standards wherever possible, in >>> order to encourage diversity and innovation. There can certainly be >>> all sorts of implementations of the audit function, but we have to >>> minimally define whether audit is per byte or per packet - for >>> interoperability. >> >> I'm quite happy to define it "per packet", for now... > > You have to argue against the reasons given why this is the wrong choice. I'm willing to do so. Please state them. > The others in this discussion have all agreed that bytes is the > correct choice. It is not sufficient to dismiss everyone else's > arguments as irrelevant by calling them mathematical (I didn't see > any explicit maths in the discussion, so perhaps you are objecting to > the use of logical reasoning?). I know you're capable of the math -- I gave you the benefit of the doubt whether you'd actually done it. >>> Can we find some way of resolving this argument, rather than keep >>> revisiting it? >> >> I believe _we_ could... > > The only thing we agree on is that deployment must be possible. That would be a good start. > The drafts on the table are deployable. They are based on > implementation experience. I respect implementation experience (though I seem to have missed the reports of the benefits of precise byte-counting that ensued). > What you're really objecting to is stating the goal as byte-balance, That's true, I guess -- though I've been trying to elicit reasons why counting packets instead of bytes is harmful before "objecting" on the list. > even if we allow some implementers to do it approximately as > packet-balance. This strikes me as a poor practice. If byte-counting is so important, we should set out to convince implementors to do it. > Instead you want us to say the goal should be packet-balance, purely > because it's easier to implement (in the case of TCP). Ease of implementation is a strong argument when you're looking for widespread deployment. (I could go into other reasons, but that seems counter-productive.) > However, although your argument is only over what we state the goal > as, you're not prepared to have that argument, because you reject > what you call 'mathematical' argument. No -- I don't reject it, until I see it. > You have no implementation, no proposed design and you don't agree > with arguing scientifically. I don't generally approach IETF work by first choosing an implementation, then arguing for it. I approach IETF work as design, trying to balance a lot of differing concerns. > I think it's time to ask the chairs to intervene. I don't ask for that -- and I think it premature until we have others stating that one or the other of us is disruptive. IMHO, there's been little enough traffic on this list to classify _anyone_ as disruptive. -- John Leslie From bob.briscoe@bt.com Mon Nov 21 19:48:37 2011 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 CB30911E8153 for ; Mon, 21 Nov 2011 19:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.884 X-Spam-Level: X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, 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 Oorp2GGwwPwr for ; Mon, 21 Nov 2011 19:48:36 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by ietfa.amsl.com (Postfix) with ESMTP id 0576011E8073 for ; Mon, 21 Nov 2011 19:48:35 -0800 (PST) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Nov 2011 03:48:33 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Nov 2011 03:48:33 +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 1321933712649; Tue, 22 Nov 2011 03:48:32 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.131.152]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id pAM3mPOo014812; Tue, 22 Nov 2011 03:48:26 GMT Message-Id: <201111220348.pAM3mPOo014812@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 22 Nov 2011 03:48:22 +0000 To: John Leslie From: Bob Briscoe In-Reply-To: <20111122001928.GH22465@verdi> References: <201111171402.pAHE26tB006646@bagheera.jungle.bt.co.uk> <201111201956.pAKJuJSQ007421@bagheera.jungle.bt.co.uk> <20111120214012.GE22465@verdi> <201111202327.pAKNRJPT008060@bagheera.jungle.bt.co.uk> <20111121203356.GG22465@verdi> <201111212314.pALNEhvZ013554@bagheera.jungle.bt.co.uk> <20111122001928.GH22465@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 22 Nov 2011 03:48:33.0717 (UTC) FILETIME=[9B78A650:01CCA8C9] Cc: ConEx IETF list Subject: Re: [conex] byte vs packet 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: Tue, 22 Nov 2011 03:48:37 -0000 John, At 00:19 22/11/2011, John Leslie wrote: >Bob Briscoe wrote: > > At 20:33 21/11/2011, John Leslie wrote: > >>Bob Briscoe wrote: > >>> > >>> But audit is about checking one stream of signals against another. > >> > >> "Audit" tends to imply sampling and verifying an approximate match > >> of things sampled. I'm afraid we've been a bit too vague about the > >> sampling ratio... > > > > [BB]: You're thinking of random audit. There is no implication of > > randomness or sampling in the word audit alone AFAIK. > > (Usually it's easy to goad me into dictionary quotes, but today >I shall resist.) > > I sincerely hope Bob isn't saying that an audit function has to >evaluate _every_ packet which passes it! I am. You might be surprised to learn that nearly every aspect of a communications system evaluates every packet that passes it. > >>> It is a factual function, not a policy-related function. > >> > >> Umm... the sampling is somewhat policy-related... > > > > [BB]: This debate is over whether we must define /what/ is being > > audited. Sampling is about /how/: we all agree that ConEx docs should > > not constrain the 'how'. > > I'd prefer we didn't cast this discussion as a "debate". > > >>> Without audit, ConEx information is unreliable for policing, > >> > >> Actually, I don't agree with this. It's perfectly reasonable to > >> design a policing function based on allowances, without reference > >> to the accuracy of congestion prediction/responses. > > > > [BB]: This assertion is missing one hugely important piece of > > context. ConEx information is volunteered by the sender. > > I don't follow. A policy device like a congestion policer using ConEx signals to decide which traffic to police. But the ConEx signals it relies on are declared by the sender who stands to lose from the policing. There is an (obvious) security flaw in that arrangement where the sender can just make up ConEx signals that suit its interests, rather than re-echoing actual congestion. That is solved by the network auditing ConEx signals against the actual congestion signalling that is independent of the sender (ie against actual losses or ECN marks). > Whether or not ConEx information is "volunteered" by the sender, >it is unreasonable to allow an unlimited number of ConEx congestion- >expected marks without some cost recovery. That's true but missing the point about audit. Without audit, if the network imposes a limit on ConEx marks or some form of cost recovery, the sender could just not set ConEx marks and still cause congestion. > > As soon as the sender knows the info could be used against its > > interests, it has no reason to speak the truth. > > Good lord, Bob: all senders already know that anything they send >"could be used against" them. I am guessing what you are thinking here. You might mean how much volume the sender sends could be used against it. You might mean the information the sender puts in the payload could be used against it. But ConEx is different - the sender doesn't have to send ConEx info in order to communicate the payload information it wants to send. So the operator has to be able to make it in the sender's interest to do so. And we (the IETF) have to define the protocol so that operators can. > And the truly critical piece of information is whether the sender, >knowing of congestion, chooses to send more before the congestion has >cleared. Standard TCP does. Less-than-best-effort transports try not >to. > > Not all senders are evil. > > > So the network will only use the sender's info for policing if it > > can verify its correctness. > > "Verify its correctness" sounds like handwaving to me. IMHO research >is needed into what heuristics would help... Please don't read this as handwaving. Verifying correctness is what audit does. You can look at the code. If you want, you can imagine the code was written randomly by waving a hand at a keyboard. But actually it was thought about for months, and every time a vulnerability was discovered, the whole protocol/audit system was reworked. Then the code was optimised for performance. And it was tested and reworked. Then reworked again. For years. Perhaps, if you believe these things are the result of hand-waving, that says more about how you expect to work. > >>> monitoring or anything. > >> > >> Oh, hardly: monitoring is the first function of research; it need > >> not depend on any particular balance of the things monitored. > > > > [BB]: As above. The situation changes drastically, as soon as > > monitored info might be used against the interests of the sender > > volunteering the information. > > Research doesn't _need_ to work against the interests of the sender. Eh? Perhaps s/Research/Monitoring/ ? No it doesn't have to. But it is enough for there to be a risk. Then the sender will not want to tell the truth. > >>> Let's assume some byte-based audit devices will discard traffic that > >>> understates ConEx bytes. And some packet-based audit devices will > >>> discard understatement in packets. Then these packet-balanced > >>> auditors will drop byte-balanced transports. And vice-versa. > >> > >> I don't agree. Knowing that some implementations count packets and > >> others count bytes, it would be somewhat stupid to punish based upon > >> your personal preference between these two. > > > > [BB]: Then each type of audit function has to allow so much leeway > > that it opens a security hole the size of a bus. Even if byte-balance > > is the rule, audit security is balanced on a knife edge. Taking away > > this rule makes the security collapse. > > "Audit security" had better not be "balanced on a knife edge!" >Whether it is, IMHO, depends far more on what you choose to punish >than what it is the sender intends to signal. Audit security /is/ balanced on a knife-edge. > (If we really need to argue "security", I'd advise seeking help >from the Security Directorate.) Had you not appreciated previously that ConEx is /primarily/ about security? Astounding. > > I suggest you go away and implement your proposed audit function, or > > at least produce a pseudocode design, then evaluate its security and > > bring it to the list if it passes muster. I can assure you, there is > > absolutely no value in inventing piecemeal in this space. The value > > of the whole ConEx system depends on the integrity of the signals > > that audit assures. It's extremely tricky to get right. > > That would be foolish. What!? Are you not aware of the ground rules here? Rough consensus and running code. I don't bring anything to the IETF until it has been implemented, tested and independently verified. Especially if it's a change to something as fundamental as IP. If you or anyone else wants to play in a different ball-game, those of us who play by the rules are entitled to ask you to go somewhere else. > Before going into that much detail, we should seek WG agreement >on what we're trying to accomplish. That should largely be done by the end of chartering stage. I fundamentally disagree with you here. I think everyone else does too. Defining an experimental protocol still requires the same decisions to be made as a stanrds track protc0l. It has to be implementable. Quickly. >For myself, I'd like to see >folks _want_ to turn on ECN notifications instead of drops. The WG >discussion so far doesn't seem to be considering that a goal. :^( This is not in the CoNEx charter. (But I'm still pursuing this in my own company too) However, my take is that ConEx deployment should make operators want to turn on ECN. I realised early on that ECN doesn't provide enough advantage on its own to warrant the deployment upheaval. > > There is value in brainstorming, but there is a time and place for > > such research. This ML is for standardisation. And we're late. > > Yes, we're late. > > No, we're not doing "standardization". We're producing an >Experimental Track specification. Hopefully we'll design experiments >and report on them, in due course. Sorry. wrong word. But I had the right sentiment. This ML is for defining the experimental protocols, not musing about possible designs that you haven't thought through. > >>> ConEx audit will become a machine for dropping large proportions of > >>> packets. > >> > >> I don't follow... how could "audit" be a "machine for dropping" > >> anything? > > > > [BB]: ...by the assumption above that operators use their audit > > devices to discard traffic that does not cross-check. As you yourself > > said, we cannot tell operators what to do or not to do. We have to > > assume many will discard non-compliant traffic. > > I don't have to assume that. If an operator is going to rely on the info in ConEx signals to drive a policer, it will need an audit device (recapping the earlier argument). If the audit device detects sender's ConEx info is lying relative to actual congestion info, but it does nothing about it, what stops the sender lying? > And I don't assume that operators will do much of anything at first. >We will define ConEx signals which will be blithely ignored by the >substantial majority of operators unless they see a _substantial_ >problem or are intrigued by a significant perceived benefit. Yup. That's how I see it starting too. > There will be a few who go off on a tangent, preferentially dropping >ConEx congestion-expected-marked packets. In our research, hopefully >we will discover these misguided folks; and in an ideal world we'd >convince them to preferentially ECN-mark-and-forward some limited >amount of it. (This will not be trivial!) I hope 'it' means all ECN-capable traffic, not just the congestion-expected-marked packets. > >>> I am all for allowing flexibility in standards wherever possible, in > >>> order to encourage diversity and innovation. There can certainly be > >>> all sorts of implementations of the audit function, but we have to > >>> minimally define whether audit is per byte or per packet - for > >>> interoperability. > >> > >> I'm quite happy to define it "per packet", for now... > > > > You have to argue against the reasons given why this is the wrong choice. > > I'm willing to do so. Please state them. All the reasons already given in this thread that you have glossed over, while focusing on occasional words and phrases instead of people's arguments. > > The drafts on the table are deployable. They are based on > > implementation experience. > > I respect implementation experience (though I seem to have missed >the reports of the benefits of precise byte-counting that ensued). Ditto. > > What you're really objecting to is stating the goal as byte-balance, > > That's true, I guess -- though I've been trying to elicit reasons >why counting packets instead of bytes is harmful before "objecting" >on the list. If you've been trying to elicit these reasons, it's strange you missed them. > > even if we allow some implementers to do it approximately as > > packet-balance. > > This strikes me as a poor practice. If byte-counting is so important, >we should set out to convince implementors to do it. I gave the approach we can offer to do byte-counting early in the thread. And this is largely in the TCP modes I-D too. The above sentence just says we don't need to insist on how implementers meet the goal, and they can even do packet-balance if they think they will get it through a byte-balancing auditor. > > Instead you want us to say the goal should be packet-balance, purely > > because it's easier to implement (in the case of TCP). > > Ease of implementation is a strong argument when you're looking for >widespread deployment. (I could go into other reasons, but that seems >counter-productive.) How many times do I have to say: i) it's no good ONLY caring about ease of implementation, without caring about whether it meets a sensible goal too. ii) the strategies in the second mail in this thread are easy to implement > > However, although your argument is only over what we state the goal > > as, you're not prepared to have that argument, because you reject > > what you call 'mathematical' argument. > > No -- I don't reject it, until I see it. You saw it and rejected it. You have a short memory. > > You have no implementation, no proposed design and you don't agree > > with arguing scientifically. > > I don't generally approach IETF work by first choosing an implementation, >then arguing for it. I approach IETF work as design, trying to balance >a lot of differing concerns. You don't get to choose the rules. THe IETF constitution is "running code". I'm not arguing /for/ an implementation. I'm arguing for a system design. Implementation gives confidence one is speaking from real experience. Then one can make compromises with others who made different choices in their design, knowing better that the new mix of designs will work. What about the arguing scientifically point? > > I think it's time to ask the chairs to intervene. > > I don't ask for that -- and I think it premature until we have others >stating that one or the other of us is disruptive. I was asking for the chairs to intervene. I'm tired of arguing with someone who is working to different rules than everyone else - rules that don't admit to reasoning, so we can never have any way to determine an argument. > IMHO, there's been little enough traffic on this list to classify >_anyone_ as disruptive. Small precise discussion is far preferable to voluminous imprecise waffle. Bob >-- >John Leslie ________________________________________________________________ Bob Briscoe, BT Innovate & Design From Dirk.Kutscher@neclab.eu Tue Nov 22 01:04:53 2011 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 A9B8921F8B74 for ; Tue, 22 Nov 2011 01:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 gixo3bLWOeoa for ; Tue, 22 Nov 2011 01:04:52 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1636021F8B6C for ; Tue, 22 Nov 2011 01:04:52 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 133FB280000F7; Tue, 22 Nov 2011 10:04:51 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vczo0ZTM4X8a; Tue, 22 Nov 2011 10:04:50 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id E6B2628000085; Tue, 22 Nov 2011 10:04:35 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.40]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 22 Nov 2011 10:04:35 +0100 From: Dirk Kutscher To: John Leslie , Bob Briscoe Thread-Topic: [conex] byte vs packet counting Thread-Index: AQHMp76JZL8r+V/zRk++ftEqZzK+IpW2ObYAgAAdnICAAWI1AIAALN6AgAASJQCAAJ/xcA== Date: Tue, 22 Nov 2011 09:04:35 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F524924B97E81@Polydeuces.office.hd> References: <201111171402.pAHE26tB006646@bagheera.jungle.bt.co.uk> <201111201956.pAKJuJSQ007421@bagheera.jungle.bt.co.uk> <20111120214012.GE22465@verdi> <201111202327.pAKNRJPT008060@bagheera.jungle.bt.co.uk> <20111121203356.GG22465@verdi> <201111212314.pALNEhvZ013554@bagheera.jungle.bt.co.uk> <20111122001928.GH22465@verdi> In-Reply-To: <20111122001928.GH22465@verdi> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.209] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ConEx IETF list Subject: Re: [conex] byte vs packet 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: Tue, 22 Nov 2011 09:04:53 -0000 Hi folks, > >>> But audit is about checking one stream of signals against another. > >> > >> "Audit" tends to imply sampling and verifying an approximate match of > >> things sampled. I'm afraid we've been a bit too vague about the > >> sampling ratio... > > > > [BB]: You're thinking of random audit. There is no implication of > > randomness or sampling in the word audit alone AFAIK. >=20 > (Usually it's easy to goad me into dictionary quotes, but today I shal= l resist.) >=20 > I sincerely hope Bob isn't saying that an audit function has to evalua= te > _every_ packet which passes it! Clearly, it at least has to be able to do that, yes! Auditing is really a f= undamental piece of the basic Conex mechanism, and has nothing to do with p= olicy. Auditing is the basis for accurate congestion exposure. Only if you = have that, you can think about implementing policies. Having said that, it is certainly implementation-specific how auditing real= ly works -- there may be tradeoffs between efficiency and effectiveness -- = but for the sake of the discussion here, I'd say it's best to assume that, = yes, auditing evaluates every packet. Best regards, Dirk =20 > >>> It is a factual function, not a policy-related function. > >> > >> Umm... the sampling is somewhat policy-related... > > > > [BB]: This debate is over whether we must define /what/ is being > > audited. Sampling is about /how/: we all agree that ConEx docs should > > not constrain the 'how'. >=20 > I'd prefer we didn't cast this discussion as a "debate". >=20 > >>> Without audit, ConEx information is unreliable for policing, > >> > >> Actually, I don't agree with this. It's perfectly reasonable to > >> design a policing function based on allowances, without reference to > >> the accuracy of congestion prediction/responses. > > > > [BB]: This assertion is missing one hugely important piece of context. > > ConEx information is volunteered by the sender. >=20 > I don't follow. >=20 > Whether or not ConEx information is "volunteered" by the sender, it is > unreasonable to allow an unlimited number of ConEx congestion- expected > marks without some cost recovery. >=20 > > As soon as the sender knows the info could be used against its > > interests, it has no reason to speak the truth. >=20 > Good lord, Bob: all senders already know that anything they send "coul= d be > used against" them. >=20 > And the truly critical piece of information is whether the sender, kno= wing of > congestion, chooses to send more before the congestion has cleared. > Standard TCP does. Less-than-best-effort transports try not to. >=20 > Not all senders are evil. >=20 > > So the network will only use the sender's info for policing if it can > > verify its correctness. >=20 > "Verify its correctness" sounds like handwaving to me. IMHO research i= s > needed into what heuristics would help... >=20 > >>> monitoring or anything. > >> > >> Oh, hardly: monitoring is the first function of research; it need not > >> depend on any particular balance of the things monitored. > > > > [BB]: As above. The situation changes drastically, as soon as > > monitored info might be used against the interests of the sender > > volunteering the information. >=20 > Research doesn't _need_ to work against the interests of the sender. >=20 > >>> Let's assume some byte-based audit devices will discard traffic that > >>> understates ConEx bytes. And some packet-based audit devices will > >>> discard understatement in packets. Then these packet-balanced > >>> auditors will drop byte-balanced transports. And vice-versa. > >> > >> I don't agree. Knowing that some implementations count packets and > >> others count bytes, it would be somewhat stupid to punish based upon > >> your personal preference between these two. > > > > [BB]: Then each type of audit function has to allow so much leeway > > that it opens a security hole the size of a bus. Even if byte-balance > > is the rule, audit security is balanced on a knife edge. Taking away > > this rule makes the security collapse. >=20 > "Audit security" had better not be "balanced on a knife edge!" > Whether it is, IMHO, depends far more on what you choose to punish than > what it is the sender intends to signal. >=20 > (If we really need to argue "security", I'd advise seeking help from t= he > Security Directorate.) >=20 > > I suggest you go away and implement your proposed audit function, or > > at least produce a pseudocode design, then evaluate its security and > > bring it to the list if it passes muster. I can assure you, there is > > absolutely no value in inventing piecemeal in this space. The value of > > the whole ConEx system depends on the integrity of the signals that > > audit assures. It's extremely tricky to get right. >=20 > That would be foolish. >=20 > Before going into that much detail, we should seek WG agreement on wha= t > we're trying to accomplish. For myself, I'd like to see folks _want_ to t= urn on > ECN notifications instead of drops. The WG discussion so far doesn't seem= to > be considering that a goal. :^( >=20 > > There is value in brainstorming, but there is a time and place for > > such research. This ML is for standardisation. And we're late. >=20 > Yes, we're late. >=20 > No, we're not doing "standardization". We're producing an Experimental > Track specification. Hopefully we'll design experiments and report on the= m, > in due course. >=20 > >>> ConEx audit will become a machine for dropping large proportions of > >>> packets. > >> > >> I don't follow... how could "audit" be a "machine for dropping" > >> anything? > > > > [BB]: ...by the assumption above that operators use their audit > > devices to discard traffic that does not cross-check. As you yourself > > said, we cannot tell operators what to do or not to do. We have to > > assume many will discard non-compliant traffic. >=20 > I don't have to assume that. >=20 > And I don't assume that operators will do much of anything at first. > We will define ConEx signals which will be blithely ignored by the substa= ntial > majority of operators unless they see a _substantial_ problem or are > intrigued by a significant perceived benefit. >=20 > There will be a few who go off on a tangent, preferentially dropping C= onEx > congestion-expected-marked packets. In our research, hopefully we will > discover these misguided folks; and in an ideal world we'd convince them = to > preferentially ECN-mark-and-forward some limited amount of it. (This will > not be trivial!) >=20 > >>> Please explain how you propose to prevent this disaster if we leave > >>> the byte-packet question open. > >> > >> Actually, that's simplicity personified -- define ConEx marking with > >> a byte-count field: if left blank the sender is byte-agnostic. > > > > [BB]: OK, now you're switching to a different argument. >=20 > No, I'm merely responding to your request. I didn't even "argue" > how it can work... >=20 > > The integrity of this flag would then need to be protected, to prevent > > it being changed enroute (and so far ConEx integrity works without any > > crypto, implying no key management complexity). >=20 > That would be counter-productive. No operator can afford to verify > cryptographic signatures for every packet in time of congestion. >=20 > > (Give the list a little more time and I'm sure we will be able to > > think up a number of other security problems. Because the more > > flexibility, the larger the space of possible vulnerabilities.) >=20 > I can think of quite enough security issues already, thank you. >=20 > > Flexibility is fine if it's needed, but the burden is on you to prove > > a choice between packet and byte balance is necessary. >=20 > I think _you're_ the one arguing such a choice is needed now. >=20 > >> (Though, to tell truth, I believe such a field SHOULD be optional, > >> and I see no particular reason we need it at all...) > > > > So, that little excursion was just a waste of my time. >=20 > I'm sorry if you think so... >=20 > >>> I am all for allowing flexibility in standards wherever possible, in > >>> order to encourage diversity and innovation. There can certainly be > >>> all sorts of implementations of the audit function, but we have to > >>> minimally define whether audit is per byte or per packet - for > >>> interoperability. > >> > >> I'm quite happy to define it "per packet", for now... > > > > You have to argue against the reasons given why this is the wrong choic= e. >=20 > I'm willing to do so. Please state them. >=20 > > The others in this discussion have all agreed that bytes is the > > correct choice. It is not sufficient to dismiss everyone else's > > arguments as irrelevant by calling them mathematical (I didn't see any > > explicit maths in the discussion, so perhaps you are objecting to the > > use of logical reasoning?). >=20 > I know you're capable of the math -- I gave you the benefit of the dou= bt > whether you'd actually done it. >=20 > >>> Can we find some way of resolving this argument, rather than keep > >>> revisiting it? > >> > >> I believe _we_ could... > > > > The only thing we agree on is that deployment must be possible. >=20 > That would be a good start. >=20 > > The drafts on the table are deployable. They are based on > > implementation experience. >=20 > I respect implementation experience (though I seem to have missed the > reports of the benefits of precise byte-counting that ensued). >=20 > > What you're really objecting to is stating the goal as byte-balance, >=20 > That's true, I guess -- though I've been trying to elicit reasons why = counting > packets instead of bytes is harmful before "objecting" > on the list. >=20 > > even if we allow some implementers to do it approximately as > > packet-balance. >=20 > This strikes me as a poor practice. If byte-counting is so important, = we > should set out to convince implementors to do it. >=20 > > Instead you want us to say the goal should be packet-balance, purely > > because it's easier to implement (in the case of TCP). >=20 > Ease of implementation is a strong argument when you're looking for > widespread deployment. (I could go into other reasons, but that seems > counter-productive.) >=20 > > However, although your argument is only over what we state the goal > > as, you're not prepared to have that argument, because you reject what > > you call 'mathematical' argument. >=20 > No -- I don't reject it, until I see it. >=20 > > You have no implementation, no proposed design and you don't agree > > with arguing scientifically. >=20 > I don't generally approach IETF work by first choosing an implementati= on, > then arguing for it. I approach IETF work as design, trying to balance a = lot of > differing concerns. >=20 > > I think it's time to ask the chairs to intervene. >=20 > I don't ask for that -- and I think it premature until we have others = stating > that one or the other of us is disruptive. >=20 > IMHO, there's been little enough traffic on this list to classify _any= one_ as > disruptive. >=20 > -- > John Leslie > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From mattmathis@google.com Tue Nov 22 13:19:32 2011 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 4545511E80C1 for ; Tue, 22 Nov 2011 13:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.492, 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 CZ0HFFSHnIB1 for ; Tue, 22 Nov 2011 13:19:31 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4541C11E80AA for ; Tue, 22 Nov 2011 13:19:31 -0800 (PST) Received: by ghrr14 with SMTP id r14so752769ghr.31 for ; Tue, 22 Nov 2011 13:19:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=lpjLiswgygTcR9D5FguP7dDWjVlDb5E4dVvLqmKpNOk=; b=GzUSSaWmVLPPIuKE9on0o3g7Gmx5TV7+AIuZA7KbzVuHEHzlJoqKafMk5SwUpbn/Yb XNniP1cl1wzA1cyDV6OQ== Received: by 10.213.13.6 with SMTP id z6mr1117547ebz.13.1321996770047; Tue, 22 Nov 2011 13:19:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.213.13.6 with SMTP id z6mr1117540ebz.13.1321996769774; Tue, 22 Nov 2011 13:19:29 -0800 (PST) Received: by 10.213.9.4 with HTTP; Tue, 22 Nov 2011 13:19:29 -0800 (PST) In-Reply-To: <20111120214012.GE22465@verdi> References: <201111171402.pAHE26tB006646@bagheera.jungle.bt.co.uk> <201111201956.pAKJuJSQ007421@bagheera.jungle.bt.co.uk> <20111120214012.GE22465@verdi> Date: Tue, 22 Nov 2011 13:19:29 -0800 Message-ID: From: Matt Mathis To: John Leslie Content-Type: multipart/alternative; boundary=001517503db2db4e9f04b2595b80 X-System-Of-Record: true Cc: ConEx IETF list Subject: Re: [conex] byte vs packet 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: Tue, 22 Nov 2011 21:19:32 -0000 --001517503db2db4e9f04b2595b80 Content-Type: text/plain; charset=ISO-8859-1 Rolling back this whole thread... On Sun, Nov 20, 2011 at 1:40 PM, John Leslie wrote: > Bob Briscoe wrote: > > > > Matt, > > (I do understand that Bob is addressing Matt...) > > > [Adding the ConEx list back in] > > I do not agree that this is a discussion which should gate on the > opinions of Bob and Matt. > Bob and I prefer to argue in private, because it works better. We always assume that the other person is correct, and make every effort to try to understand what they think and why. This is why we have often been able to clearly restate each others arguments. In that process comes enlightenment, deeper understanding and an opportunity to tease apart our underlying assumptions. What typically happens is that we discover some hidden assumption, and that both of our initial positions are over simplifications and at some level both are wrong. When we argue in public, the entire discussion get rat holed about details that are aren't on the table, either because the rest of us already have consensus or they just are not important at this stage. My take away from the intended discussion with Bob is that -abstract-mech- is flawed in that it is entirely too casual about units. The units (primarily bits v bytes v packets of congestion) should be an explicitly chosen parameter for each span of the model (congested router to receiver, ACKs carrying the signal back to the sender, reinserted feedback from the sender to the audit and policy functions). While I am inclined to agree with Bob that the congestion signal should be in bytes, I am less convinced that it is ok for the ACKs to only carry segment counts. I am willing to proceed on the basis of his assumptions, however it is critical that we all understand that this is a design decision that might be changed in the future if there is a compelling reason to do so. The abstract mech doc needs to state that proposed signal mappings for a given tentative encoding must be explicit about units. It is also important to note that for legacy interoperability using a sender only implementation, we can not assert different algorithms than are present in current network devices and ECN enabled receivers. My example earlier in the thread illustrates a rather extreme pathological case where bytes v segments might change sender behavior. In the common case and as a natural approximation, the sender will probably assume that the data in not lumpy, and that reflecting the correct number packets is good enough. Clearly when all of the packets in a given connection have uniform sizes, it doesn't matter to any component, except the policy devices. The places proper treatment of lumpy data might matter are the policy and audit devices, which will be the last part of ConEx to have fully bound specifications. Some of their details are even explicitly out of our scope, although we do have to demonstrate the existence of algorithms that provide useful signals. As I reflect on the broader debate, it is clear to me the we really need to understand choosing units of congestion as an engineering compromise. Like all such compromises, it has to balance the costs of difficulty of implementation vs opportunity cost of reduced precision. Furthermore, extended debate without hard data is pointless. It just doesn't matter at this stage. We can accept Bob's assumption for the time being, note that it is "provisional" and revisit it later, if or when we encounter a problem that would be better solved with different assumptions. John, can we arrange a phone call some time? I want to understand your vision for ConEx better. Is the phone number on your 2017 consulting page correct? (New Hampshire) Thanks, --MM-- --001517503db2db4e9f04b2595b80 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Rolling back this whole thread...


On Sun, Nov 20, 201= 1 at 1:40 PM, John Leslie <john@jlc.net> wrote:
Bob Briscoe <bob.briscoe@bt.com> wrote:
>
> Matt,

=A0 (I do understand that Bob is addressing Matt...)

> [Adding the ConEx list back in]

=A0 I do not agree that this is a discussion which should gate on th= e
opinions of Bob and Matt.

Bob and I pre= fer to argue in private, because it works better. =A0 We always assume that= the other person is correct, and make every effort to try to understand wh= at they think and why. =A0 This is why we have often been able to clearly r= estate each others arguments. =A0In that process comes=A0enlightenment, dee= per understanding and an opportunity to tease=A0apart=A0our underlying assu= mptions. =A0What typically happens is that we discover some hidden assumpti= on, and that both of our initial positions are over simplifications and at = some level both are wrong.

When we argue in public, the entire discussion get rat = holed about=A0details that are aren't on the table, either because the = rest of us=A0already=A0have consensus or they just are not important at thi= s stage.

My take away from the intended discussion with Bob is t= hat -abstract-mech- is flawed in that it is=A0entirely=A0too casual about u= nits. =A0The units (primarily bits v bytes v packets of congestion) should = be an=A0explicitly chosen parameter for each span of the model (congested r= outer to receiver, ACKs carrying the signal back to the sender, reinserted = feedback from the sender to the audit and policy functions).

While I am inclined to agree with Bob that the congesti= on signal should be in bytes, I am less convinced that it is ok for the ACK= s to only carry segment counts. =A0I am willing to proceed on the basis of = his assumptions, however it is critical that we all understand that this is= a design=A0decision that might be changed in the future if there is a comp= elling reason to do so. =A0The abstract mech doc needs to state that propos= ed signal mappings for a given tentative encoding must be explicit about un= its.

It is also important to note that for legacy interopera= bility=A0using a sender only implementation, we can not assert different al= gorithms than are present in current network devices and ECN enabled receiv= ers. =A0 My example earlier in the thread illustrates a=A0rather extreme=A0= pathological case where bytes v segments might change sender behavior. =A0I= n the common case=A0and as a natural approximation,=A0the sender will proba= bly assume that the data in not lumpy, and that reflecting the correct numb= er packets is good enough. =A0=A0Clearly=A0when all of the packets in a giv= en connection have uniform sizes, it doesn't matter to any component, e= xcept the policy devices.

The places proper treatment of lumpy data might matter = are the policy and audit devices, which will be the last part of ConEx to h= ave fully bound specifications. =A0 Some of their details are even explicit= ly out of our scope, although we do have to demonstrate the existence of=A0= algorithms=A0that provide useful signals.

As I reflect on the broader debate, it is clear to me t= he we really need to=A0understand choosing =A0units of congestion as an eng= ineering=A0compromise. =A0Like all such=A0compromises, it has to balance th= e costs of difficulty of implementation vs opportunity cost=A0of reduced pr= ecision. =A0=A0Furthermore, extended debate without hard data is pointless.= =A0 It just doesn't matter at this stage. =A0 We can accept Bob's = assumption for the time being, note that it is "provisional" and = revisit it later, if or when we encounter a problem that would be better so= lved with different assumptions.

John, can we arrange a phone call some time? =A0I want = to understand your vision for ConEx better. =A0Is the phone number on your = 2017 consulting page correct? =A0(New=A0Hampshire)=A0

<= div>Thanks,
--MM--


--001517503db2db4e9f04b2595b80-- From marcelo@it.uc3m.es Wed Nov 23 10:02:57 2011 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 036D621F8B65 for ; Wed, 23 Nov 2011 10:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.382 X-Spam-Level: X-Spam-Status: No, score=-106.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 664CB58t-682 for ; Wed, 23 Nov 2011 10:02:56 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 67FB221F8B4D for ; Wed, 23 Nov 2011 10:02:56 -0800 (PST) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (1.31.18.95.dynamic.jazztel.es [95.18.31.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 7533775AA6A for ; Wed, 23 Nov 2011 19:02:53 +0100 (CET) Message-ID: <4ECD354C.8080001@it.uc3m.es> Date: Wed, 23 Nov 2011 19:02:52 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 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-18538.000 Subject: [conex] adoption of draft-kuehlewind-conex-tcp-modifications-01 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, 23 Nov 2011 18:02:57 -0000 During the last meeting we talked about adopting this draft as WG item. before proceeding with its adoption, i would like to confirm the consensus in the ml. If someone has an issue with this, please comment before dec 1st. Regards, marcelo From bob.briscoe@bt.com Fri Nov 25 10:42:18 2011 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 B76E721F8AFC for ; Fri, 25 Nov 2011 10:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.192 X-Spam-Level: X-Spam-Status: No, score=-3.192 tagged_above=-999 required=5 tests=[AWL=0.407, 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 GKh89F+8qDbL for ; Fri, 25 Nov 2011 10:42:18 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by ietfa.amsl.com (Postfix) with ESMTP id 0E52621F8AEE for ; Fri, 25 Nov 2011 10:42:17 -0800 (PST) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Nov 2011 18:42:15 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Nov 2011 18:42:15 +0000 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 1322246535424; Fri, 25 Nov 2011 18:42:15 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.131.152]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id pAPIgDjI007487 for ; Fri, 25 Nov 2011 18:42:13 GMT Message-Id: <201111251842.pAPIgDjI007487@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 25 Nov 2011 18:42:12 +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 X-OriginalArrivalTime: 25 Nov 2011 18:42:15.0175 (UTC) FILETIME=[F3971170:01CCABA1] Subject: [conex] Fwd: New Version Notification for draft-briscoe-conex-initial-deploy-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: Fri, 25 Nov 2011 18:42:18 -0000 ConEx list, I re-posted this one yesterday after Jari Arkko pointed out the text was duplicated twice within the draft (triggering an error for his stats tools). Otherwise no changes (yet). Bob >From: >To: >CC: >Subject: New Version Notification for >draft-briscoe-conex-initial-deploy-01.txt > >A new version of I-D, draft-briscoe-conex-initial-deploy-01.txt has >been successfully submitted by Bob Briscoe and posted to the IETF repository. > >Filename: draft-briscoe-conex-initial-deploy >Revision: 01 >Title: Initial Congestion Exposure (ConEx) Deployment Examples >Creation date: 2011-11-24 >WG ID: Individual Submission >Number of pages: 10 > >Abstract: > This document gives examples of how ConEx deployment might get > started, focusing on unilateral deployment by a single network. > > > > > >The IETF Secretariat ________________________________________________________________ Bob Briscoe, BT Innovate & Design