From toby@moncaster.com Tue Mar 1 01:57:43 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 051B93A63C9 for ; Tue, 1 Mar 2011 01:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.268 X-Spam-Level: X-Spam-Status: No, score=-1.268 tagged_above=-999 required=5 tests=[AWL=-0.859, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2Yd1htrlsUu for ; Tue, 1 Mar 2011 01:57:41 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id 7E66F3A6359 for ; Tue, 1 Mar 2011 01:57:40 -0800 (PST) Received: from TobysHP (host81-158-50-164.range81-158.btcentralplus.com [81.158.50.164]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0LtS7s-1Q1tMD3LJE-010zZ0; Tue, 01 Mar 2011 10:58:42 +0100 From: "Toby Moncaster" To: "'Mcdysan, David E'" , "'Alissa Cooper'" References: <001201cbd5b3$b5114020$1f33c060$@com> In-Reply-To: Date: Tue, 1 Mar 2011 09:58:42 -0000 Message-ID: <001201cbd7f7$3f635700$be2a0500$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcvXsU/O9juFVWO4THy4DON1o/yR+QARODiQ Content-Language: en-gb X-Provags-ID: V02:K0:rr0LvT97AJPCIpeKC4DhQmkOqJwcPT9IrK2PRlb7l9+ RrFhkpwZ8UpBOKG/sH33x5VMj0atZG4LgMJxX6UV4EBbC+bshs AKlZYuRaCxvS+3xRTD8P409N0rSZaJI4F1v8BTSno+S42Q2+Z7 yNGwjKTiYPAzwKc2DP7L/ZciLclDd/Er39iN1QNKzsxQbN9F+f TdCOgvn2uEfxs3GOV6b0knYl5btDgVLiW8u+MlLua4= Cc: conex@ietf.org Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 09:57:43 -0000 Hi Dave, inline > -----Original Message----- > From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com] > Sent: 01 March 2011 01:38 > To: Toby Moncaster; 'Alissa Cooper' > Cc: conex@ietf.org > Subject: Re: [conex] Discussion of new Use Cases pt 1 > > Hi Toby, > > A few responses in line below. > > Thanks, > > Dave > > On 2/26/11 7:50 AM, "Toby Moncaster" wrote: > > > > > > >> -----Original Message----- > >> From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On > Behalf > >> Of Alissa Cooper > >> Sent: 26 February 2011 12:21 > >> To: Mcdysan, David E > >> Cc: conex@ietf.org > >> Subject: Re: [conex] Discussion of new Use Cases pt 1 > >> > >> Hi Dave, > >> > >> Couple of questions inline... > >> > >> On Feb 25, 2011, at 2:17 PM, Mcdysan, David E wrote: > >> > The proposed measure from the text that Toby sent from my draft > for > >> > this > >> > use case is that of burstiness (I.e., peak/average) where the > >> > incentive > >> > peak is the"flat rate" or "bandwidth tier" purchased. > >> > ... > >> > > >> > Let me illustrate by an example. If conex could send longer-term > user > >> > burstiness to the congested shared resource, then a mechanism (to > be > >> > described in the mechanism draft) at that point could > >> > drop more traffic from class B non-bursty users so that bandwidth > >> > tends > >> > to equalize between the two user classes > >> > Implement a bandwidth tier AND burst duration pricing scheme, with > >> > appropriate mechanisms to provide a burst duration longer than the > >> > shapers > >> > widely used today > >> > > >> > >> It seems to me that there are two different approaches being taken > to > >> what is or is not in scope for both the use cases and the mechanism > >> definition: > >> > >> Approach #1: > >> a. Assume that the CONEX mechanism will be used exclusively to > signal > >> the amount of congestion encountered by previous packets on the same > >> flow > >> b. Document the different uses to which that signal could be put > >> (traffic management, incentivizing scavenger services, etc.) in the > >> use cases draft > >> c. Document how the signal is set in the mechanism draft > > > >This is certainly the approach in draft-ietf-conex-concepts-uses and > the > >co-authors of that document assumed this was what the charter was > looking > >for. > > See my response to Allison and the meeting minutes from IETF 79 and > IETF > 78. I will wait to see if Alissa replies or not > > > > >> > >> Approach #2: > >> a. Assume that the metric that CONEX will signal is open for > >> discussion, or that the mechanism may signal multiple different > metrics > >> b. Document use cases for a variety of different potential metrics > in > >> the use cases draft (congestion encountered previously on same flow, > >> long-term user burstiness as you describe above, possibly others) > >> c. Document how network nodes could respond to CONEX signals to > >> effectuate particular outcomes (dropping more traffic from non- > bursty > >> users as you describe above) > > > >The potential problem with this approach is that there is no end to > the > >possible metrics that we could explore. In theory we are meant to be > >submitting the Use Cases document by March this year! So we do need to > be > >sensible about what is in and out of scope. > > > >> > >> It seems as though you are taking approach #2 whereas others may be > >> taking approach #1, and these two approaches probably need to be > >> reconciled. I don't see how the same mechanism can signal both > >> congestion previously experienced on the path and peak/average > sending > >> rate (although I'm happy for you or someone else to explain how it > can > >> be done). If it can't be done, then it seems like we are talking > about > >> signaling two different metrics. > > > >I certainly favour approach 1, and this seems to better match with our > >charter. On the other hand there is potential for looking at broader > >definitions of congestion within the use cases document. One of the > big > >issues facing the WG is defining congestion in a sensible fashion. > > > >I agree that Dave's peak/average rate signal doesn't seem to fit into > the > >same sort of signalling framework. For one thing Dave seems to just > imply > >this would be a binary state. > > > I.m not sure I understand this comment. Could you please expand on what > are the states. If I understood you correctly, you were suggesting that users would be classified as "heavy" or "not heavy", with their traffic marked appropriately? > > >However I think it may be possible to derive > >something that gives the same information as Dave is looking for > without > >needing an additional explicit signal. > > This is a good example of how I would see the use case and mechanism > drafts inter-relating. If the same mechanism signaling can be used to > meet > other use cases, then IMHO then this makes the abstract mechanism more > attractive. However, if the use case cannot be (well) handled by the > abstract mechanism, then that is also useful information. I agree it would be good to have some idea of how broad the applicability of the abstract mechanism is. I actually think that there is very little real disagreement between what we are both saying. The only significant difference seems to be you are suggesting an explicit measure of long-term "heaviness" of use, whereas I feel that such a measure can be derived from the short term congestion measure. > > > > >> > >> If we are focused on a single metric, then I think we need to > document > >> use cases for that metric. If there are multiple metrics, we should > be > >> clear about which use cases make use of which metric. And in either > >> case, I thought the point of the mechanism draft was to explain how > >> the chosen metric is measured so that it can be encoded at the IP > >> layer. > > > >I favour concentrating on a single metric relating as closely as > possible > >to > >"real" congestion. But Dave does have a very valid point - for > whatever > >reason, many ISPs use a shaper to rate limit traffic to/from their > >customers. I would argue that at peak times this is probably not the > >limiting factor, but off-peak it will be the biggest source of > apparent > >loss/congestion. > > And as I tried to describe in my Beijing draft, in certain growth and > restoration scenarios off-peak is the majority of elapsed network > equipment deployment time. I will go back to your draft to see if I can understand this a bit better. Out of interest, do you have a good feel for how things differ between DOCSIS and xDSL systems? I know that in xDSL there is also shaping at the BRAS (or DSLAM) to make sure the downlink to the end user is not overloaded. > > > > >One interesting thought experiment - what if, instead of a shaper, the > ISP > >introduces a congestion marking system. Then it can rate limit traffic > by > >marking it before the traffic needs to be disrupted. The only problem > then > >is how to deal with non-responsive traffic. > > This idea is not complete, but I think it is in the direction I > mentioned > above of having a description of how one mechanism could be used in a > different way to meet the needs of a use case. The idea is very far from complete! I wanted to try and get people thinking about how adaptable the ConEx approach might be... As I say, our views on this are not all that different in practise. Toby > > > > >Toby > > > >> > >> Alissa > >> > >> > > >> > Thanks, > >> > > >> > Dave > >> > > >> > > >> > On 2/24/11 5:11 PM, "John Leslie" wrote: > >> > > >> >> STUART VENTERS wrote: > >> >>> > >> >>> Let me make sure I understand this use case and it's desired > >> >>> outcome: > >> >>> > >> >>> Consider 2 users A, and B. > >> >>> A sends at a low rate all the time. > >> >>> B sends only a congestion causing bunch during busy times. > >> >>> A sends many more bytes per month than B > >> >>> > >> >>> Which is the 'heavy' user (I think B)? > >> >> > >> >> I don't think we should assume that... > >> >> > >> >>> Are we looking for a way for service providers to determine > >> >>> 'equitable' > >> >>> costs for these behaviors, or a way to make the system > forwarding > >> >>> behavior for these two load is somehow 'equitable'? > >> >> > >> >> To some degree, Dave has to speak for himself, but IMHO this > issue > >> >> is > >> >> about being able (under ConEx) to better inform a provider's > >> >> decision. > >> >> I'm nearly positive Dave doesn't mean for us to argue what > balance > >> >> between > >> >> these two is "equitable". > >> >> > >> >> At first blush, it would seem "B" should "expect" congestion > >> losses, > >> >> while "A" might not. Current non-ConEx methods tend to punish "A" > >> >> more > >> >> than "B"; and I do suspect Dave is suggesting a different balance > >> >> might > >> >> be appropriate. > >> >> > >> >> Nonetheless, IMHO "A" should expect congestion losses to > increase > >> >> during periods of heavy use -- unless s/he buys better-than the > >> >> vanilla > >> >> best-effort service. > >> >> > >> >> -- > >> >> John Leslie > >> >> _______________________________________________ > >> >> conex mailing list > >> >> conex@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/conex > >> > > >> > _______________________________________________ > >> > conex mailing list > >> > conex@ietf.org > >> > https://www.ietf.org/mailman/listinfo/conex > >> > > >> > >> > >> _______________________________________________ > >> conex mailing list > >> conex@ietf.org > >> https://www.ietf.org/mailman/listinfo/conex > > From toby@moncaster.com Tue Mar 1 02:07:15 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC9123A6407 for ; Tue, 1 Mar 2011 02:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wi+Q4Ybg3+fZ for ; Tue, 1 Mar 2011 02:07:14 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id 5D0913A6405 for ; Tue, 1 Mar 2011 02:07:14 -0800 (PST) Received: from TobysHP (host81-158-50-164.range81-158.btcentralplus.com [81.158.50.164]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0LsMjU-1Q0nXb07S4-0126Lr; Tue, 01 Mar 2011 11:08:15 +0100 From: "Toby Moncaster" To: "'Mcdysan, David E'" , "'John Leslie'" References: <20110226145616.GH7663@verdi> In-Reply-To: Date: Tue, 1 Mar 2011 10:08:15 -0000 Message-ID: <001301cbd7f8$9540e330$bfc2a990$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcvXtVNtgiHSiJT/RiCBItMCFNFzjAAQiDkQ Content-Language: en-gb X-Provags-ID: V02:K0:gvZBQ7KG0vrWIGn16cat/golN4EXHBzu/dw2iMPF1vI yMdqMGde+YyW3GOokmFXEKMexlftFIZ88KghzlN4U5ZOnb4kMQ WSAEdvX/3B5HsGM0Jr57am+KtyIG0wezDYuN8KaI3xPGMY5PMK s393d/OQj4u/E4LWT+73OkjCO87iP8i1CtRZi2xU4sd3/Y+xdw HHRF2V+kV2pKQ/7aEJrAiHHJnBqx591JhNQ9j5pMe4= Cc: conex@ietf.org Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 10:07:15 -0000 3 comments inline > -----Original Message----- > From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com] > Sent: 01 March 2011 02:07 > To: John Leslie; Toby Moncaster > Cc: 'Alissa Cooper'; conex@ietf.org > Subject: Re: [conex] Discussion of new Use Cases pt 1 > > Hi John, > > Some responses in line below. > > Dave > > On 2/26/11 9:56 AM, "John Leslie" wrote: > > >Toby Moncaster wrote: > >> To: "'Alissa Cooper'" , > >> > >>> It seems to me that there are two different approaches being taken > to > >>> what is or is not in scope for both the use cases and the mechanism > >>> definition: > >>> > >>> Approach #1: > >>> a. Assume that the CONEX mechanism will be used exclusively to > signal > >>> the amount of congestion encountered by previous packets on the > same > >>> flow > >>> b. Document the different uses to which that signal could be put > >>> (traffic management, incentivizing scavenger services, etc.) in the > >>> use cases draft > >>> c. Document how the signal is set in the mechanism draft > >> > >> This is certainly the approach in draft-ietf-conex-concepts-uses and > the > >> co-authors of that document assumed this was what the charter was > >>looking > >> for. > > > > Agreed. > > > >>> Approach #2: > >>> a. Assume that the metric that CONEX will signal is open for > >>> discussion, or that the mechanism may signal multiple different > metrics > >>> b. Document use cases for a variety of different potential metrics > in > >>> the use cases draft (congestion encountered previously on same > flow, > >>> long-term user burstiness as you describe above, possibly others) > >>> c. Document how network nodes could respond to CONEX signals to > >>> effectuate particular outcomes (dropping more traffic from non- > bursty > >>> users as you describe above) > >> > >> The potential problem with this approach is that there is no end to > the > >> possible metrics that we could explore. In theory we are meant to be > >> submitting the Use Cases document by March this year! So we do need > to > >> be sensible about what is in and out of scope. > > > > While I believe there's still some room for discussion what we mean > >by "congestion", I don't believe there's any room (left) for > discussion > >that we mean to record anything other than congestion expected during > >transit of the packet in question (with some wiggle room for quantized > >encoding a-la ECN). There just aren't enough bits. > > > > ConEx-aware boxes along the way are _very_ likely to aggregate our > >ConEx markings, over time and/or over flows. A use-cases document can > >discuss such things, whereas a mechanism document is probably more > >limited. > > Good point. I think this is the general direction that Marcello may > have > had in mind when he commented during my presentation in Beijing. Not > sure > what Marcello, Rich or Bob had in mind here as discussed in the meeting > minutes. I suggest that we need to work toward some proposed text for > the > wg use case draft that describes this. All offers of text gratefully received ;) > > > > > >>> It seems as though you are taking approach #2 whereas others may be > >>> taking approach #1, and these two approaches probably need to be > >>> reconciled. I don't see how the same mechanism can signal both > >>> congestion previously experienced on the path and peak/average > >>> sending rate (although I'm happy for you or someone else to explain > >>> how it can be done). If it can't be done, then it seems like we are > >>> talking about signaling two different metrics. > > > > IMHO, discussion of a use-cases document has some leeway here -- > >not in what the metric will signal, but in what may be done based on > >aggregations of that metric. I do not believe Dave McDysan has > exceeded > >that leeway -- though discussing use-cases in the absence of an agreed > >metric _does_ tend to lead to confusion... > > > >> I certainly favour approach 1, and this seems to better match with > our > >> charter. On the other hand there is potential for looking at broader > >> definitions of congestion within the use cases document. One of the > >> big issues facing the WG is defining congestion in a sensible > fashion. > > > > Clearly, we do have to produce a use-cases document, though I would > >prefer that at least an "abstract mechanism" could be agreed to as a > >basis for it. > > Not sure I understand what you are proposing. The wg decided to take > mechanism largely out of the use case draft in IETF 78, and in IETF 79 > the > exclusion of a use case that did not match the adopted abstract > mechanism > was explicitly agreed (see meeting minutes snippet in my response to > Allison). > > > > I tend to take a long-term view which says whatever we settle on > for > >a mechanism should allow for future extensions. (Thus I am very much > >at home with desires for different ways to measure "congestion".) > > > >>> If we are focused on a single metric, then I think we need to > document > >>> use cases for that metric. If there are multiple metrics, we should > be > >>> clear about which use cases make use of which metric. And in either > >>> case, I thought the point of the mechanism draft was to explain how > >>> the chosen metric is measured so that it can be encoded at the IP > >>> layer. > > > > I am hesitant to go the path of labeling use-cases according to > what > >metric best serves them. IMHO, our use-cases document should only > include > >things achievable with a particular metric, which I have been assuming > >to be congestion-expected-during-transit. > > Metric is mentioned once in the use case document in section 3 in the > context of existing approaches. Are you referring to the measures in > definitions of use cases, or something in the abstract mechanism draft? > (where the term metric is not used at all) I (more or less deliberately) avoided using the word "metric" in the use cases document. The main reason being that it may confuse people that are not used to thinking of congestion as something with a measurable value (after all TCP assumes congestion exists or it doesn't). In this discussion, metric is being used as short-hand for "the means by which we establish how much congestion a given packet/flow/user expects to create" > > > > > I do spend time thinking about "concrete" mechanisms, but I'm not > sure > >it would help to discuss them now. Certainly such discussion doesn't > >belong in this thread. > > > >> I favour concentrating on a single metric relating as closely as > >>possible > >> to "real" congestion. But Dave does have a very valid point - for > >> whatever reason, many ISPs use a shaper to rate limit traffic > to/from > >> their customers. I would argue that at peak times this is probably > not > >> the limiting factor, but off-peak it will be the biggest source of > >> apparent loss/congestion. > > > > Certainly, ConEx will need to operate in an environment where such > >"shaping" occurs. I am considerably less sure how (if at all) it > should > >be discussed in a use-cases document. > > > I asked this question in IETF 78 of Bob regarding a non-work conserving > scheduler (e.g., shaper), which can experiences the congestion measure > as > defined in the current use case draft. > > At a minimum I think the statement in the first paragraph of section 4 > that describes what I called "inter-user congestion" as "---- > congestion > means that your traffic impacts other users, and conversely that their > traffic impacts you." needs to exclude the use case of what I called > "self-congestion" needs to address the use case employed by many ISPs > (as > Toby points out). There is an interesting related discussion here - where a user is policed because of the level of congestion they have caused, do they then have to "declare" the policing losses as expecting a higher level of congestion? Going back to your point, you really need to address this with Bob. I think that there is a difference between what might be deemed "self-congestion" which has no impact on other users, and "cross congestion" where your traffic is actually impacting on others, and hence creates a cost for them. It is this latter form of congestion that allows people like Frank Kelly to apply micro-economics to this problem Toby > > >To me, it is "congestion" even if > >it is not resource-congestion. Congestion-expected markings could > better > >inform decisions about "shaping". The issues about whether ConEx > marking > >is considered at any point of congestion are much the same... > > I didn't follow this. Could you please elaborate. > > > > >> One interesting thought experiment - what if, instead of a shaper, > the > >> ISP introduces a congestion marking system. Then it can rate limit > >> traffic by marking it before the traffic needs to be disrupted. The > >> only problem then is how to deal with non-responsive traffic. > > > > That undoubtedly deserves its own thread! > > > >-- > >John Leslie From acooper@cdt.org Tue Mar 1 02:14:37 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 162663A65A5 for ; Tue, 1 Mar 2011 02:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plxKQZxPBJ+N for ; Tue, 1 Mar 2011 02:14:35 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id 7FBA23A6359 for ; Tue, 1 Mar 2011 02:14:35 -0800 (PST) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Tue, 1 Mar 2011 05:15:23 -0500 Message-Id: <64069EFF-C572-4088-9EF0-9CDE66B20390@cdt.org> From: Alissa Cooper To: "Mcdysan, David E" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 1 Mar 2011 10:15:21 +0000 References: X-Mailer: Apple Mail (2.936) Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 10:14:37 -0000 Dave, I don't have strong feelings about Approach 1 vs. Approach 2. I just think when we discuss existing or new use cases, we need to be clear about what metric (or whatever word people want to use instead of "metric") they are based on and whether those metrics all measure the same thing, whether they can be derived from each other, or whether they measure different things. Otherwise it becomes unclear what a use case is "using." I sensed some confusion about this at IETF 79 and was sensing it again on the list. But if it's just my confusion, we can ignore it and move on. Alissa On Mar 1, 2011, at 1:30 AM, Mcdysan, David E wrote: > Hi Alissa, > > Some responses in line below. > > Thanks, > > Dave > > On 2/26/11 7:21 AM, "Alissa Cooper" wrote: > >> Hi Dave, >> >> Couple of questions inline... >> >> On Feb 25, 2011, at 2:17 PM, Mcdysan, David E wrote: >>> The proposed measure from the text that Toby sent from my draft for >>> this >>> use case is that of burstiness (I.e., peak/average) where the >>> incentive >>> peak is the"flat rate" or "bandwidth tier" purchased. >>> ... >>> >>> Let me illustrate by an example. If conex could send longer-term >>> user >>> burstiness to the congested shared resource, then a mechanism (to be >>> described in the mechanism draft) at that point could >>> drop more traffic from class B non-bursty users so that bandwidth >>> tends >>> to equalize between the two user classes >>> Implement a bandwidth tier AND burst duration pricing scheme, with >>> appropriate mechanisms to provide a burst duration longer than the >>> shapers >>> widely used today >>> >> >> It seems to me that there are two different approaches being taken to >> what is or is not in scope for both the use cases and the mechanism >> definition: >> >> Approach #1: >> a. Assume that the CONEX mechanism will be used exclusively to signal >> the amount of congestion encountered by previous packets on the same >> flow >> b. Document the different uses to which that signal could be put >> (traffic management, incentivizing scavenger services, etc.) in the >> use cases draft >> c. Document how the signal is set in the mechanism draft >> >> Approach #2: >> a. Assume that the metric that CONEX will signal is open for >> discussion, or that the mechanism may signal multiple different >> metrics >> b. Document use cases for a variety of different potential metrics in >> the use cases draft (congestion encountered previously on same flow, >> long-term user burstiness as you describe above, possibly others) >> c. Document how network nodes could respond to CONEX signals to >> effectuate particular outcomes (dropping more traffic from non-bursty >> users as you describe above) >> >> It seems as though you are taking approach #2 whereas others may be >> taking approach #1, and these two approaches probably need to be >> reconciled. I don't see how the same mechanism can signal both >> congestion previously experienced on the path and peak/average >> sending >> rate (although I'm happy for you or someone else to explain how it >> can >> be done). If it can't be done, then it seems like we are talking >> about >> signaling two different metrics. >> >> If we are focused on a single metric, then I think we need to >> document >> use cases for that metric. If there are multiple metrics, we should >> be >> clear about which use cases make use of which metric. And in either >> case, I thought the point of the mechanism draft was to explain how >> the chosen metric is measured so that it can be encoded at the IP >> layer. >> >> Alissa > > Quoting from the IETF 70 meeting minutes > > "ConEx Concepts and Abstract Mechanism > draft-mathis-conex-abstract-mech-00 " > > > Snipped > " MB - not asking about sending to IESG, just asking about adoption > - do > people have comments? > > Dave McDysan (DM) - charter related question - first result > is > usage > scenarios document - other docs will not see publication > until > that is > done - have already had questions on list about additional > use > cases. > if we adopt this as the mechanism document then we foreclose > use-case > discussion. there are use cases being elaborated that aren't > supported > by the mechanism, so we could be going round in circles here. > > MB - are you envisioning additional use cases that could > not be > satisfied > by this mechanism? > > DM - yes > > MB - is this a little different or a lot? > > DM - could be a lot different. this is a good approach for > short > timescales, but could do something longer term, slow path. > > MB - so you would like to agree use cases? > > Leslie Daigle (LD) - i would like to support adopting > mechanism > document. > just don't use it as a blunt instrument to bludgeon people > proposing new > use cases. > > MB - would that work for DM? > > DM - yes, if that decision can be documented. > > MB - yes, it will be documented, I will remember." > > > > I interpreted the above as something like Approach 2 was acceptable > -- a > use case did not need to align with the currently documented abstract > mechanism. If others have a different interpretation, please respond > to > the list. > > Also, the way the prior version of the use case draft was written was > closely tied to the (re-ECN) mechanism (Approach 1) and the > agreement from > the IETF 78 meeting minutes was to separate these. I provided a > detailed > set of comments toward this end. > >> >>> >>> Thanks, >>> >>> Dave >>> >>> >>> On 2/24/11 5:11 PM, "John Leslie" wrote: >>> >>>> STUART VENTERS wrote: >>>>> >>>>> Let me make sure I understand this use case and it's desired >>>>> outcome: >>>>> >>>>> Consider 2 users A, and B. >>>>> A sends at a low rate all the time. >>>>> B sends only a congestion causing bunch during busy times. >>>>> A sends many more bytes per month than B >>>>> >>>>> Which is the 'heavy' user (I think B)? >>>> >>>> I don't think we should assume that... >>>> >>>>> Are we looking for a way for service providers to determine >>>>> 'equitable' >>>>> costs for these behaviors, or a way to make the system forwarding >>>>> behavior for these two load is somehow 'equitable'? >>>> >>>> To some degree, Dave has to speak for himself, but IMHO this issue >>>> is >>>> about being able (under ConEx) to better inform a provider's >>>> decision. >>>> I'm nearly positive Dave doesn't mean for us to argue what balance >>>> between >>>> these two is "equitable". >>>> >>>> At first blush, it would seem "B" should "expect" congestion >>>> losses, >>>> while "A" might not. Current non-ConEx methods tend to punish "A" >>>> more >>>> than "B"; and I do suspect Dave is suggesting a different balance >>>> might >>>> be appropriate. >>>> >>>> Nonetheless, IMHO "A" should expect congestion losses to increase >>>> during periods of heavy use -- unless s/he buys better-than the >>>> vanilla >>>> best-effort service. >>>> >>>> -- >>>> John Leslie >>>> _______________________________________________ >>>> conex mailing list >>>> conex@ietf.org >>>> https://www.ietf.org/mailman/listinfo/conex >>> >>> _______________________________________________ >>> conex mailing list >>> conex@ietf.org >>> https://www.ietf.org/mailman/listinfo/conex >>> >> > > From stuart.venters@adtran.com Tue Mar 1 08:55:55 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 523BC3A6989 for ; Tue, 1 Mar 2011 08:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.473 X-Spam-Level: X-Spam-Status: No, score=-6.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUOFHA8LCjV7 for ; Tue, 1 Mar 2011 08:55:54 -0800 (PST) Received: from p02c11o147.mxlogic.net (p02c11o147.mxlogic.net [208.65.144.80]) by core3.amsl.com (Postfix) with ESMTP id 0026A3A687C for ; Tue, 1 Mar 2011 08:55:53 -0800 (PST) Received: from unknown [76.164.174.82] by p02c11o147.mxlogic.net(mxl_mta-6.9.0-1) with SMTP id 9552d6d4.0.5901.00-240.15225.p02c11o147.mxlogic.net (envelope-from ); Tue, 01 Mar 2011 09:56:57 -0700 (MST) X-MXL-Hash: 4d6d25597c217194-431577481fb3e05c53f18496acdcc59238fceb63 Received: from corp-exfr1.corp.adtran.com (172.23.101.21) by ex-hc3.corp.adtran.com (172.22.50.73) with Microsoft SMTP Server id 14.1.270.1; Tue, 1 Mar 2011 10:56:47 -0600 Received: from EXV1.corp.adtran.com ([172.22.48.215]) by corp-exfr1.corp.adtran.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Mar 2011 10:56:48 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Mar 2011 10:56:47 -0600 Message-ID: <8F242B230AD6474C8E7815DE0B4982D7179FB92C@EXV1.corp.adtran.com> In-Reply-To: <64069EFF-C572-4088-9EF0-9CDE66B20390@cdt.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] Discussion of new Use Cases pt 1 Thread-Index: AcvX+Zhil4HXWlRQRq2GdzBRzypktwAL2phQ From: STUART VENTERS To: X-OriginalArrivalTime: 01 Mar 2011 16:56:48.0059 (UTC) FILETIME=[A73708B0:01CBD831] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [(unknown)] X-AnalysisOut: [v=1.0 c=1 a=G9T4uwCCN8UA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-] X-AnalysisOut: [IA:10 a=J+LXdEUA8t8MtBPt16/Qbg==:17 a=JjV8spf7YstJfTUnOQIA] X-AnalysisOut: [:9 a=LehdvgYvZ3A2_atxJ7AZluAc6D4A:4 a=wPNLvfGTeEIA:10] Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 16:55:55 -0000 All, After thinking about Allissa and Dave's discussion, here's my 2c for a = CONEX congestion definition: Definition for the kind of congestion that CONEX is trying to expose in = a statistically multiplexed routing cloud: Congestion is when a packet's forwarding behavior is adversely affected = because of the traffic load caused by other packets in the cloud. 'Adversely affected' means dropped or delayed more than the minimum = delay seen in an otherwise idle cloud. 'Other packets' means either packets from other users or packets from = the same user. When a packet gets affected simply because a shaper or policer says that = a specific flow or user is sending more bits that the traffic contract = allows,=20 that doesn't feel like congestion, but rather traffic management. On the other hand, if the shaper were affecting packets because it sees = the cloud is near or at congestion, then that effect feels like = congestion. (Because traffic management is telling the user that there is, or = soon will be congestion.) The definition is focused on the discussion, so I may have completely = missed some other aspect of congestion? Under this definition, it might turn out that CONEX needs to expose both = traffic management and congestion behaviors. I don't yet see the need for this, but could easily be persuaded by a = use case. It would just be unfortunate if we had to muddy the definitions for = the two in order to include the TM behaviors. Cheers, Stuart From john@jlc.net Tue Mar 1 08:58:00 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B5403A6999 for ; Tue, 1 Mar 2011 08:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.686 X-Spam-Level: X-Spam-Status: No, score=-106.686 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0nsHRMX4N9I for ; Tue, 1 Mar 2011 08:57:59 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 815863A6989 for ; Tue, 1 Mar 2011 08:57:59 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 104DC33C2C; Tue, 1 Mar 2011 11:59:03 -0500 (EST) Date: Tue, 1 Mar 2011 11:59:03 -0500 From: John Leslie To: Toby Moncaster Message-ID: <20110301165902.GN7663@verdi> References: <20110226145616.GH7663@verdi> <001301cbd7f8$9540e330$bfc2a990$@com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001301cbd7f8$9540e330$bfc2a990$@com> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: [conex] "Metric" X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 16:58:00 -0000 Toby Moncaster wrote: > [ wrote:] >> [John Leslie wrote:] >> >> > >>> I am hesitant to go the path of labeling use-cases according to >>> what metric best serves them. IMHO, our use-cases document should >>> only include things achievable with a particular metric, which I >>> have been assuming to be congestion-expected-during-transit. (My apologies for hand-waving here: I'll get back to what I meant.) >> Metric is mentioned once in the use case document in section 3 in the >> context of existing approaches. Are you referring to the measures in >> definitions of use cases, or something in the abstract mechanism >> draft? (where the term metric is not used at all) > > I (more or less deliberately) avoided using the word "metric" in the > use cases document. The main reason being that it may confuse people > that are not used to thinking of congestion as something with a > measurable value (after all TCP assumes congestion exists or it > doesn't). > > In this discussion, metric is being used as short-hand for "the means > by which we establish how much congestion a given packet/flow/user > expects to create" (Toby is hand-waving here... ;^) I realize we're not conveying the right idea when we use the word "metric". First, let me explain what I have meant (and I was assuming the other authors meant). The dictionary-definition I try to fit under is: " " 2. a standard of measurement... by which I mean "a set of rules which allows different observers to generally report the same number when they set out to measure the same observable". (Whether that "number" is binary, integer, or real should be derivable from the rules.) I have been using the word "metric" because I don't believe we have any consensus what "rules" apply. Some of us are very strict adherents to the rules of ECN; others think ECN is all wet; et cetera... The hope is that we can (later) agree on one or more actual "metrics" (sets of rules) for a packet being forwarded from source to destination; and that we can concentrate our effort (for now) on how to carry the result of that measurement through the ConEx process: back to the sender and through the forwarding process for a future packet. (Getting back to my earlier hand-waving: the unstated assumption is that the receiver of a packet will decode a number according to a rule for "congestion experienced by a packed during transit", report that number back to the sender, and the sender will encode a corresponding number into future packet(s) it sends, intending it to convey its prediction of "congestion-experienced-during-transit".) I've taken some time before replying, trying to come up with a term to substitute for "metric" which will still allow us to gloss over the issue of how we measure "congestion" -- and (for now, at least) given up. I'd be delighted to hear suggestions from other participants (or even lurkers)... -- John Leslie From toby@moncaster.com Tue Mar 1 09:16:30 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E13C3A69F5 for ; Tue, 1 Mar 2011 09:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yl-vGJy0a+-x for ; Tue, 1 Mar 2011 09:16:29 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id 675883A69FD for ; Tue, 1 Mar 2011 09:16:29 -0800 (PST) Received: from TobysHP (host81-158-50-164.range81-158.btcentralplus.com [81.158.50.164]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0Lfpnu-1QNjCi0YTi-00pIsN; Tue, 01 Mar 2011 18:17:31 +0100 From: "Toby Moncaster" To: "'John Leslie'" References: <20110226145616.GH7663@verdi> <001301cbd7f8$9540e330$bfc2a990$@com> <20110301165902.GN7663@verdi> In-Reply-To: <20110301165902.GN7663@verdi> Date: Tue, 1 Mar 2011 17:17:31 -0000 Message-ID: <003d01cbd834$8d463a40$a7d2aec0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcvYMfg9IVyd5ghISQ2476MQEEV46wAAfdxQ Content-Language: en-gb X-Provags-ID: V02:K0:odrTZGCUx58P7GoT/RXzgJRpnxoA+PGkF8O60HISVT4 kVWxz8mY9DKNsf3U3pbT3cpiP+9+jsVKgbAgGBPaZ0d2VR/7tR VCALUwnMDxoC0ryxJP6a7RYVAeEDDK+TDtMlqEbnNsV6XREyOA IbvgSNziOjkXWOD0ZAt8xxR032CB9HmxKfp+t/geilbt1rBjCx y6xSab9m9dG34ecPqKnAyNhWslavljwmXCePeqTeuw= Cc: conex@ietf.org Subject: Re: [conex] "Metric" X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 17:16:30 -0000 (NB I haven't yet properly parsed John's reply). Surely what it boils down to is we need to define the "congestion" that will be exposed by "congestion exposure"! And yes, lurkers are very welcome to join in this discussion - it is important we reach some sort of consensus here (not on the use of the word "metric", but on what the word is applied to). Oh, and a (not serious) suggested alternative word: "quantifier"... Toby > -----Original Message----- > From: John Leslie [mailto:john@jlc.net] > Sent: 01 March 2011 16:59 > To: Toby Moncaster > Cc: 'Mcdysan, David E'; 'Alissa Cooper'; conex@ietf.org > Subject: "Metric" > > Toby Moncaster wrote: > > [ wrote:] > >> [John Leslie wrote:] > >> > >> > > >>> I am hesitant to go the path of labeling use-cases according to > >>> what metric best serves them. IMHO, our use-cases document should > >>> only include things achievable with a particular metric, which I > >>> have been assuming to be congestion-expected-during-transit. > > (My apologies for hand-waving here: I'll get back to what I meant.) > > >> Metric is mentioned once in the use case document in section 3 in > the > >> context of existing approaches. Are you referring to the measures in > >> definitions of use cases, or something in the abstract mechanism > >> draft? (where the term metric is not used at all) > > > > I (more or less deliberately) avoided using the word "metric" in the > > use cases document. The main reason being that it may confuse people > > that are not used to thinking of congestion as something with a > > measurable value (after all TCP assumes congestion exists or it > > doesn't). > > > > In this discussion, metric is being used as short-hand for "the means > > by which we establish how much congestion a given packet/flow/user > > expects to create" > > (Toby is hand-waving here... ;^) > > I realize we're not conveying the right idea when we use the word > "metric". First, let me explain what I have meant (and I was assuming > the other authors meant). > > The dictionary-definition I try to fit under is: > " > " 2. a standard of measurement... > > by which I mean "a set of rules which allows different observers to > generally report the same number when they set out to measure the > same observable". > > (Whether that "number" is binary, integer, or real should be > derivable > from the rules.) > > I have been using the word "metric" because I don't believe we have > any consensus what "rules" apply. Some of us are very strict adherents > to the rules of ECN; others think ECN is all wet; et cetera... > > The hope is that we can (later) agree on one or more actual > "metrics" > (sets of rules) for a packet being forwarded from source to > destination; > and that we can concentrate our effort (for now) on how to carry the > result of that measurement through the ConEx process: back to the > sender > and through the forwarding process for a future packet. > > (Getting back to my earlier hand-waving: the unstated assumption is > that the receiver of a packet will decode a number according to a rule > for "congestion experienced by a packed during transit", report that > number back to the sender, and the sender will encode a corresponding > number into future packet(s) it sends, intending it to convey its > prediction of "congestion-experienced-during-transit".) > > I've taken some time before replying, trying to come up with a term > to substitute for "metric" which will still allow us to gloss over the > issue of how we measure "congestion" -- and (for now, at least) given > up. I'd be delighted to hear suggestions from other participants (or > even lurkers)... > > -- > John Leslie From bauer@mit.edu Tue Mar 1 09:28:59 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ACF53A6A01 for ; Tue, 1 Mar 2011 09:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PedcBNSCavn8 for ; Tue, 1 Mar 2011 09:28:56 -0800 (PST) Received: from outgoing.csail.mit.edu (outgoing.csail.mit.edu [128.30.2.149]) by core3.amsl.com (Postfix) with ESMTP id 9C16B3A69FC for ; Tue, 1 Mar 2011 09:28:55 -0800 (PST) Received: from mail-iw0-f172.google.com ([209.85.214.172]) by outgoing.csail.mit.edu with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.69) (envelope-from ) id 1PuTOY-0005zn-M7 for conex@ietf.org; Tue, 01 Mar 2011 12:29:58 -0500 Received: by iwl42 with SMTP id 42so4863872iwl.31 for ; Tue, 01 Mar 2011 09:29:58 -0800 (PST) Received: by 10.231.174.12 with SMTP id r12mr6577526ibz.155.1299000598178; Tue, 01 Mar 2011 09:29:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.206.203 with HTTP; Tue, 1 Mar 2011 09:29:27 -0800 (PST) In-Reply-To: <003d01cbd834$8d463a40$a7d2aec0$@com> References: <20110226145616.GH7663@verdi> <001301cbd7f8$9540e330$bfc2a990$@com> <20110301165902.GN7663@verdi> <003d01cbd834$8d463a40$a7d2aec0$@com> From: Steve Bauer Date: Tue, 1 Mar 2011 12:29:27 -0500 Message-ID: To: Toby Moncaster Content-Type: text/plain; charset=ISO-8859-1 Cc: conex@ietf.org Subject: Re: [conex] "Metric" X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 17:28:59 -0000 > And yes, lurkers are very welcome to join in this discussion - it is > important we reach some sort of consensus here (not on the use of the word > "metric", but on what the word is applied to). Awhile ago we wrote the following paper which may be relevant to inject at this point: The Evolution of Internet Congestion http://mitas.csail.mit.edu/papers/Bauer_Clark_Lehr_2009.pdf In particular see section 3, "Defining Congestion". Steve Bauer MIT From john@jlc.net Tue Mar 1 09:36:39 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EF253A6985 for ; Tue, 1 Mar 2011 09:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.681 X-Spam-Level: X-Spam-Status: No, score=-106.681 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VRHvqJf26oU for ; Tue, 1 Mar 2011 09:36:35 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 270A83A6A01 for ; Tue, 1 Mar 2011 09:36:35 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id AB98033C27; Tue, 1 Mar 2011 12:37:38 -0500 (EST) Date: Tue, 1 Mar 2011 12:37:38 -0500 From: John Leslie To: STUART VENTERS Message-ID: <20110301173738.GO7663@verdi> References: <64069EFF-C572-4088-9EF0-9CDE66B20390@cdt.org> <8F242B230AD6474C8E7815DE0B4982D7179FB92C@EXV1.corp.adtran.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8F242B230AD6474C8E7815DE0B4982D7179FB92C@EXV1.corp.adtran.com> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: [conex] "Congestion" definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 17:36:39 -0000 STUART VENTERS wrote: > > Definition for the kind of congestion that CONEX is trying to expose > in a statistically multiplexed routing cloud: > > Congestion is when a packet's forwarding behavior is adversely affected > because of the traffic load caused by other packets in the cloud. > - 'Adversely affected' means dropped or delayed more than the minimum > delay seen in an otherwise idle cloud. > - 'Other packets' means either packets from other users or packets from > the same user. This is a good start at discussing what we think we're talking about. So, let me take it as a start, rather than criticize its completeness. (I should perhaps criticize "Congestion is when", but let me reserve that issue for later.) There is indeed good work going on to derive a measure of "congestion" from transit-time, assuming that transit-time includes only minimum latency plus queueing delays. (There are obvious problems with that assumption, which I won't discuss.) Assuming we could actually collect useful queueing-delay numbers, it is quite reasonable to assume them to represent a type of "congestion". BTW, I have discussed defining "congestion" on the ICCRG list, starting Sat, 4 Feb 2006 16:03:28 -0500: ] ] To me, congestion is the condition where a packet can't be sent ] "immediately" (meaning perhaps that it can't be queued as the next ] packet to be sent). (I derive that from a dictionary definition of "congestion: to cause an excessive accumulation...") We could reasonably come up with a better definition of "immediately", but I contend that it would be different for every class of traffic, so I start from the most restrictive. But I digress... I don't believe time spent on arguing how much queueing corresponds to "zero" congestion is helpful. Regardless, we do hit a discontinuity when the queue "fills" and a packet is dropped; and many folks use "congestion" to refer to that discontinuity. ECN came along to moderate that discontinuity: instead of dropping the packet, we'd enforce Random-Early-Detection and at the tipping-point of RED we'd ECN-mark the packet instead of dropping it. Assuming well- behaved sender-receiver pairings this would reduce the need to drop packets more-quickly than TCP-like protocols could do by detecting a drop. ECN deployment is spotty-at-best -- possibly because nobody sees a reason to trust the sender-receiver pairings... Getting back to Stuart's definition: I think "caused by" is the wrong wording. Necessarily, it is the fact that packet-arrival-rate exceeds packet-forwarding-rate that "causes" queuing delays. It makes no sense to try to assign "blame" for this to individual senders -- except in the limiting case where a sender's packet-sending-rate exceeds the available-forwarding-rate of a particular forwarder; and for that limiting-case it's not useful to assign "blame" until the sender has had sufficient time to learn the available-forwarding-rate. Bottom line: a good start, Stuart! -- John Leslie From michawe@ifi.uio.no Tue Mar 1 10:06:44 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 338503A69FF for ; Tue, 1 Mar 2011 10:06:44 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6J11cakCED+j for ; Tue, 1 Mar 2011 10:06:43 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by core3.amsl.com (Postfix) with ESMTP id B3FD33A69E2 for ; Tue, 1 Mar 2011 10:06:42 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.72) (envelope-from ) id 1PuTz7-0006j4-Bp for conex@ietf.org; Tue, 01 Mar 2011 19:07:45 +0100 Received: from cm-84.208.175.27.getinternet.no ([84.208.175.27] helo=[192.168.0.199]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.72) (envelope-from ) id 1PuTz6-0008CO-Nh for conex@ietf.org; Tue, 01 Mar 2011 19:07:45 +0100 Message-Id: From: Michael Welzl To: conex@ietf.org In-Reply-To: <20110301173738.GO7663@verdi> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 1 Mar 2011 19:07:22 +0100 References: <64069EFF-C572-4088-9EF0-9CDE66B20390@cdt.org> <8F242B230AD6474C8E7815DE0B4982D7179FB92C@EXV1.corp.adtran.com> <20110301173738.GO7663@verdi> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 6 sum msgs/h 3 total rcpts 7114 max rcpts/h 36 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 5EB36B9918617ECD6E823912E947D39C5262983C X-UiO-SPAM-Test: remote_host: 84.208.175.27 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 570 max/h 13 blacklist 0 greylist 0 ratelimit 0 Subject: Re: [conex] "Congestion" definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 18:06:44 -0000 congestion definition, AGAIN? well, if you people think it's fun... :-) but check out some posts at: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2006-February/thread.html and the introduction of RFC 6077. On Mar 1, 2011, at 6:37 PM, John Leslie wrote: > STUART VENTERS wrote: >> >> Definition for the kind of congestion that CONEX is trying to expose >> in a statistically multiplexed routing cloud: >> >> Congestion is when a packet's forwarding behavior is adversely >> affected >> because of the traffic load caused by other packets in the cloud. >> - 'Adversely affected' means dropped or delayed more than the minimum >> delay seen in an otherwise idle cloud. >> - 'Other packets' means either packets from other users or packets >> from >> the same user. > > This is a good start at discussing what we think we're talking > about. > > So, let me take it as a start, rather than criticize its > completeness. > > (I should perhaps criticize "Congestion is when", but let me reserve > that issue for later.) > > There is indeed good work going on to derive a measure of > "congestion" > from transit-time, assuming that transit-time includes only minimum > latency plus queueing delays. (There are obvious problems with that > assumption, which I won't discuss.) > > Assuming we could actually collect useful queueing-delay numbers, it > is quite reasonable to assume them to represent a type of > "congestion". > > BTW, I have discussed defining "congestion" on the ICCRG list, > starting Sat, 4 Feb 2006 16:03:28 -0500: > ] > ] To me, congestion is the condition where a packet can't be sent > ] "immediately" (meaning perhaps that it can't be queued as the next > ] packet to be sent). > > (I derive that from a dictionary definition of "congestion: to > cause an excessive accumulation...") > > We could reasonably come up with a better definition of > "immediately", > but I contend that it would be different for every class of traffic, > so > I start from the most restrictive. > > But I digress... > > I don't believe time spent on arguing how much queueing corresponds > to "zero" congestion is helpful. > > Regardless, we do hit a discontinuity when the queue "fills" and a > packet is dropped; and many folks use "congestion" to refer to that > discontinuity. > > ECN came along to moderate that discontinuity: instead of dropping > the packet, we'd enforce Random-Early-Detection and at the tipping- > point > of RED we'd ECN-mark the packet instead of dropping it. Assuming well- > behaved sender-receiver pairings this would reduce the need to drop > packets more-quickly than TCP-like protocols could do by detecting a > drop. > > ECN deployment is spotty-at-best -- possibly because nobody sees a > reason to trust the sender-receiver pairings... > > Getting back to Stuart's definition: > > I think "caused by" is the wrong wording. Necessarily, it is the > fact that packet-arrival-rate exceeds packet-forwarding-rate that > "causes" queuing delays. It makes no sense to try to assign "blame" > for this to individual senders -- except in the limiting case where > a sender's packet-sending-rate exceeds the available-forwarding-rate > of a particular forwarder; and for that limiting-case it's not useful > to assign "blame" until the sender has had sufficient time to learn > the available-forwarding-rate. > > Bottom line: a good start, Stuart! > > -- > John Leslie > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From michawe@ifi.uio.no Tue Mar 1 10:19:51 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DC4B3A6A1A for ; Tue, 1 Mar 2011 10:19:51 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAjtynfvdnOd for ; Tue, 1 Mar 2011 10:19:49 -0800 (PST) Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by core3.amsl.com (Postfix) with ESMTP id 92E103A698E for ; Tue, 1 Mar 2011 10:19:48 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out1.uio.no with esmtp (Exim 4.72) (envelope-from ) id 1PuUBn-0007xR-KO for conex@ietf.org; Tue, 01 Mar 2011 19:20:51 +0100 Received: from cm-84.208.175.27.getinternet.no ([84.208.175.27] helo=[192.168.0.199]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.72) (envelope-from ) id 1PuUBn-00005u-0a; Tue, 01 Mar 2011 19:20:51 +0100 Message-Id: <80745FE4-DFA9-405E-A284-C26598D26828@ifi.uio.no> From: Michael Welzl To: Michael Welzl In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 1 Mar 2011 19:20:29 +0100 References: <64069EFF-C572-4088-9EF0-9CDE66B20390@cdt.org> <8F242B230AD6474C8E7815DE0B4982D7179FB92C@EXV1.corp.adtran.com> <20110301173738.GO7663@verdi> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 2 sum rcpts/h 8 sum msgs/h 4 total rcpts 7116 max rcpts/h 36 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 42C8E0750A254A095B900951E0D7FF4A3F1E078C X-UiO-SPAM-Test: UIO-GREYLIST remote_host: 84.208.175.27 spam_score: -49 maxlevel 80 minaction 1 bait 0 mail/h: 2 total 571 max/h 13 blacklist 0 greylist 1 ratelimit 0 Cc: conex@ietf.org Subject: Re: [conex] "Congestion" definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 18:19:51 -0000 sorry - totally missed john's reference to that same thread in this very email :) anyway, we made quite an effort to get the text of rfc 6077 right, so i hope that this is really helpful at this point On Mar 1, 2011, at 7:07 PM, Michael Welzl wrote: > congestion definition, AGAIN? well, if you people think it's > fun... :-) > > but check out some posts at: > http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2006-February/thread.html > > and the introduction of RFC 6077. > > > > > On Mar 1, 2011, at 6:37 PM, John Leslie wrote: > >> STUART VENTERS wrote: >>> >>> Definition for the kind of congestion that CONEX is trying to expose >>> in a statistically multiplexed routing cloud: >>> >>> Congestion is when a packet's forwarding behavior is adversely >>> affected >>> because of the traffic load caused by other packets in the cloud. >>> - 'Adversely affected' means dropped or delayed more than the >>> minimum >>> delay seen in an otherwise idle cloud. >>> - 'Other packets' means either packets from other users or packets >>> from >>> the same user. >> >> This is a good start at discussing what we think we're talking >> about. >> >> So, let me take it as a start, rather than criticize its >> completeness. >> >> (I should perhaps criticize "Congestion is when", but let me reserve >> that issue for later.) >> >> There is indeed good work going on to derive a measure of >> "congestion" >> from transit-time, assuming that transit-time includes only minimum >> latency plus queueing delays. (There are obvious problems with that >> assumption, which I won't discuss.) >> >> Assuming we could actually collect useful queueing-delay numbers, it >> is quite reasonable to assume them to represent a type of >> "congestion". >> >> BTW, I have discussed defining "congestion" on the ICCRG list, >> starting Sat, 4 Feb 2006 16:03:28 -0500: >> ] >> ] To me, congestion is the condition where a packet can't be sent >> ] "immediately" (meaning perhaps that it can't be queued as the next >> ] packet to be sent). >> >> (I derive that from a dictionary definition of "congestion: to >> cause an excessive accumulation...") >> >> We could reasonably come up with a better definition of >> "immediately", >> but I contend that it would be different for every class of >> traffic, so >> I start from the most restrictive. >> >> But I digress... >> >> I don't believe time spent on arguing how much queueing corresponds >> to "zero" congestion is helpful. >> >> Regardless, we do hit a discontinuity when the queue "fills" and a >> packet is dropped; and many folks use "congestion" to refer to that >> discontinuity. >> >> ECN came along to moderate that discontinuity: instead of dropping >> the packet, we'd enforce Random-Early-Detection and at the tipping- >> point >> of RED we'd ECN-mark the packet instead of dropping it. Assuming >> well- >> behaved sender-receiver pairings this would reduce the need to drop >> packets more-quickly than TCP-like protocols could do by detecting a >> drop. >> >> ECN deployment is spotty-at-best -- possibly because nobody sees a >> reason to trust the sender-receiver pairings... >> >> Getting back to Stuart's definition: >> >> I think "caused by" is the wrong wording. Necessarily, it is the >> fact that packet-arrival-rate exceeds packet-forwarding-rate that >> "causes" queuing delays. It makes no sense to try to assign "blame" >> for this to individual senders -- except in the limiting case where >> a sender's packet-sending-rate exceeds the available-forwarding-rate >> of a particular forwarder; and for that limiting-case it's not useful >> to assign "blame" until the sender has had sufficient time to learn >> the available-forwarding-rate. >> >> Bottom line: a good start, Stuart! >> >> -- >> John Leslie >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From john@jlc.net Tue Mar 1 11:03:33 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39AE73A6A19 for ; Tue, 1 Mar 2011 11:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.677 X-Spam-Level: X-Spam-Status: No, score=-106.677 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1ou+5vyRymR for ; Tue, 1 Mar 2011 11:03:32 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 6688C3A6A4A for ; Tue, 1 Mar 2011 11:03:11 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id F394A33C2B; Tue, 1 Mar 2011 14:04:14 -0500 (EST) Date: Tue, 1 Mar 2011 14:04:14 -0500 From: John Leslie To: Michael Welzl Message-ID: <20110301190414.GP7663@verdi> References: <64069EFF-C572-4088-9EF0-9CDE66B20390@cdt.org> <8F242B230AD6474C8E7815DE0B4982D7179FB92C@EXV1.corp.adtran.com> <20110301173738.GO7663@verdi> <80745FE4-DFA9-405E-A284-C26598D26828@ifi.uio.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80745FE4-DFA9-405E-A284-C26598D26828@ifi.uio.no> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] "Congestion" definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 19:03:33 -0000 Michael Welzl wrote: > > anyway, we made quite an effort to get the text of rfc 6077 right, so > i hope that this is really helpful at this point I do wish to commend Michael & Co. for RFC 6077, published this February. They have done an excellent job. However, it is addressing "Congestion Control", which is not our charge, and at 51 pages I can't expect everyone to be familiar with it. Our purpose is "Congestion Exposure" -- and IMHO we don't need to "expose" exactly the same thing that "Congestion Control" folks set out to control (were there even any such thing!). Some folks here think we're really closely tied to the ECN algorithm; others don't. I don't know to what extent we need to discuss differences, but I am willing to try to help delineate such differences (and possibly even _resolve_ them ;^). -- John Leslie From stuart.venters@adtran.com Tue Mar 1 11:54:19 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1EEA3A6AB2 for ; Tue, 1 Mar 2011 11:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vN0GtXzGvd0 for ; Tue, 1 Mar 2011 11:54:17 -0800 (PST) Received: from p02c12o145.mxlogic.net (p02c12o145.mxlogic.net [208.65.145.78]) by core3.amsl.com (Postfix) with ESMTP id 583503A6AB0 for ; Tue, 1 Mar 2011 11:54:17 -0800 (PST) Received: from unknown [76.164.174.81] (EHLO p02c12o145.mxlogic.net) by p02c12o145.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id 92f4d6d4.521ff940.6886.00-571.17182.p02c12o145.mxlogic.net (envelope-from ); Tue, 01 Mar 2011 12:55:21 -0700 (MST) X-MXL-Hash: 4d6d4f290a20bc2f-df50dd78d06f942c60da4865465e1fc99c5a8e2e Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c12o145.mxlogic.net(mxl_mta-6.9.0-1) over TLS secured channel with ESMTP id 32f4d6d4.0.6854.00-358.17082.p02c12o145.mxlogic.net (envelope-from ); Tue, 01 Mar 2011 12:55:17 -0700 (MST) X-MXL-Hash: 4d6d4f257f3e3262-db02dadea00c7aed6353cd99236597274b307a6b Received: from corp-exfr2.corp.adtran.com (172.23.101.22) by ex-hc1.corp.adtran.com (172.22.50.71) with Microsoft SMTP Server id 14.1.270.1; Tue, 1 Mar 2011 13:55:15 -0600 Received: from EXV1.corp.adtran.com ([172.22.48.215]) by corp-exfr2.corp.adtran.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Mar 2011 13:55:15 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Mar 2011 13:55:14 -0600 Message-ID: <8F242B230AD6474C8E7815DE0B4982D7179FB92F@EXV1.corp.adtran.com> In-Reply-To: <20110301173738.GO7663@verdi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "Congestion" definition Thread-Index: AcvYN120xVKsZezRQiKWEfeHpBxSfgACa0UA From: STUART VENTERS To: John Leslie X-OriginalArrivalTime: 01 Mar 2011 19:55:15.0301 (UTC) FILETIME=[953A8150:01CBD84A] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] X-AnalysisOut: [v=1.0 c=1 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=0XgpNN2/4a] X-AnalysisOut: [34ymu16SVwsQ==:17 a=yyJd0-ZHAAAA:8 a=IfgvnM56AAAA:8 a=48vg] X-AnalysisOut: [C7mUAAAA:8 a=eJNrpioGAAAA:8 a=D0syqeQNbJmMCU975K8A:9 a=rSn] X-AnalysisOut: [-MiIBVh53i9DNeSIA:7 a=lnfivQQmsiXKqM7AYOgwTWZ6bZUA:4 a=wPN] X-AnalysisOut: [LvfGTeEIA:10 a=0Z8cOJdu7yUA:10 a=TAcuDK1JbnAA:10 a=4Pd9wTg] X-AnalysisOut: [h_q4A:10 a=nrO8ZedqA1AA:10 a=IiGycQPoy5kA:10 a=lZB815dzVvQ] X-AnalysisOut: [A:10 a=DvnSUQUdWHYA:10 a=4xgxFMMM-93zXwqA:21 a=z14WAJXzzZp] X-AnalysisOut: [wkEU9:21] Cc: conex@ietf.org Subject: Re: [conex] "Congestion" definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 19:54:19 -0000 John, I just looked up the ICCRG list. Thanks. There's a lot of similar stuff there. Some specific pointers below. One def from ICCRG is as follows: "A network is said to be congested from the perspective of user i if = the utility of i decreases due to an increase in network load." This combines the idea of congestion in the cloud with the user's = congestion tolerance threshold. This definition seems to be heading towards congestion being the = state that you are above or below some threshold. I think of congestion is a continuum of states of the cloud, separate = from the user's idea of utility. Making it the result of a threshold test certainly raises issues of = discontinuity. Making it dependant on differing users ideas of utility certainly = makes it hard to define. I'm not sure which way the group wants to go, but at least this = points out issues in need of consensus. Incurring extra delay above the minimum is likely the first consequence = a packet sees at the onset of congestion. This makes measuring delay or the amount of queuing delay a likely = proxy for the amount of congestion in the network. One way to measure this proxy is to occasionally set bits or drop = packets (ECN and RED?) when this happens. Another way is to measure the end to end delay for each packet with an = accurate timestamps. This might require BGP work in the core to publish the minimum = forwarding times, but perhaps no hop by hop consequences, except for finding a place for the timestamp in every packet.) I'm not sure if it matters if any of these actually measure congestion = if the proxy tracks well enough. I guess as the network gets more loaded, the next proxy is packet drops, = which TCP depends on. If I understand the end goal here, we should never get this far over = the cliff edge if CONEX works out. I still vote for keeping the idea of congestion separate from the = proxies. As for the text I presented. I though about putting a disclaimer for the English. If I managed to get the idea on the table, I'm happy. If somebody can figure out a respectable way to say it, so much the = better. On a second reading, "Congestion is when"? That's terrible, who = write such a thing! =20 At least you'll got a little afternoon's entertainment. Cheers, Stuart enc: interesting ICCRG pointers URL for the above quote http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2006-February/000034.html A summary http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2006-February/000035.html Another discussion http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2006-February/000052.html The archive http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2006-February/thread.html -----Original Message----- From: John Leslie [mailto:john@jlc.net] Sent: Tuesday, March 01, 2011 11:38 AM To: STUART VENTERS Cc: conex@ietf.org Subject: "Congestion" definition STUART VENTERS wrote: >=20 > Definition for the kind of congestion that CONEX is trying to expose > in a statistically multiplexed routing cloud: >=20 > Congestion is when a packet's forwarding behavior is adversely = affected > because of the traffic load caused by other packets in the cloud. > - 'Adversely affected' means dropped or delayed more than the minimum > delay seen in an otherwise idle cloud. > - 'Other packets' means either packets from other users or packets = from > the same user. This is a good start at discussing what we think we're talking about. So, let me take it as a start, rather than criticize its = completeness. (I should perhaps criticize "Congestion is when", but let me reserve that issue for later.) There is indeed good work going on to derive a measure of = "congestion" from transit-time, assuming that transit-time includes only minimum latency plus queueing delays. (There are obvious problems with that assumption, which I won't discuss.) Assuming we could actually collect useful queueing-delay numbers, it is quite reasonable to assume them to represent a type of "congestion". BTW, I have discussed defining "congestion" on the ICCRG list, starting Sat, 4 Feb 2006 16:03:28 -0500: ]=20 ] To me, congestion is the condition where a packet can't be sent ] "immediately" (meaning perhaps that it can't be queued as the next ] packet to be sent). (I derive that from a dictionary definition of "congestion: to cause an excessive accumulation...") We could reasonably come up with a better definition of = "immediately", but I contend that it would be different for every class of traffic, so I start from the most restrictive. But I digress... I don't believe time spent on arguing how much queueing corresponds to "zero" congestion is helpful. Regardless, we do hit a discontinuity when the queue "fills" and a packet is dropped; and many folks use "congestion" to refer to that discontinuity. ECN came along to moderate that discontinuity: instead of dropping the packet, we'd enforce Random-Early-Detection and at the tipping-point of RED we'd ECN-mark the packet instead of dropping it. Assuming well- behaved sender-receiver pairings this would reduce the need to drop packets more-quickly than TCP-like protocols could do by detecting a drop. ECN deployment is spotty-at-best -- possibly because nobody sees a reason to trust the sender-receiver pairings... Getting back to Stuart's definition: I think "caused by" is the wrong wording. Necessarily, it is the fact that packet-arrival-rate exceeds packet-forwarding-rate that "causes" queuing delays. It makes no sense to try to assign "blame" for this to individual senders -- except in the limiting case where a sender's packet-sending-rate exceeds the available-forwarding-rate of a particular forwarder; and for that limiting-case it's not useful to assign "blame" until the sender has had sufficient time to learn the available-forwarding-rate. Bottom line: a good start, Stuart! -- John Leslie From dave.mcdysan@verizon.com Wed Mar 2 05:10:34 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CDF33A67E2 for ; Wed, 2 Mar 2011 05:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=-0.489, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bsRA7l1Twtx for ; Wed, 2 Mar 2011 05:10:30 -0800 (PST) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id A51B03A693C for ; Wed, 2 Mar 2011 05:10:30 -0800 (PST) Received: from fldsmtpi01.verizon.com (fldsmtpi01.verizon.com [166.68.71.143]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p22DBBVf022089 for ; Wed, 2 Mar 2011 08:11:26 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,253,1297036800"; d="scan'208";a="3945378" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi01.verizon.com with ESMTP; 02 Mar 2011 13:11:11 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.147]) by FHDP1LUMXC7HB03.us.one.verizon.com ([2002:a644:3bbe::a644:3bbe]) with mapi; Wed, 2 Mar 2011 08:11:11 -0500 To: Toby Moncaster , "'Alissa Cooper'" Date: Wed, 2 Mar 2011 08:11:08 -0500 Thread-Topic: [conex] Discussion of new Use Cases pt 1 Thread-Index: AcvY20yvxWCvvtSqRJqqBQ/nL/HLoQ== Message-ID: In-Reply-To: <001201cbd7f7$3f635700$be2a0500$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 13:10:34 -0000 Hi Toby, In line, snipping some material already covered. Dave On 3/1/11 4:58 AM, "Toby Moncaster" wrote: >Hi Dave, > >Inline Snipped > >> >I agree that Dave's peak/average rate signal doesn't seem to fit into >> the >> >same sort of signalling framework. For one thing Dave seems to just >> imply >> >this would be a binary state. >>=20 >>=20 >> I.m not sure I understand this comment. Could you please expand on what >> are the states. > >If I understood you correctly, you were suggesting that users would be >classified as "heavy" or "not heavy", with their traffic marked >appropriately? NOw I understand your point. I was proposing burstiness as (one possible) measure of "heaviness." It could be quantized as two values, and the title "heavy vs light" does imply this. However, I would not want to preclude more levels of quantization or a conex response that was some related to such a "heaviness" measure in a more continuous manner. > >>=20 >> >However I think it may be possible to derive >> >something that gives the same information as Dave is looking for >> without >> >needing an additional explicit signal. >>=20 >> This is a good example of how I would see the use case and mechanism >> drafts inter-relating. If the same mechanism signaling can be used to >> meet >> other use cases, then IMHO then this makes the abstract mechanism more >> attractive. However, if the use case cannot be (well) handled by the >> abstract mechanism, then that is also useful information. > >I agree it would be good to have some idea of how broad the applicability >of >the abstract mechanism is. I actually think that there is very little real >disagreement between what we are both saying. The only significant >difference seems to be you are suggesting an explicit measure of long-term >"heaviness" of use, whereas I feel that such a measure can be derived from >the short term congestion measure. I am OK with a comparable measure that can be derived from the abstract mechanism draft. But we should agree as to what the form of the result of such a variation would like. That is, what are the characterisitics. > > >>=20 >> > >> >> >> >> If we are focused on a single metric, then I think we need to >> document >> >> use cases for that metric. If there are multiple metrics, we should >> be >> >> clear about which use cases make use of which metric. And in either >> >> case, I thought the point of the mechanism draft was to explain how >> >> the chosen metric is measured so that it can be encoded at the IP >> >> layer. >> > >> >I favour concentrating on a single metric relating as closely as >> possible >> >to >> >"real" congestion. But Dave does have a very valid point - for >> whatever >> >reason, many ISPs use a shaper to rate limit traffic to/from their >> >customers. I would argue that at peak times this is probably not the >> >limiting factor, but off-peak it will be the biggest source of >> apparent >> >loss/congestion. >>=20 >> And as I tried to describe in my Beijing draft, in certain growth and >> restoration scenarios off-peak is the majority of elapsed network >> equipment deployment time. > >I will go back to your draft to see if I can understand this a bit better. >Out of interest, do you have a good feel for how things differ between >DOCSIS and xDSL systems? I know that in xDSL there is also shaping at the >BRAS (or DSLAM) to make sure the downlink to the end user is not >overloaded. This is a different aspect. It was covered in the time of day reuse section of my Beijing draft. As suggested in the WG minutes draft I plan to write a short individual draft on this topic and submit by 3/7. I will include/ clarify this point in that short draft. I plan to include some of the material from the thread related to ledbat and some of the problem statement comments from Mikael Abrahamsson. > >>=20 >> > >> >One interesting thought experiment - what if, instead of a shaper, the >> ISP >> >introduces a congestion marking system. Then it can rate limit traffic >> by >> >marking it before the traffic needs to be disrupted. The only problem >> then >> >is how to deal with non-responsive traffic. >>=20 >> This idea is not complete, but I think it is in the direction I >> mentioned >> above of having a description of how one mechanism could be used in a >> different way to meet the needs of a use case. > >The idea is very far from complete! I wanted to try and get people >thinking >about how adaptable the ConEx approach might be... As I say, our views on >this are not all that different in practise. Agreed. I would be open to jointly develop some text off-list that describes the derivation you mention and mapping to the abstract mechanism and then publishing that proposed text to the list. From dave.mcdysan@verizon.com Wed Mar 2 05:40:32 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E93143A6820 for ; Wed, 2 Mar 2011 05:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.113 X-Spam-Level: X-Spam-Status: No, score=-3.113 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmPuRQDoPYLF for ; Wed, 2 Mar 2011 05:40:31 -0800 (PST) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id E0B423A67B7 for ; Wed, 2 Mar 2011 05:40:28 -0800 (PST) Received: from fldsmtpi03.verizon.com (fldsmtpi03.verizon.com [166.68.71.145]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p22DfWZu015663 for ; Wed, 2 Mar 2011 08:41:32 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,253,1297036800"; d="scan'208";a="3959771" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi03.verizon.com with ESMTP; 02 Mar 2011 13:41:31 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.147]) by FHDP1LUMXC7HB01.us.one.verizon.com ([2002:a644:3bbc::a644:3bbc]) with mapi; Wed, 2 Mar 2011 08:41:31 -0500 To: Alissa Cooper Date: Wed, 2 Mar 2011 08:41:29 -0500 Thread-Topic: [conex] Discussion of new Use Cases pt 1 Thread-Index: AcvY34pKlnmSLzK3SdSNnqFjEfcnhg== Message-ID: In-Reply-To: <64069EFF-C572-4088-9EF0-9CDE66B20390@cdt.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 13:40:33 -0000 Hi Alissa, The term (and document) in the context of the IETF 79 meeting minutes was "mechanism," and I assumed that is what you meant in your post. Let me try to map the discussion so far to your approaches using the above assumption. IMHO, the agreement from IETF 79 was that use cases that can be proposed for inclusion in the use cases document that do not necessarily need to have a representation in the (current version) of the abstract mechanism document. (Approach 2) As posted by Toby and John, if a derivation from information provided by the (current version) of the abstract mechanism can be defined to meet the use case, then the use case document is the best place to document this. (Approach 1) Also, as I posted, if there is a use case that is not well supported by a (derivation of) the abstract mechanism, then the use case document would also be a good place to document this. (Approach 2) Thanks, Dave On 3/1/11 5:15 AM, "Alissa Cooper" wrote: >Dave, > >I don't have strong feelings about Approach 1 vs. Approach 2. I just >think when we discuss existing or new use cases, we need to be clear >about what metric (or whatever word people want to use instead of >"metric") they are based on and whether those metrics all measure the >same thing, whether they can be derived from each other, or whether >they measure different things. Otherwise it becomes unclear what a use >case is "using." > >I sensed some confusion about this at IETF 79 and was sensing it again >on the list. But if it's just my confusion, we can ignore it and move >on. > >Alissa > > >On Mar 1, 2011, at 1:30 AM, Mcdysan, David E wrote: > >> Hi Alissa, >> >> Some responses in line below. >> >> Thanks, >> >> Dave >> >> On 2/26/11 7:21 AM, "Alissa Cooper" wrote: >> >>> Hi Dave, >>> >>> Couple of questions inline... >>> >>> On Feb 25, 2011, at 2:17 PM, Mcdysan, David E wrote: >>>> The proposed measure from the text that Toby sent from my draft for >>>> this >>>> use case is that of burstiness (I.e., peak/average) where the >>>> incentive >>>> peak is the"flat rate" or "bandwidth tier" purchased. >>>> ... >>>> >>>> Let me illustrate by an example. If conex could send longer-term >>>> user >>>> burstiness to the congested shared resource, then a mechanism (to be >>>> described in the mechanism draft) at that point could >>>> drop more traffic from class B non-bursty users so that bandwidth >>>> tends >>>> to equalize between the two user classes >>>> Implement a bandwidth tier AND burst duration pricing scheme, with >>>> appropriate mechanisms to provide a burst duration longer than the >>>> shapers >>>> widely used today >>>> >>> >>> It seems to me that there are two different approaches being taken to >>> what is or is not in scope for both the use cases and the mechanism >>> definition: >>> >>> Approach #1: >>> a. Assume that the CONEX mechanism will be used exclusively to signal >>> the amount of congestion encountered by previous packets on the same >>> flow >>> b. Document the different uses to which that signal could be put >>> (traffic management, incentivizing scavenger services, etc.) in the >>> use cases draft >>> c. Document how the signal is set in the mechanism draft >>> >>> Approach #2: >>> a. Assume that the metric that CONEX will signal is open for >>> discussion, or that the mechanism may signal multiple different >>> metrics >>> b. Document use cases for a variety of different potential metrics in >>> the use cases draft (congestion encountered previously on same flow, >>> long-term user burstiness as you describe above, possibly others) >>> c. Document how network nodes could respond to CONEX signals to >>> effectuate particular outcomes (dropping more traffic from non-bursty >>> users as you describe above) >>> >>> It seems as though you are taking approach #2 whereas others may be >>> taking approach #1, and these two approaches probably need to be >>> reconciled. I don't see how the same mechanism can signal both >>> congestion previously experienced on the path and peak/average >>> sending >>> rate (although I'm happy for you or someone else to explain how it >>> can >>> be done). If it can't be done, then it seems like we are talking >>> about >>> signaling two different metrics. >>> >>> If we are focused on a single metric, then I think we need to >>> document >>> use cases for that metric. If there are multiple metrics, we should >>> be >>> clear about which use cases make use of which metric. And in either >>> case, I thought the point of the mechanism draft was to explain how >>> the chosen metric is measured so that it can be encoded at the IP >>> layer. >>> >>> Alissa >> >> Quoting from the IETF 70 meeting minutes >> >> "ConEx Concepts and Abstract Mechanism >> draft-mathis-conex-abstract-mech-00 " >> >> >> Snipped >> " MB - not asking about sending to IESG, just asking about adoption >> - do >> people have comments? >> >> Dave McDysan (DM) - charter related question - first result >> is >> usage >> scenarios document - other docs will not see publication >> until >> that is >> done - have already had questions on list about additional >> use >> cases. >> if we adopt this as the mechanism document then we foreclose >> use-case >> discussion. there are use cases being elaborated that aren't >> supported >> by the mechanism, so we could be going round in circles here. >> >> MB - are you envisioning additional use cases that could >> not be >> satisfied >> by this mechanism? >> >> DM - yes >> >> MB - is this a little different or a lot? >> >> DM - could be a lot different. this is a good approach for >> short >> timescales, but could do something longer term, slow path. >> >> MB - so you would like to agree use cases? >> >> Leslie Daigle (LD) - i would like to support adopting >> mechanism >> document. >> just don't use it as a blunt instrument to bludgeon people >> proposing new >> use cases. >> >> MB - would that work for DM? >> >> DM - yes, if that decision can be documented. >> >> MB - yes, it will be documented, I will remember." >> >> >> >> I interpreted the above as something like Approach 2 was acceptable >> -- a >> use case did not need to align with the currently documented abstract >> mechanism. If others have a different interpretation, please respond >> to >> the list. >> >> Also, the way the prior version of the use case draft was written was >> closely tied to the (re-ECN) mechanism (Approach 1) and the >> agreement from >> the IETF 78 meeting minutes was to separate these. I provided a >> detailed >> set of comments toward this end. >> >>> >>>> >>>> Thanks, >>>> >>>> Dave >>>> >>>> >>>> On 2/24/11 5:11 PM, "John Leslie" wrote: >>>> >>>>> STUART VENTERS wrote: >>>>>> >>>>>> Let me make sure I understand this use case and it's desired >>>>>> outcome: >>>>>> >>>>>> Consider 2 users A, and B. >>>>>> A sends at a low rate all the time. >>>>>> B sends only a congestion causing bunch during busy times. >>>>>> A sends many more bytes per month than B >>>>>> >>>>>> Which is the 'heavy' user (I think B)? >>>>> >>>>> I don't think we should assume that... >>>>> >>>>>> Are we looking for a way for service providers to determine >>>>>> 'equitable' >>>>>> costs for these behaviors, or a way to make the system forwarding >>>>>> behavior for these two load is somehow 'equitable'? >>>>> >>>>> To some degree, Dave has to speak for himself, but IMHO this issue >>>>> is >>>>> about being able (under ConEx) to better inform a provider's >>>>> decision. >>>>> I'm nearly positive Dave doesn't mean for us to argue what balance >>>>> between >>>>> these two is "equitable". >>>>> >>>>> At first blush, it would seem "B" should "expect" congestion >>>>> losses, >>>>> while "A" might not. Current non-ConEx methods tend to punish "A" >>>>> more >>>>> than "B"; and I do suspect Dave is suggesting a different balance >>>>> might >>>>> be appropriate. >>>>> >>>>> Nonetheless, IMHO "A" should expect congestion losses to increase >>>>> during periods of heavy use -- unless s/he buys better-than the >>>>> vanilla >>>>> best-effort service. >>>>> >>>>> -- >>>>> John Leslie >>>>> _______________________________________________ >>>>> conex mailing list >>>>> conex@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/conex >>>> >>>> _______________________________________________ >>>> conex mailing list >>>> conex@ietf.org >>>> https://www.ietf.org/mailman/listinfo/conex >>>> >>> >> >> > > From dave.mcdysan@verizon.com Wed Mar 2 06:00:46 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24E853A67D8 for ; Wed, 2 Mar 2011 06:00:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.402 X-Spam-Level: X-Spam-Status: No, score=-3.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyOBkJ2IvoaW for ; Wed, 2 Mar 2011 06:00:45 -0800 (PST) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id 3EF753A67B7 for ; Wed, 2 Mar 2011 06:00:45 -0800 (PST) Received: from fldsmtpi03.verizon.com (fldsmtpi03.verizon.com [166.68.71.145]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p22E1o37022262 for ; Wed, 2 Mar 2011 09:01:51 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,253,1297036800"; d="scan'208";a="3974577" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi03.verizon.com with ESMTP; 02 Mar 2011 14:01:50 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.147]) by FHDP1LUMXC7HB01.us.one.verizon.com ([2002:a644:3bbc::a644:3bbc]) with mapi; Wed, 2 Mar 2011 09:01:50 -0500 To: STUART VENTERS , "conex@ietf.org" Date: Wed, 2 Mar 2011 09:01:48 -0500 Thread-Topic: [conex] Discussion of new Use Cases pt 1 Thread-Index: AcvY4mCcqkCov2AhT4euWn+N+4DvaA== Message-ID: In-Reply-To: <8F242B230AD6474C8E7815DE0B4982D7179FB92C@EXV1.corp.adtran.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 14:00:46 -0000 Hi Stuart, An individual flow will experience the effect of loss or increased delay if a shaper (more generally a non-work conserving scheduler) that is similar to congestion of a shared resource. The current use case draft only mentions congestion of a shared resources. This only covers a (subset) of the things which both "feel" like congestion to a an individual flow. =20 IMHO, somehow the use case (and mechanism) draft need to describe and address this shaper/non-work conserving scheduler case which will appear as congestion to an individual flow. One simple way to address this would be to declare it out of scope, but then in my opinion the wg has not addressed an important use case that will be difficult to distinguish from shared resource congestion. Thanks, Dave On 3/1/11 11:56 AM, "STUART VENTERS" wrote: >All, > >After thinking about Allissa and Dave's discussion, here's my 2c for a >CONEX congestion definition: > > > > >Definition for the kind of congestion that CONEX is trying to expose in a >statistically multiplexed routing cloud: > >Congestion is when a packet's forwarding behavior is adversely affected >because of the traffic load caused by other packets in the cloud. > 'Adversely affected' means dropped or delayed more than the minimum >delay seen in an otherwise idle cloud. > 'Other packets' means either packets from other users or packets from >the same user. > >When a packet gets affected simply because a shaper or policer says that >a specific flow or user is sending more bits that the traffic contract >allows,=20 > that doesn't feel like congestion, but rather traffic management. > >On the other hand, if the shaper were affecting packets because it sees >the cloud is near or at congestion, then that effect feels like >congestion. > (Because traffic management is telling the user that there is, or >soon will be congestion.) > > > >The definition is focused on the discussion, so I may have completely >missed some other aspect of congestion? > >Under this definition, it might turn out that CONEX needs to expose both >traffic management and congestion behaviors. > I don't yet see the need for this, but could easily be persuaded by a >use case. > It would just be unfortunate if we had to muddy the definitions for the >two in order to include the TM behaviors. > > >Cheers, > >Stuart >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex From dave.mcdysan@verizon.com Wed Mar 2 07:03:01 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D128A3A67AF for ; Wed, 2 Mar 2011 07:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQwEslPS22h5 for ; Wed, 2 Mar 2011 07:03:00 -0800 (PST) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id 389053A67A1 for ; Wed, 2 Mar 2011 07:03:00 -0800 (PST) Received: from fldsmtpi02.verizon.com (fldsmtpi02.verizon.com [166.68.71.144]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p22F3rep014667 for ; Wed, 2 Mar 2011 10:03:59 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,253,1297036800"; d="scan'208";a="4024878" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi02.verizon.com with ESMTP; 02 Mar 2011 15:03:47 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.147]) by FHDP1LUMXC7HB04.us.one.verizon.com ([2002:a644:3bbf::a644:3bbf]) with mapi; Wed, 2 Mar 2011 10:03:46 -0500 To: Toby Moncaster , "'John Leslie'" Date: Wed, 2 Mar 2011 10:03:41 -0500 Thread-Topic: "Metric" - "Measure"? Thread-Index: AcvY6wd37KDs0mmwTjySBvXAYFJmjg== Message-ID: In-Reply-To: <003d01cbd834$8d463a40$a7d2aec0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] "Metric" - "Measure"? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 15:03:02 -0000 I think the term "measure" used in the use case draft is sufficient. >From http://en.wikipedia.org/wiki/Measure_(mathematics) "... a measure on a set is a systematic way to assign to each suitable subset a number ..." The use case document defines congestion as "Congestion is a measure of the probability that a packet will be marked or dropped as it traverses a queue." The abstract mechanism draft specifically defines these as LOSS and ECN "signals" passed (implicitly or explicitly) from the congestion point to the receiver. In measure theory terms the implicit/explicit "signals" associated with these packets that experience congestion are a systematically defined subset of the set of all packets delivered to the receiver. The abstract mechanism then defines (implicit/explicit) loss/marking feedback signals to the sender. (In a subset of all reverse direction packets of the same flow (e.g., TCP ACKs). Finally feed-forward (re-inserted) information developed in a systematic way from the fed-back congestion (loss, ECN marking) subset of reverse direction packets is inserted into a subset of the packets from sender to receiver. I think that all of these subsets can be assigned to a number. Similar arguments can be made for Con-ex capable and credit bits from the abstract mechanism draft. Therefore, I believe the mathematical meaning of the term "measure" is sufficient. This is what I had in mind when I proposed a burstiness "measure." As Toby mentioned it may be possible to map the conex abstract mechanism to the burstiness measure I defined in my Beijing draft and an earlier post. If anyone has another basis for terminology, then please propose it. Otherwise, I would like to proceed on attempting to doing what Toby proposed using the concept and terminology of "measure." Thanks, Dave On 3/1/11 12:17 PM, "Toby Moncaster" wrote: >(NB I haven't yet properly parsed John's reply). > >Surely what it boils down to is we need to define the "congestion" that >will >be exposed by "congestion exposure"! > >And yes, lurkers are very welcome to join in this discussion - it is >important we reach some sort of consensus here (not on the use of the word >"metric", but on what the word is applied to). > >Oh, and a (not serious) suggested alternative word: "quantifier"... > >Toby > >> -----Original Message----- >> From: John Leslie [mailto:john@jlc.net] >> Sent: 01 March 2011 16:59 >> To: Toby Moncaster >> Cc: 'Mcdysan, David E'; 'Alissa Cooper'; conex@ietf.org >> Subject: "Metric" >>=20 >> Toby Moncaster wrote: >> > [ wrote:] >> >> [John Leslie wrote:] >> >> >> >> > >> >>> I am hesitant to go the path of labeling use-cases according to >> >>> what metric best serves them. IMHO, our use-cases document should >> >>> only include things achievable with a particular metric, which I >> >>> have been assuming to be congestion-expected-during-transit. >>=20 >> (My apologies for hand-waving here: I'll get back to what I meant.) >>=20 >> >> Metric is mentioned once in the use case document in section 3 in >> the >> >> context of existing approaches. Are you referring to the measures in >> >> definitions of use cases, or something in the abstract mechanism >> >> draft? (where the term metric is not used at all) >> > >> > I (more or less deliberately) avoided using the word "metric" in the >> > use cases document. The main reason being that it may confuse people >> > that are not used to thinking of congestion as something with a >> > measurable value (after all TCP assumes congestion exists or it >> > doesn't). >> > >> > In this discussion, metric is being used as short-hand for "the means >> > by which we establish how much congestion a given packet/flow/user >> > expects to create" >>=20 >> (Toby is hand-waving here... ;^) >>=20 >> I realize we're not conveying the right idea when we use the word >> "metric". First, let me explain what I have meant (and I was assuming >> the other authors meant). >>=20 >> The dictionary-definition I try to fit under is: >> " >> " 2. a standard of measurement... >>=20 >> by which I mean "a set of rules which allows different observers to >> generally report the same number when they set out to measure the >> same observable". >>=20 >> (Whether that "number" is binary, integer, or real should be >> derivable >> from the rules.) >>=20 >> I have been using the word "metric" because I don't believe we have >> any consensus what "rules" apply. Some of us are very strict adherents >> to the rules of ECN; others think ECN is all wet; et cetera... >>=20 >> The hope is that we can (later) agree on one or more actual >> "metrics" >> (sets of rules) for a packet being forwarded from source to >> destination; >> and that we can concentrate our effort (for now) on how to carry the >> result of that measurement through the ConEx process: back to the >> sender >> and through the forwarding process for a future packet. >>=20 >> (Getting back to my earlier hand-waving: the unstated assumption is >> that the receiver of a packet will decode a number according to a rule >> for "congestion experienced by a packed during transit", report that >> number back to the sender, and the sender will encode a corresponding >> number into future packet(s) it sends, intending it to convey its >> prediction of "congestion-experienced-during-transit".) >>=20 >> I've taken some time before replying, trying to come up with a term >> to substitute for "metric" which will still allow us to gloss over the >> issue of how we measure "congestion" -- and (for now, at least) given >> up. I'd be delighted to hear suggestions from other participants (or >> even lurkers)... >>=20 >> -- >> John Leslie > From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Mar 2 08:48:51 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97C813A67B3 for ; Wed, 2 Mar 2011 08:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.438 X-Spam-Level: X-Spam-Status: No, score=-1.438 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZ3fzojE8MKq for ; Wed, 2 Mar 2011 08:48:50 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id BF0823A67A5 for ; Wed, 2 Mar 2011 08:48:50 -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 8EB4A633B1; Wed, 2 Mar 2011 17:49: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 7AB6759A8A; Wed, 2 Mar 2011 17:49:55 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: conex@ietf.org, "Mcdysan, David E" , Toby Moncaster Date: Wed, 2 Mar 2011 17:49:54 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20090731.1005176) References: In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201103021749.54967.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 16:48:51 -0000 Hi Dave, > >> >However I think it may be possible to derive > >> >something that gives the same information as Dave is looking for without > >> >needing an additional explicit signal. > >> > >> This is a good example of how I would see the use case and mechanism > >> drafts inter-relating. If the same mechanism signaling can be used to > >> meet > >> other use cases, then IMHO then this makes the abstract mechanism more > >> attractive. However, if the use case cannot be (well) handled by the > >> abstract mechanism, then that is also useful information. > > > >I agree it would be good to have some idea of how broad the applicability > >of > >the abstract mechanism is. I actually think that there is very little real > >disagreement between what we are both saying. The only significant > >difference seems to be you are suggesting an explicit measure of long-term > >"heaviness" of use, whereas I feel that such a measure can be derived from > >the short term congestion measure. > > I am OK with a comparable measure that can be derived from the abstract > mechanism draft. But we should agree as to what the form of the result of > such a variation would like. That is, what are the characterisitics. I agree with Toby here. You can derive something like "heaviness" or "burtiness" from the (long-term evaluation of) ConEx information. Thus the use case would be that those information can be derived. The use case should _NOT_ cover _HOW_ those information will be derived as this is a different mechanism and out of scope. Mirja From stuart.venters@adtran.com Wed Mar 2 09:08:34 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0E8C3A6857 for ; Wed, 2 Mar 2011 09:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMqYZ5PCwfix for ; Wed, 2 Mar 2011 09:08:34 -0800 (PST) Received: from p02c12o143.mxlogic.net (p02c12o143.mxlogic.net [208.65.145.76]) by core3.amsl.com (Postfix) with ESMTP id 6CDCD3A6855 for ; Wed, 2 Mar 2011 09:08:33 -0800 (PST) Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p02c12o143.mxlogic.net(mxl_mta-6.9.0-1) over TLS secured channel with ESMTP id 3d97e6d4.0.13702.00-392.33860.p02c12o143.mxlogic.net (envelope-from ); Wed, 02 Mar 2011 10:09:40 -0700 (MST) X-MXL-Hash: 4d6e79d40b4b04c7-843ddba4b193b7392110b0c1feb62354920a00e5 Received: from corp-exfr1.corp.adtran.com (172.23.101.21) by ex-hc3.corp.adtran.com (172.22.50.73) with Microsoft SMTP Server id 14.1.270.1; Wed, 2 Mar 2011 11:09:38 -0600 Received: from EXV1.corp.adtran.com ([172.22.48.215]) by corp-exfr1.corp.adtran.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Mar 2011 11:09:12 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Mar 2011 11:09:11 -0600 Message-ID: <8F242B230AD6474C8E7815DE0B4982D7179FB934@EXV1.corp.adtran.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] Discussion of new Use Cases pt 1 Thread-Index: AcvY4mCcqkCov2AhT4euWn+N+4DvaAAGJLsw From: STUART VENTERS To: "Mcdysan, David E" X-OriginalArrivalTime: 02 Mar 2011 17:09:12.0462 (UTC) FILETIME=[8D53AAE0:01CBD8FC] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.82] X-AnalysisOut: [v=1.0 c=1 a=G9T4uwCCN8UA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-] X-AnalysisOut: [IA:10 a=J+LXdEUA8t8MtBPt16/Qbg==:17 a=ZsyXEVtvAAAA:8 a=48v] X-AnalysisOut: [gC7mUAAAA:8 a=eJNrpioGAAAA:8 a=AljJKeqSYkPM6J7cnXQA:9 a=GD] X-AnalysisOut: [6grKrCdCd8koBJoIMA:7 a=5_982vACxnYSyDjCrlpGW1KiGEEA:4 a=wP] X-AnalysisOut: [NLvfGTeEIA:10 a=TRFw3Wk1wdAA:10 a=lZB815dzVvQA:10 a=DvnSUQ] X-AnalysisOut: [UdWHYA:10 a=xVYAKjGRGjb0ooYa:21 a=rkjrD5NxAFxnLT6l:21] Cc: conex@ietf.org Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 17:08:35 -0000 Dave, I support your direction (somehow, the use case draft needs to cover the shaper/non-work = conserving scheduler) because it will get the issue on the table for discussion. I'm just quibbling over the terminology. Congestion and shapers are similar in effect but different in cause = and therefore response. For congestion, the optimal application response is send slower now = and try faster later. For a shaper, the optimal application response is send slower now = and somehow ask for better service if you need to go faster. I seems worth keeping the two separate in terminology for the time = being. Regards, Stuart -----Original Message----- From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com] Sent: Wednesday, March 02, 2011 8:02 AM To: STUART VENTERS; conex@ietf.org Subject: Re: [conex] Discussion of new Use Cases pt 1 Hi Stuart, An individual flow will experience the effect of loss or increased delay if a shaper (more generally a non-work conserving scheduler) that is similar to congestion of a shared resource. The current use case draft only mentions congestion of a shared resources. This only covers a (subset) of the things which both "feel" like congestion to a an individual flow. =20 IMHO, somehow the use case (and mechanism) draft need to describe and address this shaper/non-work conserving scheduler case which will appear as congestion to an individual flow. One simple way to address this = would be to declare it out of scope, but then in my opinion the wg has not addressed an important use case that will be difficult to distinguish = from shared resource congestion. Thanks, Dave On 3/1/11 11:56 AM, "STUART VENTERS" wrote: >All, > >After thinking about Allissa and Dave's discussion, here's my 2c for a >CONEX congestion definition: > > > > >Definition for the kind of congestion that CONEX is trying to expose in = a >statistically multiplexed routing cloud: > >Congestion is when a packet's forwarding behavior is adversely affected >because of the traffic load caused by other packets in the cloud. > 'Adversely affected' means dropped or delayed more than the minimum >delay seen in an otherwise idle cloud. > 'Other packets' means either packets from other users or packets = from >the same user. > >When a packet gets affected simply because a shaper or policer says = that >a specific flow or user is sending more bits that the traffic contract >allows,=20 > that doesn't feel like congestion, but rather traffic management. > >On the other hand, if the shaper were affecting packets because it sees >the cloud is near or at congestion, then that effect feels like >congestion. > (Because traffic management is telling the user that there is, or >soon will be congestion.) > > > >The definition is focused on the discussion, so I may have completely >missed some other aspect of congestion? > >Under this definition, it might turn out that CONEX needs to expose = both >traffic management and congestion behaviors. > I don't yet see the need for this, but could easily be persuaded by a >use case. > It would just be unfortunate if we had to muddy the definitions for = the >two in order to include the TM behaviors. > > >Cheers, > >Stuart >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex From toby@moncaster.com Wed Mar 2 09:23:49 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7C263A6838 for ; Wed, 2 Mar 2011 09:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDkJ8x1eNv-S for ; Wed, 2 Mar 2011 09:23:48 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id 25AC43A682C for ; Wed, 2 Mar 2011 09:23:48 -0800 (PST) Received: from TobysHP (host81-158-50-164.range81-158.btcentralplus.com [81.158.50.164]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0Lf0SV-1QM8GC1Tkl-00qg47; Wed, 02 Mar 2011 18:24:53 +0100 From: "Toby Moncaster" To: "'STUART VENTERS'" , "'Mcdysan, David E'" References: <8F242B230AD6474C8E7815DE0B4982D7179FB934@EXV1.corp.adtran.com> In-Reply-To: <8F242B230AD6474C8E7815DE0B4982D7179FB934@EXV1.corp.adtran.com> Date: Wed, 2 Mar 2011 17:24:50 -0000 Message-ID: <004201cbd8fe$bde5fc10$39b1f430$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcvY4mCcqkCov2AhT4euWn+N+4DvaAAGJLswAADLaYA= Content-Language: en-gb X-Provags-ID: V02:K0:zz18sDsdef8kaZdKKDJw1K91JVXE3WaGjUy0OxFvs66 Xm3U+vPKzaFKMFmrxtQgom3OI6INItxU+bqqEwVUd+eMOtFeNh UDKEk2zJJmRmHhZWBhZXplo0eIpr0kqiv+w1nlJY+2/eLFek1r N7yBtBSK+pfL17/MwGCZoRW1yYNnWfEaOPHgSk3u1NUs/G0WEy /2xUm4lKpNyKYkb1q8w978kWw1e/hlA7x0/kmunoV0= Cc: conex@ietf.org Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 17:23:49 -0000 > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of STUART VENTERS > Sent: 02 March 2011 17:09 > To: Mcdysan, David E > Cc: conex@ietf.org > Subject: Re: [conex] Discussion of new Use Cases pt 1 > > Dave, > > I support your direction > (somehow, the use case draft needs to cover the shaper/non-work > conserving scheduler) > because it will get the issue on the table for discussion. > > I'm just quibbling over the terminology. > Congestion and shapers are similar in effect but different in cause > and therefore response. > For congestion, the optimal application response is send slower > now and try faster later. > For a shaper, the optimal application response is send slower now > and somehow ask for better service if you need to go faster. Furthermore, the fact you have been shaped is not correlated with whether you have had an adverse impact on other users. Consequently if you include that form of congestion information in the ConEx signal then it needs to be reacted to differently by the rest of the network... My current instinct is that we should include of Dave's burstiness measure, but give it its own section that looks at forms of congestion beyond the classical queue-related congestion represented by packet drop, queue delay and ECN marking. I guess that is what you are implying in the sentence below... > I seems worth keeping the two separate in terminology for the time > being. > > Regards, > > Stuart > > -----Original Message----- > From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com] > Sent: Wednesday, March 02, 2011 8:02 AM > To: STUART VENTERS; conex@ietf.org > Subject: Re: [conex] Discussion of new Use Cases pt 1 > > > Hi Stuart, > > An individual flow will experience the effect of loss or increased > delay > if a shaper (more generally a non-work conserving scheduler) that is > similar to congestion of a shared resource. The current use case draft > only mentions congestion of a shared resources. This only covers a > (subset) of the things which both "feel" like congestion to a an > individual flow. > > IMHO, somehow the use case (and mechanism) draft need to describe and > address this shaper/non-work conserving scheduler case which will > appear > as congestion to an individual flow. One simple way to address this > would > be to declare it out of scope, but then in my opinion the wg has not > addressed an important use case that will be difficult to distinguish > from > shared resource congestion. > > > Thanks, > > Dave > > On 3/1/11 11:56 AM, "STUART VENTERS" wrote: > > >All, > > > >After thinking about Allissa and Dave's discussion, here's my 2c for a > >CONEX congestion definition: > > > > > > > > > >Definition for the kind of congestion that CONEX is trying to expose > in a > >statistically multiplexed routing cloud: > > > >Congestion is when a packet's forwarding behavior is adversely > affected > >because of the traffic load caused by other packets in the cloud. > > 'Adversely affected' means dropped or delayed more than the minimum > >delay seen in an otherwise idle cloud. > > 'Other packets' means either packets from other users or packets > from > >the same user. > > > >When a packet gets affected simply because a shaper or policer says > that > >a specific flow or user is sending more bits that the traffic contract > >allows, > > that doesn't feel like congestion, but rather traffic management. > > > >On the other hand, if the shaper were affecting packets because it > sees > >the cloud is near or at congestion, then that effect feels like > >congestion. > > (Because traffic management is telling the user that there is, or > >soon will be congestion.) > > > > > > > >The definition is focused on the discussion, so I may have completely > >missed some other aspect of congestion? > > > >Under this definition, it might turn out that CONEX needs to expose > both > >traffic management and congestion behaviors. > > I don't yet see the need for this, but could easily be persuaded by > a > >use case. > > It would just be unfortunate if we had to muddy the definitions for > the > >two in order to include the TM behaviors. > > > > > >Cheers, > > > >Stuart > >_______________________________________________ > >conex mailing list > >conex@ietf.org > >https://www.ietf.org/mailman/listinfo/conex > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From dave.mcdysan@verizon.com Wed Mar 2 09:57:54 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0DD53A680C for ; Wed, 2 Mar 2011 09:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.435 X-Spam-Level: X-Spam-Status: No, score=-3.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5XYRDdI56xR for ; Wed, 2 Mar 2011 09:57:53 -0800 (PST) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id 1B2F73A67C0 for ; Wed, 2 Mar 2011 09:57:52 -0800 (PST) Received: from fldsmtpi02.verizon.com (fldsmtpi02.verizon.com [166.68.71.144]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p22HwtEx024289 for ; Wed, 2 Mar 2011 12:58:56 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,254,1297036800"; d="scan'208";a="4166370" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi02.verizon.com with ESMTP; 02 Mar 2011 17:58:46 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.147]) by FHDP1LUMXC7HB02.us.one.verizon.com ([2002:a644:3bbd::a644:3bbd]) with mapi; Wed, 2 Mar 2011 12:58:46 -0500 To: STUART VENTERS Date: Wed, 2 Mar 2011 12:58:44 -0500 Thread-Topic: [conex] Discussion of new Use Cases pt 1 Thread-Index: AcvZA3nW5rZZwxnRRFmeD0DWgpybDw== Message-ID: In-Reply-To: <8F242B230AD6474C8E7815DE0B4982D7179FB934@EXV1.corp.adtran.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 17:57:54 -0000 Hi Stuart, I agree that although the user perceived effect is different, the cause is important and the response may indeed be different. We need to document this. There may be a need to distinguish how these are signaled as well. For example, if loss is implicitly determined by the receiver then there currently may not be a way to distinguish between congestion of a shared queue and shaper buffer overflow. Your last comment "somehow ask for better service if you need to go faster" made me think of who would pay for making the service "go faster." There is a burst mode service offered by some ISPs; and in some cases the user pays and in others it involves recharging (i.e., someone else pays). This reminds me of a comment as recorded in the Beijing minutes by an unnamed person from Ericsson that recharging had been tried for 100 years in telephony and it did not work and would not work in the Internet. I did not have time to respond in the meeting, and am doing so here. Isn't toll free service in telephony a form of recharging (i.e., called party pays instead of caller)? Are you saying that toll-free service has not worked? The assertion made by that speaker was that therefore recharging should not be considered. I think that in at least the consideration of who pays for adjusting the rate of a shaper that it is something to be mentioned. Any disagreement? Thanks, Dave On 3/2/11 12:09 PM, "STUART VENTERS" wrote: >Dave, > >I support your direction > (somehow, the use case draft needs to cover the shaper/non-work >conserving scheduler) > because it will get the issue on the table for discussion. > >I'm just quibbling over the terminology. > Congestion and shapers are similar in effect but different in cause >and therefore response. > For congestion, the optimal application response is send slower now >and try faster later. > For a shaper, the optimal application response is send slower now >and somehow ask for better service if you need to go faster. > I seems worth keeping the two separate in terminology for the time >being. > >Regards, > >Stuart > >-----Original Message----- >From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com] >Sent: Wednesday, March 02, 2011 8:02 AM >To: STUART VENTERS; conex@ietf.org >Subject: Re: [conex] Discussion of new Use Cases pt 1 > > >Hi Stuart, > >An individual flow will experience the effect of loss or increased delay >if a shaper (more generally a non-work conserving scheduler) that is >similar to congestion of a shared resource. The current use case draft >only mentions congestion of a shared resources. This only covers a >(subset) of the things which both "feel" like congestion to a an >individual flow. =20 > >IMHO, somehow the use case (and mechanism) draft need to describe and >address this shaper/non-work conserving scheduler case which will appear >as congestion to an individual flow. One simple way to address this would >be to declare it out of scope, but then in my opinion the wg has not >addressed an important use case that will be difficult to distinguish from >shared resource congestion. > > >Thanks, > >Dave > >On 3/1/11 11:56 AM, "STUART VENTERS" wrote: > >>All, >> >>After thinking about Allissa and Dave's discussion, here's my 2c for a >>CONEX congestion definition: >> >> >> >> >>Definition for the kind of congestion that CONEX is trying to expose in a >>statistically multiplexed routing cloud: >> >>Congestion is when a packet's forwarding behavior is adversely affected >>because of the traffic load caused by other packets in the cloud. >> 'Adversely affected' means dropped or delayed more than the minimum >>delay seen in an otherwise idle cloud. >> 'Other packets' means either packets from other users or packets from >>the same user. >> >>When a packet gets affected simply because a shaper or policer says that >>a specific flow or user is sending more bits that the traffic contract >>allows,=20 >> that doesn't feel like congestion, but rather traffic management. >> >>On the other hand, if the shaper were affecting packets because it sees >>the cloud is near or at congestion, then that effect feels like >>congestion. >> (Because traffic management is telling the user that there is, or >>soon will be congestion.) >> >> >> >>The definition is focused on the discussion, so I may have completely >>missed some other aspect of congestion? >> >>Under this definition, it might turn out that CONEX needs to expose both >>traffic management and congestion behaviors. >> I don't yet see the need for this, but could easily be persuaded by a >>use case. >> It would just be unfortunate if we had to muddy the definitions for the >>two in order to include the TM behaviors. >> >> >>Cheers, >> >>Stuart >>_______________________________________________ >>conex mailing list >>conex@ietf.org >>https://www.ietf.org/mailman/listinfo/conex > From dave.mcdysan@verizon.com Wed Mar 2 10:03:09 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 879203A680C for ; Wed, 2 Mar 2011 10:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.827 X-Spam-Level: X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=-0.468, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8jJ+6afw7LQ for ; Wed, 2 Mar 2011 10:03:08 -0800 (PST) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id 313AB3A67FB for ; Wed, 2 Mar 2011 10:03:06 -0800 (PST) Received: from fldsmtpi03.verizon.com (fldsmtpi03.verizon.com [166.68.71.145]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p22I4C7g028362 for ; Wed, 2 Mar 2011 13:04:12 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,254,1297036800"; d="scan'208";a="4165404" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi03.verizon.com with ESMTP; 02 Mar 2011 18:04:12 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.147]) by FHDP1LUMXC7HB03.us.one.verizon.com ([2002:a644:3bbe::a644:3bbe]) with mapi; Wed, 2 Mar 2011 13:04:11 -0500 To: Mirja Kuehlewind , "conex@ietf.org" , Toby Moncaster Date: Wed, 2 Mar 2011 13:04:08 -0500 Thread-Topic: [conex] Discussion of new Use Cases pt 1 Thread-Index: AcvZBDwUPJC2eSNzSfC0tHAGxA89IA== Message-ID: In-Reply-To: <201103021749.54967.mirja.kuehlewind@ikr.uni-stuttgart.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 18:03:09 -0000 Hi Mirja, On 3/2/11 11:49 AM, "Mirja Kuehlewind" wrote: >Hi Dave, > >> >> >However I think it may be possible to derive >> >> >something that gives the same information as Dave is looking for >>without >> >> >needing an additional explicit signal. >> >> >> >> This is a good example of how I would see the use case and mechanism >> >> drafts inter-relating. If the same mechanism signaling can be used to >> >> meet >> >> other use cases, then IMHO then this makes the abstract mechanism >>more >> >> attractive. However, if the use case cannot be (well) handled by the >> >> abstract mechanism, then that is also useful information. >> > >> >I agree it would be good to have some idea of how broad the >>applicability >> >of >> >the abstract mechanism is. I actually think that there is very little >>real >> >disagreement between what we are both saying. The only significant >> >difference seems to be you are suggesting an explicit measure of >>long-term >> >"heaviness" of use, whereas I feel that such a measure can be derived >>from >> >the short term congestion measure. >> >> I am OK with a comparable measure that can be derived from the abstract >> mechanism draft. But we should agree as to what the form of the result >>of >> such a variation would like. That is, what are the characterisitics. > >I agree with Toby here. You can derive something like "heaviness" >or "burtiness" from the (long-term evaluation of) ConEx information. Thus >the=20 >use case would be that those information can be derived. The use case >should=20 >_NOT_ cover _HOW_ those information will be derived as this is a >different=20 >mechanism and out of scope. I don't believe that saying a derivation is possible is sufficient. I believe the working group needs to see some level of description of the derivation to confirm this assertion. (It is not immediately obvious to me.) If you are saying that the derivation need not be a description to the level of detail of the abstract mechanism draft, then I agree. I believe that John Leslie made the point that the use case draft would be a good place to capture such derivation (outlines), and I agree with that recommendation on wg document organization and content Thanks, Dave > >Mirja > From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Mar 2 10:18:41 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF5823A67DF for ; Wed, 2 Mar 2011 10:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5Z1src0XBzV for ; Wed, 2 Mar 2011 10:18:40 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id 1DEE63A67D3 for ; Wed, 2 Mar 2011 10:18:39 -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 95BEE633B1 for ; Wed, 2 Mar 2011 19:19:44 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 6C43A59A8A for ; Wed, 2 Mar 2011 19:19:44 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: conex@ietf.org Date: Wed, 2 Mar 2011 19:19:43 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20090731.1005176) References: 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: <201103021919.43890.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 18:18:41 -0000 Hi, On Wednesday 02 March 2011 18:58:44 Mcdysan, David E wrote: > Hi Stuart, > > I agree that although the user perceived effect is different, the cause > is important and the response may indeed be different. We need to document > this. There may be a need to distinguish how these are signaled as well. If you have a different element, giving you a different signal and you want= a=20 different response, isn't this simply a different mechanism and not ConEx??= ?=20 When you talk about shaping that's not congestion and thus no case for=20 Congestion Exposure. > For example, if loss is implicitly determined by the receiver then there > currently may not be a way to distinguish between congestion of a shared > queue and shaper buffer overflow. Loss is loss for the receiver... how can you distinguish how a packet got=20 lost? And as you don't know how the packet got lost, you have to be=20 conservative and assume its because of congestion. This might be a quite radical view but it keeps thing more simple. Mirja > > Your last comment "somehow ask for better service if you need to go > faster" made me think of who would pay for making the service "go faster." > There is a burst mode service offered by some ISPs; and in some cases the > user pays and in others it involves recharging (i.e., someone else pays). > > This reminds me of a comment as recorded in the Beijing minutes by an > unnamed person from Ericsson that recharging had been tried for 100 years > in telephony and it did not work and would not work in the Internet. I did > not have time to respond in the meeting, and am doing so here. Isn't toll > free service in telephony a form of recharging (i.e., called party pays > instead of caller)? Are you saying that toll-free service has not worked? > The assertion made by that speaker was that therefore recharging should > not be considered. I think that in at least the consideration of who pays > for adjusting the rate of a shaper that it is something to be mentioned. > Any disagreement? > > Thanks, > > Dave > > On 3/2/11 12:09 PM, "STUART VENTERS" wrote: > >Dave, > > > >I support your direction > > (somehow, the use case draft needs to cover the shaper/non-work > >conserving scheduler) > > because it will get the issue on the table for discussion. > > > >I'm just quibbling over the terminology. > > Congestion and shapers are similar in effect but different in cause > >and therefore response. > > For congestion, the optimal application response is send slower now > >and try faster later. > > For a shaper, the optimal application response is send slower now > >and somehow ask for better service if you need to go faster. > > I seems worth keeping the two separate in terminology for the time > >being. > > > >Regards, > > > >Stuart > > > >-----Original Message----- > >From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com] > >Sent: Wednesday, March 02, 2011 8:02 AM > >To: STUART VENTERS; conex@ietf.org > >Subject: Re: [conex] Discussion of new Use Cases pt 1 > > > > > >Hi Stuart, > > > >An individual flow will experience the effect of loss or increased delay > >if a shaper (more generally a non-work conserving scheduler) that is > >similar to congestion of a shared resource. The current use case draft > >only mentions congestion of a shared resources. This only covers a > >(subset) of the things which both "feel" like congestion to a an > >individual flow. > > > >IMHO, somehow the use case (and mechanism) draft need to describe and > >address this shaper/non-work conserving scheduler case which will appear > >as congestion to an individual flow. One simple way to address this would > >be to declare it out of scope, but then in my opinion the wg has not > >addressed an important use case that will be difficult to distinguish fr= om > >shared resource congestion. > > > > > >Thanks, > > > >Dave > > > >On 3/1/11 11:56 AM, "STUART VENTERS" wrote: > >>All, > >> > >>After thinking about Allissa and Dave's discussion, here's my 2c for a > >>CONEX congestion definition: > >> > >> > >> > >> > >>Definition for the kind of congestion that CONEX is trying to expose in= a > >>statistically multiplexed routing cloud: > >> > >>Congestion is when a packet's forwarding behavior is adversely affected > >>because of the traffic load caused by other packets in the cloud. > >> 'Adversely affected' means dropped or delayed more than the minimum > >>delay seen in an otherwise idle cloud. > >> 'Other packets' means either packets from other users or packets from > >>the same user. > >> > >>When a packet gets affected simply because a shaper or policer says that > >>a specific flow or user is sending more bits that the traffic contract > >>allows, > >> that doesn't feel like congestion, but rather traffic management. > >> > >>On the other hand, if the shaper were affecting packets because it sees > >>the cloud is near or at congestion, then that effect feels like > >>congestion. > >> (Because traffic management is telling the user that there is, or > >>soon will be congestion.) > >> > >> > >> > >>The definition is focused on the discussion, so I may have completely > >>missed some other aspect of congestion? > >> > >>Under this definition, it might turn out that CONEX needs to expose both > >>traffic management and congestion behaviors. > >> I don't yet see the need for this, but could easily be persuaded by a > >>use case. > >> It would just be unfortunate if we had to muddy the definitions for t= he > >>two in order to include the TM behaviors. > >> > >> > >>Cheers, > >> > >>Stuart > >>_______________________________________________ > >>conex mailing list > >>conex@ietf.org > >>https://www.ietf.org/mailman/listinfo/conex > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex =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 dave.mcdysan@verizon.com Wed Mar 2 10:50:15 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 336BD3A6831 for ; Wed, 2 Mar 2011 10:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.414 X-Spam-Level: X-Spam-Status: No, score=-3.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBT8xSChZ6yc for ; Wed, 2 Mar 2011 10:50:13 -0800 (PST) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id 786CC3A6800 for ; Wed, 2 Mar 2011 10:50:09 -0800 (PST) Received: from fldsmtpi02.verizon.com (fldsmtpi02.verizon.com [166.68.71.144]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p22Ip5eC019314 for ; Wed, 2 Mar 2011 13:51:05 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,254,1297036800"; d="scan'208";a="4207982" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi02.verizon.com with ESMTP; 02 Mar 2011 18:51:05 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.147]) by FHDP1LUMXC7HB03.us.one.verizon.com ([2002:a644:3bbe::a644:3bbe]) with mapi; Wed, 2 Mar 2011 13:51:05 -0500 To: Toby Moncaster , "'STUART VENTERS'" Date: Wed, 2 Mar 2011 13:50:57 -0500 Thread-Topic: [conex] Discussion of new Use Cases pt 1 Thread-Index: AcvZCscEfx7nRZ1bQlegt+aIyEpk5Q== Message-ID: In-Reply-To: <004201cbd8fe$bde5fc10$39b1f430$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 18:50:15 -0000 We have had a lot of good discussion on the list and I recommend that we need to capture this in the working group use case draft. I support adding a separate section in the use case draft to capture the impact of non-work conserving schedulers (e.g., shapers, hierarchical schedulers, etc.). This new section should include: * Discussion on the inequity of heavy versus light users motivation (proposing text Toby sent out as starting point for this and related technical points from the discussion) * Text describing burstiness as a potential measure (proposing text that I sent 2/25 as starting point) * Add text that distinguishes between the current drafts' scope (shared resource congestion) and individual congestion-like behavior (as proposed by Stuart and Toby) * Add a placeholder for text to be developed (see Bobs' comment in meeting minutes, Tobys' posts) that describes how the abstract mechanism measures could be used to derive a "burstiness" or "heaviness" measure. Unless I hear objections to developing text in a new, separate section, I volunteer to do so. Thanks, Dave =20 On 3/2/11 12:24 PM, "Toby Moncaster" wrote: > > >> -----Original Message----- >> From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf >> Of STUART VENTERS >> Sent: 02 March 2011 17:09 >> To: Mcdysan, David E >> Cc: conex@ietf.org >> Subject: Re: [conex] Discussion of new Use Cases pt 1 >>=20 >> Dave, >>=20 >> I support your direction >> (somehow, the use case draft needs to cover the shaper/non-work >> conserving scheduler) >> because it will get the issue on the table for discussion. >>=20 >> I'm just quibbling over the terminology. >> Congestion and shapers are similar in effect but different in cause >> and therefore response. >> For congestion, the optimal application response is send slower >> now and try faster later. >> For a shaper, the optimal application response is send slower now >> and somehow ask for better service if you need to go faster. > >Furthermore, the fact you have been shaped is not correlated with whether >you have had an adverse impact on other users. Consequently if you include >that form of congestion information in the ConEx signal then it needs to >be >reacted to differently by the rest of the network... > >My current instinct is that we should include of Dave's burstiness >measure, >but give it its own section that looks at forms of congestion beyond the >classical queue-related congestion represented by packet drop, queue delay >and ECN marking. I guess that is what you are implying in the sentence >below... > >> I seems worth keeping the two separate in terminology for the time >> being. >>=20 >> Regards, >>=20 >> Stuart >>=20 >> -----Original Message----- >> From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com] >> Sent: Wednesday, March 02, 2011 8:02 AM >> To: STUART VENTERS; conex@ietf.org >> Subject: Re: [conex] Discussion of new Use Cases pt 1 >>=20 >>=20 >> Hi Stuart, >>=20 >> An individual flow will experience the effect of loss or increased >> delay >> if a shaper (more generally a non-work conserving scheduler) that is >> similar to congestion of a shared resource. The current use case draft >> only mentions congestion of a shared resources. This only covers a >> (subset) of the things which both "feel" like congestion to a an >> individual flow. >>=20 >> IMHO, somehow the use case (and mechanism) draft need to describe and >> address this shaper/non-work conserving scheduler case which will >> appear >> as congestion to an individual flow. One simple way to address this >> would >> be to declare it out of scope, but then in my opinion the wg has not >> addressed an important use case that will be difficult to distinguish >> from >> shared resource congestion. >>=20 >>=20 >> Thanks, >>=20 >> Dave >>=20 >> On 3/1/11 11:56 AM, "STUART VENTERS" wrote: >>=20 >> >All, >> > >> >After thinking about Allissa and Dave's discussion, here's my 2c for a >> >CONEX congestion definition: >> > >> > >> > >> > >> >Definition for the kind of congestion that CONEX is trying to expose >> in a >> >statistically multiplexed routing cloud: >> > >> >Congestion is when a packet's forwarding behavior is adversely >> affected >> >because of the traffic load caused by other packets in the cloud. >> > 'Adversely affected' means dropped or delayed more than the minimum >> >delay seen in an otherwise idle cloud. >> > 'Other packets' means either packets from other users or packets >> from >> >the same user. >> > >> >When a packet gets affected simply because a shaper or policer says >> that >> >a specific flow or user is sending more bits that the traffic contract >> >allows, >> > that doesn't feel like congestion, but rather traffic management. >> > >> >On the other hand, if the shaper were affecting packets because it >> sees >> >the cloud is near or at congestion, then that effect feels like >> >congestion. >> > (Because traffic management is telling the user that there is, or >> >soon will be congestion.) >> > >> > >> > >> >The definition is focused on the discussion, so I may have completely >> >missed some other aspect of congestion? >> > >> >Under this definition, it might turn out that CONEX needs to expose >> both >> >traffic management and congestion behaviors. >> > I don't yet see the need for this, but could easily be persuaded by >> a >> >use case. >> > It would just be unfortunate if we had to muddy the definitions for >> the >> >two in order to include the TM behaviors. >> > >> > >> >Cheers, >> > >> >Stuart >> >_______________________________________________ >> >conex mailing list >> >conex@ietf.org >> >https://www.ietf.org/mailman/listinfo/conex >>=20 >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex > From stuart.venters@adtran.com Wed Mar 2 12:04:12 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08AF33A6888 for ; Wed, 2 Mar 2011 12:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUs2GRKmt3RK for ; Wed, 2 Mar 2011 12:04:10 -0800 (PST) Received: from p02c12o141.mxlogic.net (p02c12o141.mxlogic.net [208.65.145.74]) by core3.amsl.com (Postfix) with ESMTP id 5FF8D3A6882 for ; Wed, 2 Mar 2011 12:04:08 -0800 (PST) Received: from unknown [76.164.174.82] by p02c12o141.mxlogic.net(mxl_mta-6.9.0-1) with SMTP id af2ae6d4.0.8068.00-382.20536.p02c12o141.mxlogic.net (envelope-from ); Wed, 02 Mar 2011 13:05:15 -0700 (MST) X-MXL-Hash: 4d6ea2fb70872259-4709a6988be982c96cf7215b4788ae8e3a65e4e3 Received: from corp-exfr2.corp.adtran.com (172.23.101.22) by ex-hc3.corp.adtran.com (172.22.50.73) with Microsoft SMTP Server id 14.1.270.1; Wed, 2 Mar 2011 14:04:39 -0600 Received: from EXV1.corp.adtran.com ([172.22.48.215]) by corp-exfr2.corp.adtran.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Mar 2011 14:04:30 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Mar 2011 14:04:29 -0600 Message-ID: <8F242B230AD6474C8E7815DE0B4982D7179FB935@EXV1.corp.adtran.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] Discussion of new Use Cases pt 1 Thread-Index: AcvZA3nW5rZZwxnRRFmeD0DWgpybDwAENcCw From: STUART VENTERS To: "Mcdysan, David E" X-OriginalArrivalTime: 02 Mar 2011 20:04:30.0223 (UTC) FILETIME=[0A66A1F0:01CBD915] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [(unknown)] X-AnalysisOut: [v=1.0 c=1 a=G9T4uwCCN8UA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-] X-AnalysisOut: [IA:10 a=J+LXdEUA8t8MtBPt16/Qbg==:17 a=ZsyXEVtvAAAA:8 a=48v] X-AnalysisOut: [gC7mUAAAA:8 a=eJNrpioGAAAA:8 a=y5UPZ0taS37QMkuGII4A:9 a=Ri] X-AnalysisOut: [vAAHw4cPscGuO_-2YA:7 a=hdArPYI0I8tFw4ky3KW_kEmIn60A:4 a=wP] X-AnalysisOut: [NLvfGTeEIA:10 a=TRFw3Wk1wdAA:10 a=lZB815dzVvQA:10 a=DvnSUQ] X-AnalysisOut: [UdWHYA:10 a=26QQG33TvGwt9a56:21 a=lGFoNe0Z9K96KymA:21] Cc: conex@ietf.org Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 20:04:12 -0000 Dave, Not sure I understand the 3rd paragraph enough to agree or not. Perhaps a discussion about the psychology getting folks to part with = their money would be a good subject for a beer BOF. Hopefully, CONEX is more about making the service we already have work = better. Regards, Stuart -----Original Message----- From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com] Sent: Wednesday, March 02, 2011 11:59 AM To: STUART VENTERS Cc: conex@ietf.org Subject: Re: [conex] Discussion of new Use Cases pt 1 Hi Stuart, I agree that although the user perceived effect is different, the cause is important and the response may indeed be different. We need to = document this. There may be a need to distinguish how these are signaled as well. For example, if loss is implicitly determined by the receiver then there currently may not be a way to distinguish between congestion of a shared queue and shaper buffer overflow. Your last comment "somehow ask for better service if you need to go faster" made me think of who would pay for making the service "go = faster." There is a burst mode service offered by some ISPs; and in some cases = the user pays and in others it involves recharging (i.e., someone else = pays). This reminds me of a comment as recorded in the Beijing minutes by an unnamed person from Ericsson that recharging had been tried for 100 = years in telephony and it did not work and would not work in the Internet. I = did not have time to respond in the meeting, and am doing so here. Isn't = toll free service in telephony a form of recharging (i.e., called party pays instead of caller)? Are you saying that toll-free service has not = worked? The assertion made by that speaker was that therefore recharging should not be considered. I think that in at least the consideration of who = pays for adjusting the rate of a shaper that it is something to be mentioned. Any disagreement? Thanks, Dave On 3/2/11 12:09 PM, "STUART VENTERS" wrote: >Dave, > >I support your direction > (somehow, the use case draft needs to cover the shaper/non-work >conserving scheduler) > because it will get the issue on the table for discussion. > >I'm just quibbling over the terminology. > Congestion and shapers are similar in effect but different in cause >and therefore response. > For congestion, the optimal application response is send slower = now >and try faster later. > For a shaper, the optimal application response is send slower now >and somehow ask for better service if you need to go faster. > I seems worth keeping the two separate in terminology for the time >being. > >Regards, > >Stuart > >-----Original Message----- >From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com] >Sent: Wednesday, March 02, 2011 8:02 AM >To: STUART VENTERS; conex@ietf.org >Subject: Re: [conex] Discussion of new Use Cases pt 1 > > >Hi Stuart, > >An individual flow will experience the effect of loss or increased = delay >if a shaper (more generally a non-work conserving scheduler) that is >similar to congestion of a shared resource. The current use case draft >only mentions congestion of a shared resources. This only covers a >(subset) of the things which both "feel" like congestion to a an >individual flow. =20 > >IMHO, somehow the use case (and mechanism) draft need to describe and >address this shaper/non-work conserving scheduler case which will = appear >as congestion to an individual flow. One simple way to address this = would >be to declare it out of scope, but then in my opinion the wg has not >addressed an important use case that will be difficult to distinguish = from >shared resource congestion. > > >Thanks, > >Dave > >On 3/1/11 11:56 AM, "STUART VENTERS" wrote: > >>All, >> >>After thinking about Allissa and Dave's discussion, here's my 2c for a >>CONEX congestion definition: >> >> >> >> >>Definition for the kind of congestion that CONEX is trying to expose = in a >>statistically multiplexed routing cloud: >> >>Congestion is when a packet's forwarding behavior is adversely = affected >>because of the traffic load caused by other packets in the cloud. >> 'Adversely affected' means dropped or delayed more than the minimum >>delay seen in an otherwise idle cloud. >> 'Other packets' means either packets from other users or packets = from >>the same user. >> >>When a packet gets affected simply because a shaper or policer says = that >>a specific flow or user is sending more bits that the traffic contract >>allows,=20 >> that doesn't feel like congestion, but rather traffic management. >> >>On the other hand, if the shaper were affecting packets because it = sees >>the cloud is near or at congestion, then that effect feels like >>congestion. >> (Because traffic management is telling the user that there is, or >>soon will be congestion.) >> >> >> >>The definition is focused on the discussion, so I may have completely >>missed some other aspect of congestion? >> >>Under this definition, it might turn out that CONEX needs to expose = both >>traffic management and congestion behaviors. >> I don't yet see the need for this, but could easily be persuaded by = a >>use case. >> It would just be unfortunate if we had to muddy the definitions for = the >>two in order to include the TM behaviors. >> >> >>Cheers, >> >>Stuart >>_______________________________________________ >>conex mailing list >>conex@ietf.org >>https://www.ietf.org/mailman/listinfo/conex > From cait@asomi.com Wed Mar 2 12:22:55 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 823153A6823 for ; Wed, 2 Mar 2011 12:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2zYYTFgjrib for ; Wed, 2 Mar 2011 12:22:53 -0800 (PST) Received: from mail3.sea5.speakeasy.net (mail3.sea5.speakeasy.net [69.17.117.42]) by core3.amsl.com (Postfix) with ESMTP id C74D23A6824 for ; Wed, 2 Mar 2011 12:22:50 -0800 (PST) Received: (qmail 17784 invoked from network); 2 Mar 2011 20:17:14 -0000 Received: from imac.asomi.com (cait@asomi.com@[66.92.48.27]) (envelope-sender ) by mail3.sea5.speakeasy.net (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 2 Mar 2011 20:17:13 -0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Caitlin Bestler In-Reply-To: <20110301173738.GO7663@verdi> Date: Wed, 2 Mar 2011 12:17:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <86D4248D-F176-46A0-AC1D-B8C9F41D9287@asomi.com> References: <64069EFF-C572-4088-9EF0-9CDE66B20390@cdt.org> <8F242B230AD6474C8E7815DE0B4982D7179FB92C@EXV1.corp.adtran.com> <20110301173738.GO7663@verdi> To: John Leslie X-Mailer: Apple Mail (2.1082) Cc: conex@ietf.org Subject: Re: [conex] "Congestion" definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 20:22:55 -0000 On Mar 1, 2011, at 9:37 AM, John Leslie wrote: > STUART VENTERS wrote: >>=20 >> Definition for the kind of congestion that CONEX is trying to expose >> in a statistically multiplexed routing cloud: >>=20 >> Congestion is when a packet's forwarding behavior is adversely = affected >> because of the traffic load caused by other packets in the cloud. >> - 'Adversely affected' means dropped or delayed more than the minimum >> delay seen in an otherwise idle cloud. >> - 'Other packets' means either packets from other users or packets = from >> the same user. >=20 > This is a good start at discussing what we think we're talking = about. >=20 > So, let me take it as a start, rather than criticize its = completeness. >=20 > (I should perhaps criticize "Congestion is when", but let me reserve > that issue for later.) >=20 > There is indeed good work going on to derive a measure of = "congestion" > from transit-time, assuming that transit-time includes only minimum > latency plus queueing delays. (There are obvious problems with that > assumption, which I won't discuss.) >=20 > Assuming we could actually collect useful queueing-delay numbers, it > is quite reasonable to assume them to represent a type of = "congestion". >=20 > BTW, I have discussed defining "congestion" on the ICCRG list, > starting Sat, 4 Feb 2006 16:03:28 -0500: > ]=20 > ] To me, congestion is the condition where a packet can't be sent > ] "immediately" (meaning perhaps that it can't be queued as the next > ] packet to be sent). >=20 > (I derive that from a dictionary definition of "congestion: to > cause an excessive accumulation...") >=20 > We could reasonably come up with a better definition of = "immediately", > but I contend that it would be different for every class of traffic, = so > I start from the most restrictive. >=20 > But I digress... >=20 > I don't believe time spent on arguing how much queueing corresponds > to "zero" congestion is helpful. >=20 > Regardless, we do hit a discontinuity when the queue "fills" and a > packet is dropped; and many folks use "congestion" to refer to that > discontinuity. >=20 > ECN came along to moderate that discontinuity: instead of dropping > the packet, we'd enforce Random-Early-Detection and at the = tipping-point > of RED we'd ECN-mark the packet instead of dropping it. Assuming well- > behaved sender-receiver pairings this would reduce the need to drop > packets more-quickly than TCP-like protocols could do by detecting a > drop. >=20 > ECN deployment is spotty-at-best -- possibly because nobody sees a > reason to trust the sender-receiver pairings... >=20 > Getting back to Stuart's definition: >=20 > I think "caused by" is the wrong wording. Necessarily, it is the > fact that packet-arrival-rate exceeds packet-forwarding-rate that > "causes" queuing delays. It makes no sense to try to assign "blame" > for this to individual senders -- except in the limiting case where > a sender's packet-sending-rate exceeds the available-forwarding-rate > of a particular forwarder; and for that limiting-case it's not useful > to assign "blame" until the sender has had sufficient time to learn > the available-forwarding-rate. >=20 > Bottom line: a good start, Stuart! >=20 >=20 Two aspects of this definition strike me as needing refinement. First, other packets come from other flows. Switches/routers do not know what this "user" entity is. Secondly the definition of "delay" is far too inclusive. It could be = interpreted as simply delay waiting for a round-robin turn at the transmitter. QCN (802.1Qau) focuses strictly on queue depth (whether the queue is actual or virtual). I think that is appropriate. The results of = round-robin algorithms are already felt in the queue depth, so there is no need to separately measure them. Queue depth is also easily measured. Combined with a delta measurment the results give a very complete understanding of the network, and even = the delta can be measured inexpensively. Predicting delay caused by other queues that share a given transmitter is fairly complex, and ultimately unnecessary. The queue is either backing up (which can already be measured) or it is not. -- Caitlin Bestler cait@asomi.com -- Caitlin Bestler cait@asomi.com http://www.asomi.com/CaitlinBestlerResume.html From lists@syshex.com Wed Mar 2 21:22:01 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED1CB3A695E for ; Wed, 2 Mar 2011 21:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3G4w9FT7MsIa for ; Wed, 2 Mar 2011 21:21:59 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 9524A3A67ED for ; Wed, 2 Mar 2011 21:21:59 -0800 (PST) Received: by yic13 with SMTP id 13so283524yic.31 for ; Wed, 02 Mar 2011 21:23:06 -0800 (PST) Received: by 10.236.200.200 with SMTP id z48mr1072203yhn.10.1299129786109; Wed, 02 Mar 2011 21:23:06 -0800 (PST) Received: from localhost ([136.187.112.184]) by mx.google.com with ESMTPS id z5sm537531yhc.35.2011.03.02.21.23.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Mar 2011 21:23:04 -0800 (PST) Content-Type: text/plain; charset=UTF-8 From: =?utf-8?q?Jo=C3=A3o_Taveira_Ara=C3=BAjo?= To: conex In-reply-to: <004201cbd8fe$bde5fc10$39b1f430$@com> References: <8F242B230AD6474C8E7815DE0B4982D7179FB934@EXV1.corp.adtran.com> <004201cbd8fe$bde5fc10$39b1f430$@com> Date: Thu, 03 Mar 2011 14:23:00 +0900 Message-Id: <1299129398-sup-3190@moonloop.syshex.com> User-Agent: Sup/0.11 Content-Transfer-Encoding: 8bit Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 03 Mar 2011 05:22:02 -0000 To play devil's advocate here .... Excerpts from Toby Moncaster's message of Wed Mar 02 17:24:50 UTC 2011: > > Congestion and shapers are similar in effect but different in cause > > and therefore response. > > For congestion, the optimal application response is send slower > > now and try faster later. > > For a shaper, the optimal application response is send slower now > > and somehow ask for better service if you need to go faster. Isn't a shaper just an induced bottleneck? I agree that it would be useful to know the nature of what is holding you back, but I don't think the response can be different unless you know very specific details of the shaper which would be outside the scope of ConEx (and have probably been pursued before). > Furthermore, the fact you have been shaped is not correlated with whether > you have had an adverse impact on other users. Consequently if you include > that form of congestion information in the ConEx signal then it needs to be > reacted to differently by the rest of the network... Clearly you are having an adverse impact ... on the network's business model. Conflating all these causes into a single metric is not ideal, but I think it's a lot better than trying to fine-tune separate signals and risk using none (should checksum errors due to BER be treated as congestion?). In the long term it seems simpler to provide a seemingly loose definition of what this single metric means than trying to very neatly compartmentalize what exists today. On a side note, a shaper in a conex setting should be much more readily identifiable than at present, and would probably be used more sparingly if congestion were used in addition to bandwidth to assess the quality of an ISP. J. > My current instinct is that we should include of Dave's burstiness measure, > but give it its own section that looks at forms of congestion beyond the > classical queue-related congestion represented by packet drop, queue delay > and ECN marking. I guess that is what you are implying in the sentence > below... > > > I seems worth keeping the two separate in terminology for the time > > being. > > > > Regards, > > > > Stuart > > > > -----Original Message----- > > From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com] > > Sent: Wednesday, March 02, 2011 8:02 AM > > To: STUART VENTERS; conex@ietf.org > > Subject: Re: [conex] Discussion of new Use Cases pt 1 > > > > > > Hi Stuart, > > > > An individual flow will experience the effect of loss or increased > > delay > > if a shaper (more generally a non-work conserving scheduler) that is > > similar to congestion of a shared resource. The current use case draft > > only mentions congestion of a shared resources. This only covers a > > (subset) of the things which both "feel" like congestion to a an > > individual flow. > > > > IMHO, somehow the use case (and mechanism) draft need to describe and > > address this shaper/non-work conserving scheduler case which will > > appear > > as congestion to an individual flow. One simple way to address this > > would > > be to declare it out of scope, but then in my opinion the wg has not > > addressed an important use case that will be difficult to distinguish > > from > > shared resource congestion. > > > > > > Thanks, > > > > Dave > > > > On 3/1/11 11:56 AM, "STUART VENTERS" wrote: > > > > >All, > > > > > >After thinking about Allissa and Dave's discussion, here's my 2c for a > > >CONEX congestion definition: > > > > > > > > > > > > > > >Definition for the kind of congestion that CONEX is trying to expose > > in a > > >statistically multiplexed routing cloud: > > > > > >Congestion is when a packet's forwarding behavior is adversely > > affected > > >because of the traffic load caused by other packets in the cloud. > > > 'Adversely affected' means dropped or delayed more than the minimum > > >delay seen in an otherwise idle cloud. > > > 'Other packets' means either packets from other users or packets > > from > > >the same user. > > > > > >When a packet gets affected simply because a shaper or policer says > > that > > >a specific flow or user is sending more bits that the traffic contract > > >allows, > > > that doesn't feel like congestion, but rather traffic management. > > > > > >On the other hand, if the shaper were affecting packets because it > > sees > > >the cloud is near or at congestion, then that effect feels like > > >congestion. > > > (Because traffic management is telling the user that there is, or > > >soon will be congestion.) > > > > > > > > > > > >The definition is focused on the discussion, so I may have completely > > >missed some other aspect of congestion? > > > > > >Under this definition, it might turn out that CONEX needs to expose > > both > > >traffic management and congestion behaviors. > > > I don't yet see the need for this, but could easily be persuaded by > > a > > >use case. > > > It would just be unfortunate if we had to muddy the definitions for > > the > > >two in order to include the TM behaviors. > > > > > > > > >Cheers, > > > > > >Stuart > > >_______________________________________________ > > >conex mailing list > > >conex@ietf.org > > >https://www.ietf.org/mailman/listinfo/conex > > > > _______________________________________________ > > conex mailing list > > conex@ietf.org > > https://www.ietf.org/mailman/listinfo/conex > From cait@asomi.com Wed Mar 2 23:35:28 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93B0D3A68EC for ; Wed, 2 Mar 2011 23:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQl+AYGlH2Ec for ; Wed, 2 Mar 2011 23:35:27 -0800 (PST) Received: from mail2.sea5.speakeasy.net (mail2.sea5.speakeasy.net [69.17.117.41]) by core3.amsl.com (Postfix) with ESMTP id 7C3FD3A6403 for ; Wed, 2 Mar 2011 23:35:24 -0800 (PST) Received: (qmail 2725 invoked from network); 3 Mar 2011 07:36:30 -0000 Received: from imac.asomi.com (cait@asomi.com@[66.92.48.27]) (envelope-sender ) by mail2.sea5.speakeasy.net (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 3 Mar 2011 07:36:30 -0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Caitlin Bestler In-Reply-To: Date: Wed, 2 Mar 2011 23:36:28 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: To: "Mcdysan, David E" X-Mailer: Apple Mail (2.1082) Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 03 Mar 2011 07:35:28 -0000 On Mar 2, 2011, at 5:11 AM, Mcdysan, David E wrote: > Hi Toby, > > In line, snipping some material already covered. > > Dave > > On 3/1/11 4:58 AM, "Toby Moncaster" wrote: > >> Hi Dave, >> >> Inline > > > Snipped > >> >>>> I agree that Dave's peak/average rate signal doesn't seem to fit into >>> the >>>> same sort of signalling framework. For one thing Dave seems to just >>> imply >>>> this would be a binary state. >>> >>> >>> I.m not sure I understand this comment. Could you please expand on what >>> are the states. >> >> If I understood you correctly, you were suggesting that users would be >> classified as "heavy" or "not heavy", with their traffic marked >> appropriately? > > NOw I understand your point. I was proposing burstiness as (one possible) > measure of "heaviness." It could be quantized as two values, and the title > "heavy vs light" does imply this. However, I would not want to preclude > more levels of quantization or a conex response that was some related to > such a "heaviness" measure in a more continuous manner. > Burstiness is only "heavy" when it is uncorrelated with network congestion. An ideal LEDBAT-algorithm would be perceived as being 'bursty'. Therefore I believe equating any form of burstiness that a router could measure with being a "heavy" user is a poor metric. -- Caitlin Bestler cait@asomi.com -- Caitlin Bestler cait@asomi.com http://www.asomi.com/CaitlinBestlerResume.html From toby@moncaster.com Thu Mar 3 01:18:30 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F5623A6997 for ; Thu, 3 Mar 2011 01:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psNJJMrfyvxp for ; Thu, 3 Mar 2011 01:18:29 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id 47B353A6882 for ; Thu, 3 Mar 2011 01:18:29 -0800 (PST) Received: from TobysHP (host81-158-50-164.range81-158.btcentralplus.com [81.158.50.164]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MRQIm-1PSQx70MKu-00SjJ8; Thu, 03 Mar 2011 10:19:30 +0100 From: "Toby Moncaster" To: "'Caitlin Bestler'" , "'Mcdysan, David E'" References: In-Reply-To: Date: Thu, 3 Mar 2011 09:19:28 -0000 Message-ID: <001201cbd984$19e8d1b0$4dba7510$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcvZdbiAe+cJKUVfRMWoZrxlJ42TbAADaBCw Content-Language: en-gb X-Provags-ID: V02:K0:/cvkJ+6InrVQpwFyDHcmBQNfyCRMQo75/1vgl5f2qyR OCQ/fRW92XdcUcsDbqPR+lu2BiN+H4x2dKR6gXE7QNUYu9KTvp iZfGFbn08XohJ6n14quHX6OvCTzKR5WmPpZ3eInqaxQlUQ1v76 2Dw3cvxiRBfjTfue8UH7+2z+JxmMEGApcdgD0jXGPwFqIUEIN8 8x0wAGo/r92NLRKEDY2hPJvsKGW5ilJGIAu6TEIpN4= Cc: conex@ietf.org Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 03 Mar 2011 09:18:30 -0000 > -----Original Message----- > From: Caitlin Bestler [mailto:cait@asomi.com] > Sent: 03 March 2011 07:36 > To: Mcdysan, David E > Cc: Toby Moncaster; 'Alissa Cooper'; conex@ietf.org > Subject: Re: [conex] Discussion of new Use Cases pt 1 > > > > > > NOw I understand your point. I was proposing burstiness as (one > possible) > > measure of "heaviness." It could be quantized as two values, and the > title > > "heavy vs light" does imply this. However, I would not want to > preclude > > more levels of quantization or a conex response that was some related > to > > such a "heaviness" measure in a more continuous manner. > > > > > Burstiness is only "heavy" when it is uncorrelated with network > congestion. > An ideal LEDBAT-algorithm would be perceived as being 'bursty'. > Therefore > I believe equating any form of burstiness that a router could measure > with > being a "heavy" user is a poor metric. But when coupled with a measure of their actual contribution to congestion (what we call congestion volume in the draft) it gives a very good measure. You essentially end up with 4 groups - heavy users (high congestion, high burstinesss), LEDBAT users (low congestion, low burstiness), "bursty" users (low congestion, high burstiness) and light users (low congestion, low burstiness). Toby > > > -- > Caitlin Bestler > cait@asomi.com > > > > > -- > Caitlin Bestler > cait@asomi.com > http://www.asomi.com/CaitlinBestlerResume.html > From toby@moncaster.com Thu Mar 3 01:26:50 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C40C53A6882 for ; Thu, 3 Mar 2011 01:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.981 X-Spam-Level: X-Spam-Status: No, score=-1.981 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKEIiotqrboa for ; Thu, 3 Mar 2011 01:26:49 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id 5572F3A69A4 for ; Thu, 3 Mar 2011 01:26:49 -0800 (PST) Received: from TobysHP (host81-158-50-164.range81-158.btcentralplus.com [81.158.50.164]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0LtjF3-1Q2bGO0sGj-010iJV; Thu, 03 Mar 2011 10:27:53 +0100 From: "Toby Moncaster" To: =?iso-8859-1?Q?'Jo=E3o_Taveira_Ara=FAjo'?= , "'conex'" References: <8F242B230AD6474C8E7815DE0B4982D7179FB934@EXV1.corp.adtran.com> <004201cbd8fe$bde5fc10$39b1f430$@com> <1299129398-sup-3190@moonloop.syshex.com> In-Reply-To: <1299129398-sup-3190@moonloop.syshex.com> Date: Thu, 3 Mar 2011 09:27:53 -0000 Message-ID: <001301cbd985$45f234d0$d1d69e70$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcvZYxghVUQC31j+S86iL6NMMp1ULgAIQ5cg Content-Language: en-gb X-Provags-ID: V02:K0:jxBUqd3DinUBSiLDUOWFk/w8gqT4OQ7lq3IMI7Yma92 lY3rqCTKw1vOl00/QSem6qo9MOJAvNZfxq/S/nGfZ3WzddCNRg eRBH+j1aeLa/OSLpnaR7DU2ZJX17fqpriX//2DrfrD9BKFojfr llK9pE/W4LGq736eNKPqbu+3VfzgGcmi+hzj+vB8oC3lBab9VL z7m/9km+qw+tK9Lz5gqAEzVswI7g6X8s4CNOLzofOY= Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 03 Mar 2011 09:26:50 -0000 > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Jo=E3o Taveira Ara=FAjo > Sent: 03 March 2011 05:23 > To: conex > Subject: Re: [conex] Discussion of new Use Cases pt 1 >=20 > To play devil's advocate here .... >=20 > Excerpts from Toby Moncaster's message of Wed Mar 02 17:24:50 UTC = 2011: > > > Congestion and shapers are similar in effect but different in > cause > > > and therefore response. > > > For congestion, the optimal application response is send > slower > > > now and try faster later. > > > For a shaper, the optimal application response is send slower > now > > > and somehow ask for better service if you need to go faster. >=20 > Isn't a shaper just an induced bottleneck? I agree that it would be > useful to know the nature of what is holding you back, but I don't > think the response can be different unless you know very specific > details of the shaper which would be outside the scope of ConEx (and > have probably been pursued before). Indeed it is just an artificial bottleneck, so (depending on why it is there) the best response is probably to try and get your rate to as = close to that rate as possible >=20 > > Furthermore, the fact you have been shaped is not correlated with > whether > > you have had an adverse impact on other users. Consequently if you > include > > that form of congestion information in the ConEx signal then it = needs > to be > > reacted to differently by the rest of the network... >=20 > Clearly you are having an adverse impact ... on the network's business > model.=20 No, you may be being shaped to make sure you don't suffer loss on your = DSL link... Unless the UK is way out on a limb, ISPs seem to be moving = beyond imposing rate caps as part of their business model, instead relying on = the physical limits imposed by the access... > Conflating all these causes into a single metric is not ideal, > but I think it's a lot better than trying to fine-tune separate = signals > and risk using none (should checksum errors due to BER be treated as > congestion?). In the long term it seems simpler to provide a = seemingly > loose definition of what this single metric means than trying to very > neatly compartmentalize what exists today. I think the best approach is for the mechanism draft to focus on an achievable measure of congestion but for the use cases draft to leave = the door open to future more complex (or just richer) measures... The one = thing I am desperate to avoid with ConEx is any further ossification of the Internet (read "Why the Internet Only Just Works", M. Handley, BTTJ Vol = 24, No 3, July 2006) >=20 > On a side note, a shaper in a conex setting should be much more = readily > identifiable than at present, and would probably be used more = sparingly > if congestion were used in addition to bandwidth to assess the quality > of an ISP. Again, it depends on the type of shaper and what it is seeking to = achieve. I know that many UK ISPs throttle certain types of traffic at peak times, regardless of whether they cause congestion, just because they believe = they are "heavy" users of the network. ConEx can certainly achieve a similar = aim in a far better manner. Toby >=20 > J. >=20 >=20 > > My current instinct is that we should include of Dave's burstiness > measure, > > but give it its own section that looks at forms of congestion beyond > the > > classical queue-related congestion represented by packet drop, queue > delay > > and ECN marking. I guess that is what you are implying in the > sentence > > below... > > > > > I seems worth keeping the two separate in terminology for the > time > > > being. > > > > > > Regards, > > > > > > Stuart > > > > > > -----Original Message----- > > > From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com] > > > Sent: Wednesday, March 02, 2011 8:02 AM > > > To: STUART VENTERS; conex@ietf.org > > > Subject: Re: [conex] Discussion of new Use Cases pt 1 > > > > > > > > > Hi Stuart, > > > > > > An individual flow will experience the effect of loss or increased > > > delay > > > if a shaper (more generally a non-work conserving scheduler) that > is > > > similar to congestion of a shared resource. The current use case > draft > > > only mentions congestion of a shared resources. This only covers a > > > (subset) of the things which both "feel" like congestion to a an > > > individual flow. > > > > > > IMHO, somehow the use case (and mechanism) draft need to describe > and > > > address this shaper/non-work conserving scheduler case which will > > > appear > > > as congestion to an individual flow. One simple way to address = this > > > would > > > be to declare it out of scope, but then in my opinion the wg has > not > > > addressed an important use case that will be difficult to > distinguish > > > from > > > shared resource congestion. > > > > > > > > > Thanks, > > > > > > Dave > > > > > > On 3/1/11 11:56 AM, "STUART VENTERS" > wrote: > > > > > > >All, > > > > > > > >After thinking about Allissa and Dave's discussion, here's my 2c > for a > > > >CONEX congestion definition: > > > > > > > > > > > > > > > > > > > >Definition for the kind of congestion that CONEX is trying to > expose > > > in a > > > >statistically multiplexed routing cloud: > > > > > > > >Congestion is when a packet's forwarding behavior is adversely > > > affected > > > >because of the traffic load caused by other packets in the cloud. > > > > 'Adversely affected' means dropped or delayed more than the > minimum > > > >delay seen in an otherwise idle cloud. > > > > 'Other packets' means either packets from other users or > packets > > > from > > > >the same user. > > > > > > > >When a packet gets affected simply because a shaper or policer > says > > > that > > > >a specific flow or user is sending more bits that the traffic > contract > > > >allows, > > > > that doesn't feel like congestion, but rather traffic > management. > > > > > > > >On the other hand, if the shaper were affecting packets because = it > > > sees > > > >the cloud is near or at congestion, then that effect feels like > > > >congestion. > > > > (Because traffic management is telling the user that there = is, > or > > > >soon will be congestion.) > > > > > > > > > > > > > > > >The definition is focused on the discussion, so I may have > completely > > > >missed some other aspect of congestion? > > > > > > > >Under this definition, it might turn out that CONEX needs to > expose > > > both > > > >traffic management and congestion behaviors. > > > > I don't yet see the need for this, but could easily be = persuaded > by > > > a > > > >use case. > > > > It would just be unfortunate if we had to muddy the definitions > for > > > the > > > >two in order to include the TM behaviors. > > > > > > > > > > > >Cheers, > > > > > > > >Stuart > > > >_______________________________________________ > > > >conex mailing list > > > >conex@ietf.org > > > >https://www.ietf.org/mailman/listinfo/conex > > > > > > _______________________________________________ > > > conex mailing list > > > conex@ietf.org > > > https://www.ietf.org/mailman/listinfo/conex > > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From dave.mcdysan@verizon.com Thu Mar 3 05:53:42 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 772F33A6884 for ; Thu, 3 Mar 2011 05:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x13w7V0Ws9S8 for ; Thu, 3 Mar 2011 05:53:41 -0800 (PST) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id 4203B3A6403 for ; Thu, 3 Mar 2011 05:53:41 -0800 (PST) Received: from fldsmtpi03.verizon.com (fldsmtpi03.verizon.com [166.68.71.145]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p23Dsmft025177 for ; Thu, 3 Mar 2011 08:54:48 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,258,1297036800"; d="scan'208";a="4742835" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi03.verizon.com with ESMTP; 03 Mar 2011 13:54:47 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.147]) by FHDP1LUMXC7HB02.us.one.verizon.com ([2002:a644:3bbd::a644:3bbd]) with mapi; Thu, 3 Mar 2011 08:54:47 -0500 To: "conex@ietf.org" , STUART VENTERS Date: Thu, 3 Mar 2011 08:54:47 -0500 Thread-Topic: [conex] Discussion of new Use Cases pt 1 Thread-Index: AcvZqo8GehwnAI9+QCGSSbo4Triz2w== Message-ID: In-Reply-To: <8F242B230AD6474C8E7815DE0B4982D7179FB935@EXV1.corp.adtran.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 03 Mar 2011 13:53:42 -0000 Hi Stuart, A Beer BoF to discuss the 3rd paragraph sounds great to me, since the beer in Prague is so good. :-) In your opinion (and others in the working group who wish to comment), is "somehow ask for better service if you need to go faster" about making the service we already have (i.e., the shaper/ non-work conserving scheduler rate) better?=20 The choices (so far) seem to be: 1. Treat the shaper queue the same as all other queues since they all appear to create congestion as perceived by the flow user. 2. Signal more information to the receiver about the cause of loss since the remedy differs: A. For a shared queue, use current draft of abstract mechanism signals to reduce load and choose packets for different treatments. B. For a queue dedicated to a receiver (e.g., shaper) signal information that the shaper rate is the bottleneck, so that somehow (specific mechanism not in the current conex wg charter) the user could make a request to "go faster." Thanks, Dave On 3/2/11 3:04 PM, "STUART VENTERS" wrote: >Dave, > >Not sure I understand the 3rd paragraph enough to agree or not. > Perhaps a discussion about the psychology getting folks to part with >their money would be a good subject for a beer BOF. > >Hopefully, CONEX is more about making the service we already have work >better. > >Regards, > >Stuart > >-----Original Message----- >From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com] >Sent: Wednesday, March 02, 2011 11:59 AM >To: STUART VENTERS >Cc: conex@ietf.org >Subject: Re: [conex] Discussion of new Use Cases pt 1 > > >Hi Stuart, > >I agree that although the user perceived effect is different, the cause >is important and the response may indeed be different. We need to document >this. There may be a need to distinguish how these are signaled as well. >For example, if loss is implicitly determined by the receiver then there >currently may not be a way to distinguish between congestion of a shared >queue and shaper buffer overflow. > >Your last comment "somehow ask for better service if you need to go >faster" made me think of who would pay for making the service "go faster." >There is a burst mode service offered by some ISPs; and in some cases the >user pays and in others it involves recharging (i.e., someone else pays). > >This reminds me of a comment as recorded in the Beijing minutes by an >unnamed person from Ericsson that recharging had been tried for 100 years >in telephony and it did not work and would not work in the Internet. I did >not have time to respond in the meeting, and am doing so here. Isn't toll >free service in telephony a form of recharging (i.e., called party pays >instead of caller)? Are you saying that toll-free service has not worked? >The assertion made by that speaker was that therefore recharging should >not be considered. I think that in at least the consideration of who pays >for adjusting the rate of a shaper that it is something to be mentioned. >Any disagreement? > >Thanks, > >Dave > > >On 3/2/11 12:09 PM, "STUART VENTERS" wrote: > >>Dave, >> >>I support your direction >> (somehow, the use case draft needs to cover the shaper/non-work >>conserving scheduler) >> because it will get the issue on the table for discussion. >> >>I'm just quibbling over the terminology. >> Congestion and shapers are similar in effect but different in cause >>and therefore response. >> For congestion, the optimal application response is send slower now >>and try faster later. >> For a shaper, the optimal application response is send slower now >>and somehow ask for better service if you need to go faster. >> I seems worth keeping the two separate in terminology for the time >>being. >> >>Regards, >> >>Stuart >> >>-----Original Message----- >>From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com] >>Sent: Wednesday, March 02, 2011 8:02 AM >>To: STUART VENTERS; conex@ietf.org >>Subject: Re: [conex] Discussion of new Use Cases pt 1 >> >> >>Hi Stuart, >> >>An individual flow will experience the effect of loss or increased delay >>if a shaper (more generally a non-work conserving scheduler) that is >>similar to congestion of a shared resource. The current use case draft >>only mentions congestion of a shared resources. This only covers a >>(subset) of the things which both "feel" like congestion to a an >>individual flow.=20 >> >>IMHO, somehow the use case (and mechanism) draft need to describe and >>address this shaper/non-work conserving scheduler case which will appear >>as congestion to an individual flow. One simple way to address this would >>be to declare it out of scope, but then in my opinion the wg has not >>addressed an important use case that will be difficult to distinguish >>from >>shared resource congestion. >> >> >>Thanks, >> >>Dave >> >>On 3/1/11 11:56 AM, "STUART VENTERS" wrote: >> >>>All, >>> >>>After thinking about Allissa and Dave's discussion, here's my 2c for a >>>CONEX congestion definition: >>> >>> >>> >>> >>>Definition for the kind of congestion that CONEX is trying to expose in >>>a >>>statistically multiplexed routing cloud: >>> >>>Congestion is when a packet's forwarding behavior is adversely affected >>>because of the traffic load caused by other packets in the cloud. >>> 'Adversely affected' means dropped or delayed more than the minimum >>>delay seen in an otherwise idle cloud. >>> 'Other packets' means either packets from other users or packets from >>>the same user. >>> >>>When a packet gets affected simply because a shaper or policer says that >>>a specific flow or user is sending more bits that the traffic contract >>>allows,=20 >>> that doesn't feel like congestion, but rather traffic management. >>> >>>On the other hand, if the shaper were affecting packets because it sees >>>the cloud is near or at congestion, then that effect feels like >>>congestion. >>> (Because traffic management is telling the user that there is, or >>>soon will be congestion.) >>> >>> >>> >>>The definition is focused on the discussion, so I may have completely >>>missed some other aspect of congestion? >>> >>>Under this definition, it might turn out that CONEX needs to expose both >>>traffic management and congestion behaviors. >>> I don't yet see the need for this, but could easily be persuaded by a >>>use case. >>> It would just be unfortunate if we had to muddy the definitions for >>>the >>>two in order to include the TM behaviors. >>> >>> >>>Cheers, >>> >>>Stuart >>>_______________________________________________ >>>conex mailing list >>>conex@ietf.org >>>https://www.ietf.org/mailman/listinfo/conex >> > From dave.mcdysan@verizon.com Thu Mar 3 06:02:17 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0DE93A67F9 for ; Thu, 3 Mar 2011 06:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.437 X-Spam-Level: X-Spam-Status: No, score=-3.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxfavU3LveEe for ; Thu, 3 Mar 2011 06:02:15 -0800 (PST) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id B2E9B3A67F4 for ; Thu, 3 Mar 2011 06:02:15 -0800 (PST) Received: from fldsmtpi01.verizon.com (fldsmtpi01.verizon.com [166.68.71.143]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p23E38fP015535 for ; Thu, 3 Mar 2011 09:03:13 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,258,1297036800"; d="scan'208";a="4751022" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi01.verizon.com with ESMTP; 03 Mar 2011 14:03:07 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.147]) by FHDP1LUMXC7HB03.us.one.verizon.com ([2002:a644:3bbe::a644:3bbe]) with mapi; Thu, 3 Mar 2011 09:03:07 -0500 To: Caitlin Bestler , John Leslie Date: Thu, 3 Mar 2011 09:03:08 -0500 Thread-Topic: [conex] "Congestion" definition Thread-Index: AcvZq7kdxep0j9cERJi0MeehtVzttQ== Message-ID: In-Reply-To: <86D4248D-F176-46A0-AC1D-B8C9F41D9287@asomi.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] "Congestion" definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 03 Mar 2011 14:02:17 -0000 Hi Caitlin, I think that "queue depth" is another measure that could be considered and is an example of measures other than those currently in the definitions section of the use case draft and abstract mechanism draft (I.e., measures based upon lost packets or those which are ECN marked). LEDBAT proposes a measure that is related to queue depth of estimated latency that is one that has been discussed on this list and raised some questions as to how this would interact with conex. It is not clear to me whether either of these measures could be derived from the conex measures. A possibility to consider would be to create a draft in iccrg to collect the various definitions of congestion and use cases since conex has a charter focused on near term deliverables? Thanks, Dave On 3/2/11 3:17 PM, "Caitlin Bestler" wrote: > >On Mar 1, 2011, at 9:37 AM, John Leslie wrote: > >> STUART VENTERS wrote: >>>=20 >>> Definition for the kind of congestion that CONEX is trying to expose >>> in a statistically multiplexed routing cloud: >>>=20 >>> Congestion is when a packet's forwarding behavior is adversely affected >>> because of the traffic load caused by other packets in the cloud. >>> - 'Adversely affected' means dropped or delayed more than the minimum >>> delay seen in an otherwise idle cloud. >>> - 'Other packets' means either packets from other users or packets from >>> the same user. >>=20 >> This is a good start at discussing what we think we're talking about. >>=20 >> So, let me take it as a start, rather than criticize its completeness. >>=20 >> (I should perhaps criticize "Congestion is when", but let me reserve >> that issue for later.) >>=20 >> There is indeed good work going on to derive a measure of "congestion" >> from transit-time, assuming that transit-time includes only minimum >> latency plus queueing delays. (There are obvious problems with that >> assumption, which I won't discuss.) >>=20 >> Assuming we could actually collect useful queueing-delay numbers, it >> is quite reasonable to assume them to represent a type of "congestion". >>=20 >> BTW, I have discussed defining "congestion" on the ICCRG list, >> starting Sat, 4 Feb 2006 16:03:28 -0500: >> ]=20 >> ] To me, congestion is the condition where a packet can't be sent >> ] "immediately" (meaning perhaps that it can't be queued as the next >> ] packet to be sent). >>=20 >> (I derive that from a dictionary definition of "congestion: to >> cause an excessive accumulation...") >>=20 >> We could reasonably come up with a better definition of "immediately", >> but I contend that it would be different for every class of traffic, so >> I start from the most restrictive. >>=20 >> But I digress... >>=20 >> I don't believe time spent on arguing how much queueing corresponds >> to "zero" congestion is helpful. >>=20 >> Regardless, we do hit a discontinuity when the queue "fills" and a >> packet is dropped; and many folks use "congestion" to refer to that >> discontinuity. >>=20 >> ECN came along to moderate that discontinuity: instead of dropping >> the packet, we'd enforce Random-Early-Detection and at the tipping-point >> of RED we'd ECN-mark the packet instead of dropping it. Assuming well- >> behaved sender-receiver pairings this would reduce the need to drop >> packets more-quickly than TCP-like protocols could do by detecting a >> drop. >>=20 >> ECN deployment is spotty-at-best -- possibly because nobody sees a >> reason to trust the sender-receiver pairings... >>=20 >> Getting back to Stuart's definition: >>=20 >> I think "caused by" is the wrong wording. Necessarily, it is the >> fact that packet-arrival-rate exceeds packet-forwarding-rate that >> "causes" queuing delays. It makes no sense to try to assign "blame" >> for this to individual senders -- except in the limiting case where >> a sender's packet-sending-rate exceeds the available-forwarding-rate >> of a particular forwarder; and for that limiting-case it's not useful >> to assign "blame" until the sender has had sufficient time to learn >> the available-forwarding-rate. >>=20 >> Bottom line: a good start, Stuart! >>=20 >>=20 > >Two aspects of this definition strike me as needing refinement. > >First, other packets come from other flows. Switches/routers do not >know what this "user" entity is. > >Secondly the definition of "delay" is far too inclusive. It could be >interpreted >as simply delay waiting for a round-robin turn at the transmitter. > >QCN (802.1Qau) focuses strictly on queue depth (whether the queue is >actual or virtual). I think that is appropriate. The results of >round-robin >algorithms are already felt in the queue depth, so there is no need to >separately measure them. > >Queue depth is also easily measured. Combined with a delta measurment >the results give a very complete understanding of the network, and even >the >delta can be measured inexpensively. Predicting delay caused by other >queues that share a given transmitter is fairly complex, and ultimately >unnecessary. The queue is either backing up (which can already be >measured) or it is not. > > > > >-- >Caitlin Bestler >cait@asomi.com > > > > >-- >Caitlin Bestler >cait@asomi.com >http://www.asomi.com/CaitlinBestlerResume.html > > > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex From dave.mcdysan@verizon.com Thu Mar 3 06:27:12 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDAC73A699F for ; Thu, 3 Mar 2011 06:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.297 X-Spam-Level: X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDC36j-MXnlb for ; Thu, 3 Mar 2011 06:27:11 -0800 (PST) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id AEA803A68AD for ; Thu, 3 Mar 2011 06:27:11 -0800 (PST) Received: from fldsmtpi03.verizon.com (fldsmtpi03.verizon.com [166.68.71.145]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p23ES96i019669 for ; Thu, 3 Mar 2011 09:28:14 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,258,1297036800"; d="scan'208";a="4768893" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi03.verizon.com with ESMTP; 03 Mar 2011 14:28:08 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.147]) by FHDP1LUMXC7HB02.us.one.verizon.com ([2002:a644:3bbd::a644:3bbd]) with mapi; Thu, 3 Mar 2011 09:28:08 -0500 To: =?iso-8859-1?Q?Jo=E3o_Taveira_Ara=FAjo?= , conex Date: Thu, 3 Mar 2011 09:28:07 -0500 Thread-Topic: [conex] Discussion of new Use Cases pt 1 Thread-Index: AcvZrzdCj0tRv4zBT4e6toofylxNTw== Message-ID: In-Reply-To: <1299129398-sup-3190@moonloop.syshex.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 03 Mar 2011 14:27:13 -0000 Hi, A few responses in line below. Thanks, Dave On 3/3/11 12:23 AM, "Jo=E3o Taveira Ara=FAjo" wrote: >To play devil's advocate here .... > >Excerpts from Toby Moncaster's message of Wed Mar 02 17:24:50 UTC 2011: Actually, I think these paragraphs were posted by Stuart Venters. >> > Congestion and shapers are similar in effect but different in cause >> > and therefore response. >> > For congestion, the optimal application response is send slower >> > now and try faster later. >> > For a shaper, the optimal application response is send slower now >> > and somehow ask for better service if you need to go faster. > >Isn't a shaper just an induced bottleneck? I agree that it would be >useful to know the nature of what is holding you back, but I don't think >the response can be different unless you know very specific details of >the shaper which would be outside the scope of ConEx (and have probably >been pursued before). If anyone has pointer(s) to previous efforts to pursue this it would be helpful. > >> Furthermore, the fact you have been shaped is not correlated with >>whether >> you have had an adverse impact on other users. Consequently if you >>include >> that form of congestion information in the ConEx signal then it needs >>to be >> reacted to differently by the rest of the network... > >Clearly you are having an adverse impact ... on the network's business >model. Conflating all these causes into a single metric is not ideal, but >I think it's a lot better than trying to fine-tune separate signals and >risk using none (should checksum errors due to BER be treated as >congestion?). =20 In the current use case and abstract mechanism draft checksum errors are mapped to loss. This distinction could be important in a radio access network.=20 >In the long term it seems simpler to provide a seemingly loose definition >of what this single metric means than trying to very neatly >compartmentalize what exists today. > >On a side note, a shaper in a conex setting should be much more readily >identifiable than at present, and would probably be used more sparingly >if congestion were used in addition to bandwidth to assess the quality of >an ISP. This sounds interesting, but I don't completely follow this point. Could you please elaborate. > >J. > > >> My current instinct is that we should include of Dave's burstiness >>measure, >> but give it its own section that looks at forms of congestion beyond the >> classical queue-related congestion represented by packet drop, queue >>delay >> and ECN marking. I guess that is what you are implying in the sentence >> below... >>=20 >> > I seems worth keeping the two separate in terminology for the time >> > being. >> >=20 >> > Regards, >> >=20 >> > Stuart >> >=20 >> > -----Original Message----- >> > From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com] >> > Sent: Wednesday, March 02, 2011 8:02 AM >> > To: STUART VENTERS; conex@ietf.org >> > Subject: Re: [conex] Discussion of new Use Cases pt 1 >> >=20 >> >=20 >> > Hi Stuart, >> >=20 >> > An individual flow will experience the effect of loss or increased >> > delay >> > if a shaper (more generally a non-work conserving scheduler) that is >> > similar to congestion of a shared resource. The current use case draft >> > only mentions congestion of a shared resources. This only covers a >> > (subset) of the things which both "feel" like congestion to a an >> > individual flow. >> >=20 >> > IMHO, somehow the use case (and mechanism) draft need to describe and >> > address this shaper/non-work conserving scheduler case which will >> > appear >> > as congestion to an individual flow. One simple way to address this >> > would >> > be to declare it out of scope, but then in my opinion the wg has not >> > addressed an important use case that will be difficult to distinguish >> > from >> > shared resource congestion. >> >=20 >> >=20 >> > Thanks, >> >=20 >> > Dave >> >=20 >> > On 3/1/11 11:56 AM, "STUART VENTERS" >>wrote: >> >=20 >> > >All, >> > > >> > >After thinking about Allissa and Dave's discussion, here's my 2c for >>a >> > >CONEX congestion definition: >> > > >> > > >> > > >> > > >> > >Definition for the kind of congestion that CONEX is trying to expose >> > in a >> > >statistically multiplexed routing cloud: >> > > >> > >Congestion is when a packet's forwarding behavior is adversely >> > affected >> > >because of the traffic load caused by other packets in the cloud. >> > > 'Adversely affected' means dropped or delayed more than the >>minimum >> > >delay seen in an otherwise idle cloud. >> > > 'Other packets' means either packets from other users or packets >> > from >> > >the same user. >> > > >> > >When a packet gets affected simply because a shaper or policer says >> > that >> > >a specific flow or user is sending more bits that the traffic >>contract >> > >allows, >> > > that doesn't feel like congestion, but rather traffic management. >> > > >> > >On the other hand, if the shaper were affecting packets because it >> > sees >> > >the cloud is near or at congestion, then that effect feels like >> > >congestion. >> > > (Because traffic management is telling the user that there is, or >> > >soon will be congestion.) >> > > >> > > >> > > >> > >The definition is focused on the discussion, so I may have completely >> > >missed some other aspect of congestion? >> > > >> > >Under this definition, it might turn out that CONEX needs to expose >> > both >> > >traffic management and congestion behaviors. >> > > I don't yet see the need for this, but could easily be persuaded by >> > a >> > >use case. >> > > It would just be unfortunate if we had to muddy the definitions for >> > the >> > >two in order to include the TM behaviors. >> > > >> > > >> > >Cheers, >> > > >> > >Stuart >> > >_______________________________________________ >> > >conex mailing list >> > >conex@ietf.org >> > >https://www.ietf.org/mailman/listinfo/conex >> >=20 >> > _______________________________________________ >> > conex mailing list >> > conex@ietf.org >> > https://www.ietf.org/mailman/listinfo/conex >>=20 >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex From dave.mcdysan@verizon.com Thu Mar 3 06:31:03 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E42A43A67B2 for ; Thu, 3 Mar 2011 06:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.447 X-Spam-Level: X-Spam-Status: No, score=-3.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zzet+7g7zhEK for ; Thu, 3 Mar 2011 06:31:02 -0800 (PST) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id 4487C3A69A5 for ; Thu, 3 Mar 2011 06:30:33 -0800 (PST) Received: from fldsmtpi03.verizon.com (fldsmtpi03.verizon.com [166.68.71.145]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p23EVebM022878 for ; Thu, 3 Mar 2011 09:31:41 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,258,1297036800"; d="scan'208";a="4771710" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi03.verizon.com with ESMTP; 03 Mar 2011 14:31:40 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.147]) by FHDP1LUMXC7HB04.us.one.verizon.com ([2002:a644:3bbf::a644:3bbf]) with mapi; Thu, 3 Mar 2011 09:31:40 -0500 To: Caitlin Bestler Date: Thu, 3 Mar 2011 09:31:40 -0500 Thread-Topic: [conex] Discussion of new Use Cases pt 1 Thread-Index: AcvZr7Xkf7nDPRosQ1K8FVsW8fac/Q== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 03 Mar 2011 14:31:04 -0000 Hi Caitlin, You are reading this out of context of the earlier posts where burstiness is meaningful only when congestion is occurring. Also, a burst user is light, not heavy. I will merge the earlier posts along with the clarification I provided to Toby in the new section Toby and I proposed so that the context will be there. Thanks, Dave On 3/3/11 2:36 AM, "Caitlin Bestler" wrote: > >On Mar 2, 2011, at 5:11 AM, Mcdysan, David E wrote: > >> Hi Toby, >>=20 >> In line, snipping some material already covered. >>=20 >> Dave >>=20 >> On 3/1/11 4:58 AM, "Toby Moncaster" wrote: >>=20 >>> Hi Dave, >>>=20 >>> Inline >>=20 >>=20 >> Snipped >>=20 >>>=20 >>>>> I agree that Dave's peak/average rate signal doesn't seem to fit into >>>> the >>>>> same sort of signalling framework. For one thing Dave seems to just >>>> imply >>>>> this would be a binary state. >>>>=20 >>>>=20 >>>> I.m not sure I understand this comment. Could you please expand on >>>>what >>>> are the states. >>>=20 >>> If I understood you correctly, you were suggesting that users would be >>> classified as "heavy" or "not heavy", with their traffic marked >>> appropriately? >>=20 >> NOw I understand your point. I was proposing burstiness as (one >>possible) >> measure of "heaviness." It could be quantized as two values, and the >>title >> "heavy vs light" does imply this. However, I would not want to preclude >> more levels of quantization or a conex response that was some related to >> such a "heaviness" measure in a more continuous manner. >>=20 > > >Burstiness is only "heavy" when it is uncorrelated with network >congestion. >An ideal LEDBAT-algorithm would be perceived as being 'bursty'. Therefore >I believe equating any form of burstiness that a router could measure >with >being a "heavy" user is a poor metric. > > >-- >Caitlin Bestler >cait@asomi.com > > > > >-- >Caitlin Bestler >cait@asomi.com >http://www.asomi.com/CaitlinBestlerResume.html > > > From dave.mcdysan@verizon.com Thu Mar 3 06:34:06 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C84D3A67E7 for ; Thu, 3 Mar 2011 06:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.455 X-Spam-Level: X-Spam-Status: No, score=-3.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gD8XIc2hMLWG for ; Thu, 3 Mar 2011 06:34:05 -0800 (PST) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id 49DA83A69DC for ; Thu, 3 Mar 2011 06:34:05 -0800 (PST) Received: from fldsmtpi01.verizon.com (fldsmtpi01.verizon.com [166.68.71.143]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p23EZCKx025646 for ; Thu, 3 Mar 2011 09:35:13 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,258,1297036800"; d="scan'208";a="4775963" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi01.verizon.com with ESMTP; 03 Mar 2011 14:35:12 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.147]) by FHDP1LUMXC7HB04.us.one.verizon.com ([2002:a644:3bbf::a644:3bbf]) with mapi; Thu, 3 Mar 2011 09:35:12 -0500 To: Toby Moncaster , "'Caitlin Bestler'" Date: Thu, 3 Mar 2011 09:35:11 -0500 Thread-Topic: [conex] Discussion of new Use Cases pt 1 Thread-Index: AcvZsDQcH68uSru3Q/mdDCjPihvJRw== Message-ID: In-Reply-To: <001201cbd984$19e8d1b0$4dba7510$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 03 Mar 2011 14:34:06 -0000 Hi Toby, Agree that the coupling of burstiness with congestion is the region of interest. Will continue to work with you offline to fill in the subsection in the proposed new section of the use case draft that would cover a mapping of current measures into conex. I haven't seen any objections to adding this new section, but I may not get to this until Sunday. Thanks, Dave On 3/3/11 4:19 AM, "Toby Moncaster" wrote: > > >> -----Original Message----- >> From: Caitlin Bestler [mailto:cait@asomi.com] >> Sent: 03 March 2011 07:36 >> To: Mcdysan, David E >> Cc: Toby Moncaster; 'Alissa Cooper'; conex@ietf.org >> Subject: Re: [conex] Discussion of new Use Cases pt 1 >>=20 >>=20 > > > > >> > >> > NOw I understand your point. I was proposing burstiness as (one >> possible) >> > measure of "heaviness." It could be quantized as two values, and the >> title >> > "heavy vs light" does imply this. However, I would not want to >> preclude >> > more levels of quantization or a conex response that was some related >> to >> > such a "heaviness" measure in a more continuous manner. >> > >>=20 >>=20 >> Burstiness is only "heavy" when it is uncorrelated with network >> congestion. >> An ideal LEDBAT-algorithm would be perceived as being 'bursty'. >> Therefore >> I believe equating any form of burstiness that a router could measure >> with >> being a "heavy" user is a poor metric. > >But when coupled with a measure of their actual contribution to congestion >(what we call congestion volume in the draft) it gives a very good >measure. >You essentially end up with 4 groups - heavy users (high congestion, high >burstinesss), LEDBAT users (low congestion, low burstiness), "bursty" >users >(low congestion, high burstiness) and light users (low congestion, low >burstiness). > > >Toby > >>=20 >>=20 >> -- >> Caitlin Bestler >> cait@asomi.com >>=20 >>=20 >>=20 >>=20 >> -- >> Caitlin Bestler >> cait@asomi.com >> http://www.asomi.com/CaitlinBestlerResume.html >>=20 > > From dave.mcdysan@verizon.com Thu Mar 3 06:40:02 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2A843A6802 for ; Thu, 3 Mar 2011 06:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.312 X-Spam-Level: X-Spam-Status: No, score=-3.312 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahkc8hpRBgWq for ; Thu, 3 Mar 2011 06:40:01 -0800 (PST) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id 629873A67B2 for ; Thu, 3 Mar 2011 06:40:01 -0800 (PST) Received: from fldsmtpi02.verizon.com (fldsmtpi02.verizon.com [166.68.71.144]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p23Ef88h014243 for ; Thu, 3 Mar 2011 09:41:08 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,258,1297036800"; d="scan'208";a="4786733" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi02.verizon.com with ESMTP; 03 Mar 2011 14:41:08 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.147]) by FHDP1LUMXC7HB01.us.one.verizon.com ([2002:a644:3bbc::a644:3bbc]) with mapi; Thu, 3 Mar 2011 09:41:08 -0500 To: Toby Moncaster , =?iso-8859-1?Q?=27Jo=E3o_Taveira_Ara=FAjo=27?= , "'conex'" Date: Thu, 3 Mar 2011 09:41:07 -0500 Thread-Topic: [conex] Discussion of new Use Cases pt 1 Thread-Index: AcvZsQhBqQCtpZPHTzWLhOtbPDk+lg== Message-ID: In-Reply-To: <001301cbd985$45f234d0$d1d69e70$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 03 Mar 2011 14:40:02 -0000 Hi Toby, A few responses in line. Dave On 3/3/11 4:27 AM, "Toby Moncaster" wrote: > > >> -----Original Message----- >> From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf >> Of Jo=E3o Taveira Ara=FAjo >> Sent: 03 March 2011 05:23 >> To: conex >> Subject: Re: [conex] Discussion of new Use Cases pt 1 >>=20 >> To play devil's advocate here .... >>=20 >> Excerpts from Toby Moncaster's message of Wed Mar 02 17:24:50 UTC 2011: >> > > Congestion and shapers are similar in effect but different in >> cause >> > > and therefore response. >> > > For congestion, the optimal application response is send >> slower >> > > now and try faster later. >> > > For a shaper, the optimal application response is send slower >> now >> > > and somehow ask for better service if you need to go faster. >>=20 >> Isn't a shaper just an induced bottleneck? I agree that it would be >> useful to know the nature of what is holding you back, but I don't >> think the response can be different unless you know very specific >> details of the shaper which would be outside the scope of ConEx (and >> have probably been pursued before). > >Indeed it is just an artificial bottleneck, so (depending on why it is >there) the best response is probably to try and get your rate to as close >to >that rate as possible > >>=20 >> > Furthermore, the fact you have been shaped is not correlated with >> whether >> > you have had an adverse impact on other users. Consequently if you >> include >> > that form of congestion information in the ConEx signal then it needs >> to be >> > reacted to differently by the rest of the network... >>=20 >> Clearly you are having an adverse impact ... on the network's business >> model.=20 > >No, you may be being shaped to make sure you don't suffer loss on your DSL >link... Unless the UK is way out on a limb, ISPs seem to be moving beyond >imposing rate caps as part of their business model, instead relying on the >physical limits imposed by the access... In the US, rate tiers are a common ISP practice for higher speed physical access networks (e.g., cable, FTTC, FTTH). > >> Conflating all these causes into a single metric is not ideal, >> but I think it's a lot better than trying to fine-tune separate signals >> and risk using none (should checksum errors due to BER be treated as >> congestion?). In the long term it seems simpler to provide a seemingly >> loose definition of what this single metric means than trying to very >> neatly compartmentalize what exists today. > >I think the best approach is for the mechanism draft to focus on an >achievable measure of congestion but for the use cases draft to leave the >door open to future more complex (or just richer) measures... The one >thing >I am desperate to avoid with ConEx is any further ossification of the >Internet (read "Why the Internet Only Just Works", M. Handley, BTTJ Vol >24, >No 3, July 2006) > >>=20 >> On a side note, a shaper in a conex setting should be much more readily >> identifiable than at present, and would probably be used more sparingly >> if congestion were used in addition to bandwidth to assess the quality >> of an ISP. > >Again, it depends on the type of shaper and what it is seeking to >achieve. I >know that many UK ISPs throttle certain types of traffic at peak times, >regardless of whether they cause congestion, just because they believe >they >are "heavy" users of the network. ConEx can certainly achieve a similar >aim >in a far better manner. Not all ISPs will have the same use cases, and some have other constraints (e.g., regulatory). IMHO, assuming that the Internet is homogeneous and the same everywhere is too simple of an assumption, and the use case draft should capture the scenarios where conex can improve matters beyond the status quo, such as the one Toby mentions above. > >Toby > >>=20 >> J. >>=20 >>=20 >> > My current instinct is that we should include of Dave's burstiness >> measure, >> > but give it its own section that looks at forms of congestion beyond >> the >> > classical queue-related congestion represented by packet drop, queue >> delay >> > and ECN marking. I guess that is what you are implying in the >> sentence >> > below... >> > >> > > I seems worth keeping the two separate in terminology for the >> time >> > > being. >> > > >> > > Regards, >> > > >> > > Stuart >> > > >> > > -----Original Message----- >> > > From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com] >> > > Sent: Wednesday, March 02, 2011 8:02 AM >> > > To: STUART VENTERS; conex@ietf.org >> > > Subject: Re: [conex] Discussion of new Use Cases pt 1 >> > > >> > > >> > > Hi Stuart, >> > > >> > > An individual flow will experience the effect of loss or increased >> > > delay >> > > if a shaper (more generally a non-work conserving scheduler) that >> is >> > > similar to congestion of a shared resource. The current use case >> draft >> > > only mentions congestion of a shared resources. This only covers a >> > > (subset) of the things which both "feel" like congestion to a an >> > > individual flow. >> > > >> > > IMHO, somehow the use case (and mechanism) draft need to describe >> and >> > > address this shaper/non-work conserving scheduler case which will >> > > appear >> > > as congestion to an individual flow. One simple way to address this >> > > would >> > > be to declare it out of scope, but then in my opinion the wg has >> not >> > > addressed an important use case that will be difficult to >> distinguish >> > > from >> > > shared resource congestion. >> > > >> > > >> > > Thanks, >> > > >> > > Dave >> > > >> > > On 3/1/11 11:56 AM, "STUART VENTERS" >> wrote: >> > > >> > > >All, >> > > > >> > > >After thinking about Allissa and Dave's discussion, here's my 2c >> for a >> > > >CONEX congestion definition: >> > > > >> > > > >> > > > >> > > > >> > > >Definition for the kind of congestion that CONEX is trying to >> expose >> > > in a >> > > >statistically multiplexed routing cloud: >> > > > >> > > >Congestion is when a packet's forwarding behavior is adversely >> > > affected >> > > >because of the traffic load caused by other packets in the cloud. >> > > > 'Adversely affected' means dropped or delayed more than the >> minimum >> > > >delay seen in an otherwise idle cloud. >> > > > 'Other packets' means either packets from other users or >> packets >> > > from >> > > >the same user. >> > > > >> > > >When a packet gets affected simply because a shaper or policer >> says >> > > that >> > > >a specific flow or user is sending more bits that the traffic >> contract >> > > >allows, >> > > > that doesn't feel like congestion, but rather traffic >> management. >> > > > >> > > >On the other hand, if the shaper were affecting packets because it >> > > sees >> > > >the cloud is near or at congestion, then that effect feels like >> > > >congestion. >> > > > (Because traffic management is telling the user that there is, >> or >> > > >soon will be congestion.) >> > > > >> > > > >> > > > >> > > >The definition is focused on the discussion, so I may have >> completely >> > > >missed some other aspect of congestion? >> > > > >> > > >Under this definition, it might turn out that CONEX needs to >> expose >> > > both >> > > >traffic management and congestion behaviors. >> > > > I don't yet see the need for this, but could easily be persuaded >> by >> > > a >> > > >use case. >> > > > It would just be unfortunate if we had to muddy the definitions >> for >> > > the >> > > >two in order to include the TM behaviors. >> > > > >> > > > >> > > >Cheers, >> > > > >> > > >Stuart >> > > >_______________________________________________ >> > > >conex mailing list >> > > >conex@ietf.org >> > > >https://www.ietf.org/mailman/listinfo/conex >> > > >> > > _______________________________________________ >> > > conex mailing list >> > > conex@ietf.org >> > > https://www.ietf.org/mailman/listinfo/conex >> > >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex From richard_woundy@cable.comcast.com Thu Mar 3 07:56:58 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAAD93A69F7 for ; Thu, 3 Mar 2011 07:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.969 X-Spam-Level: X-Spam-Status: No, score=-102.969 tagged_above=-999 required=5 tests=[AWL=-1.534, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFHr-EO4Py3C for ; Thu, 3 Mar 2011 07:56:57 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 3004C3A69F8 for ; Thu, 3 Mar 2011 07:56:57 -0800 (PST) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.28106842; Thu, 03 Mar 2011 09:09:56 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0270.001; Thu, 3 Mar 2011 10:57:59 -0500 From: "Woundy, Richard" To: "Mcdysan, David E" , Toby Moncaster , =?iso-8859-1?Q?=27Jo=E3o_Taveira_Ara=FAjo=27?= Thread-Topic: [conex] Discussion of new Use Cases pt 1 Thread-Index: AQHL2WMPfx7nRZ1bQlegt+aIyEpk5ZQbq5aAgABXhID//62ZcA== Date: Thu, 3 Mar 2011 15:57:59 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD11343D198@PACDCEXMB05.cable.comcast.com> References: <001301cbd985$45f234d0$d1d69e70$@com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.191.223.245] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'conex' Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 03 Mar 2011 15:56:58 -0000 >>No, you may be being shaped to make sure you don't suffer loss on your DS= L >>link... Unless the UK is way out on a limb, ISPs seem to be moving beyond >>imposing rate caps as part of their business model, instead relying on th= e >>physical limits imposed by the access... >In the US, rate tiers are a common ISP practice for higher speed physical >access networks (e.g., cable, FTTC, FTTH). Definitely agree with Dave. In the US ISPs use rate tiers on wireline acces= s (eg higher speeds for higher price tiers), although not as much with wire= less access. I see service tiers in other countries as well, eg Sweden and = Japan. Some US wireless providers charge different prices for access to dif= ferent wireless technologies, eg "3G" vs "4G". There may be different variations of "rate caps" in different geographies, = though. In the UK, Plusnet appears to deploy "per-application rate caps" on= a time of day basis. I don't think I've seen rate shaping like this in the= US among the larger ISPs. http://www.plus.net/support/broadband/speed_guide/download_speeds.shtml http://www.plus.net/support/broadband/speed_guide/upload_speeds.shtml -- Rich -----Original Message----- From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of M= cdysan, David E Sent: Thursday, March 03, 2011 9:41 AM To: Toby Moncaster; 'Jo=E3o Taveira Ara=FAjo'; 'conex' Subject: Re: [conex] Discussion of new Use Cases pt 1 Hi Toby, A few responses in line. Dave On 3/3/11 4:27 AM, "Toby Moncaster" wrote: > > >> -----Original Message----- >> From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf >> Of Jo=E3o Taveira Ara=FAjo >> Sent: 03 March 2011 05:23 >> To: conex >> Subject: Re: [conex] Discussion of new Use Cases pt 1 >>=20 >> To play devil's advocate here .... >>=20 >> Excerpts from Toby Moncaster's message of Wed Mar 02 17:24:50 UTC 2011: >> > > Congestion and shapers are similar in effect but different in >> cause >> > > and therefore response. >> > > For congestion, the optimal application response is send >> slower >> > > now and try faster later. >> > > For a shaper, the optimal application response is send slower >> now >> > > and somehow ask for better service if you need to go faster. >>=20 >> Isn't a shaper just an induced bottleneck? I agree that it would be >> useful to know the nature of what is holding you back, but I don't >> think the response can be different unless you know very specific >> details of the shaper which would be outside the scope of ConEx (and >> have probably been pursued before). > >Indeed it is just an artificial bottleneck, so (depending on why it is >there) the best response is probably to try and get your rate to as close >to >that rate as possible > >>=20 >> > Furthermore, the fact you have been shaped is not correlated with >> whether >> > you have had an adverse impact on other users. Consequently if you >> include >> > that form of congestion information in the ConEx signal then it needs >> to be >> > reacted to differently by the rest of the network... >>=20 >> Clearly you are having an adverse impact ... on the network's business >> model.=20 > >No, you may be being shaped to make sure you don't suffer loss on your DSL >link... Unless the UK is way out on a limb, ISPs seem to be moving beyond >imposing rate caps as part of their business model, instead relying on the >physical limits imposed by the access... In the US, rate tiers are a common ISP practice for higher speed physical access networks (e.g., cable, FTTC, FTTH). > >> Conflating all these causes into a single metric is not ideal, >> but I think it's a lot better than trying to fine-tune separate signals >> and risk using none (should checksum errors due to BER be treated as >> congestion?). In the long term it seems simpler to provide a seemingly >> loose definition of what this single metric means than trying to very >> neatly compartmentalize what exists today. > >I think the best approach is for the mechanism draft to focus on an >achievable measure of congestion but for the use cases draft to leave the >door open to future more complex (or just richer) measures... The one >thing >I am desperate to avoid with ConEx is any further ossification of the >Internet (read "Why the Internet Only Just Works", M. Handley, BTTJ Vol >24, >No 3, July 2006) > >>=20 >> On a side note, a shaper in a conex setting should be much more readily >> identifiable than at present, and would probably be used more sparingly >> if congestion were used in addition to bandwidth to assess the quality >> of an ISP. > >Again, it depends on the type of shaper and what it is seeking to >achieve. I >know that many UK ISPs throttle certain types of traffic at peak times, >regardless of whether they cause congestion, just because they believe >they >are "heavy" users of the network. ConEx can certainly achieve a similar >aim >in a far better manner. Not all ISPs will have the same use cases, and some have other constraints (e.g., regulatory). IMHO, assuming that the Internet is homogeneous and the same everywhere is too simple of an assumption, and the use case draft should capture the scenarios where conex can improve matters beyond the status quo, such as the one Toby mentions above. > >Toby > >>=20 >> J. >>=20 >>=20 >> > My current instinct is that we should include of Dave's burstiness >> measure, >> > but give it its own section that looks at forms of congestion beyond >> the >> > classical queue-related congestion represented by packet drop, queue >> delay >> > and ECN marking. I guess that is what you are implying in the >> sentence >> > below... >> > >> > > I seems worth keeping the two separate in terminology for the >> time >> > > being. >> > > >> > > Regards, >> > > >> > > Stuart >> > > >> > > -----Original Message----- >> > > From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com] >> > > Sent: Wednesday, March 02, 2011 8:02 AM >> > > To: STUART VENTERS; conex@ietf.org >> > > Subject: Re: [conex] Discussion of new Use Cases pt 1 >> > > >> > > >> > > Hi Stuart, >> > > >> > > An individual flow will experience the effect of loss or increased >> > > delay >> > > if a shaper (more generally a non-work conserving scheduler) that >> is >> > > similar to congestion of a shared resource. The current use case >> draft >> > > only mentions congestion of a shared resources. This only covers a >> > > (subset) of the things which both "feel" like congestion to a an >> > > individual flow. >> > > >> > > IMHO, somehow the use case (and mechanism) draft need to describe >> and >> > > address this shaper/non-work conserving scheduler case which will >> > > appear >> > > as congestion to an individual flow. One simple way to address this >> > > would >> > > be to declare it out of scope, but then in my opinion the wg has >> not >> > > addressed an important use case that will be difficult to >> distinguish >> > > from >> > > shared resource congestion. >> > > >> > > >> > > Thanks, >> > > >> > > Dave >> > > >> > > On 3/1/11 11:56 AM, "STUART VENTERS" >> wrote: >> > > >> > > >All, >> > > > >> > > >After thinking about Allissa and Dave's discussion, here's my 2c >> for a >> > > >CONEX congestion definition: >> > > > >> > > > >> > > > >> > > > >> > > >Definition for the kind of congestion that CONEX is trying to >> expose >> > > in a >> > > >statistically multiplexed routing cloud: >> > > > >> > > >Congestion is when a packet's forwarding behavior is adversely >> > > affected >> > > >because of the traffic load caused by other packets in the cloud. >> > > > 'Adversely affected' means dropped or delayed more than the >> minimum >> > > >delay seen in an otherwise idle cloud. >> > > > 'Other packets' means either packets from other users or >> packets >> > > from >> > > >the same user. >> > > > >> > > >When a packet gets affected simply because a shaper or policer >> says >> > > that >> > > >a specific flow or user is sending more bits that the traffic >> contract >> > > >allows, >> > > > that doesn't feel like congestion, but rather traffic >> management. >> > > > >> > > >On the other hand, if the shaper were affecting packets because it >> > > sees >> > > >the cloud is near or at congestion, then that effect feels like >> > > >congestion. >> > > > (Because traffic management is telling the user that there is, >> or >> > > >soon will be congestion.) >> > > > >> > > > >> > > > >> > > >The definition is focused on the discussion, so I may have >> completely >> > > >missed some other aspect of congestion? >> > > > >> > > >Under this definition, it might turn out that CONEX needs to >> expose >> > > both >> > > >traffic management and congestion behaviors. >> > > > I don't yet see the need for this, but could easily be persuaded >> by >> > > a >> > > >use case. >> > > > It would just be unfortunate if we had to muddy the definitions >> for >> > > the >> > > >two in order to include the TM behaviors. >> > > > >> > > > >> > > >Cheers, >> > > > >> > > >Stuart >> > > >_______________________________________________ >> > > >conex mailing list >> > > >conex@ietf.org >> > > >https://www.ietf.org/mailman/listinfo/conex >> > > >> > > _______________________________________________ >> > > conex mailing list >> > > conex@ietf.org >> > > https://www.ietf.org/mailman/listinfo/conex >> > >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex From dave.mcdysan@verizon.com Thu Mar 3 08:04:16 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 110493A69CC for ; Thu, 3 Mar 2011 08:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.311 X-Spam-Level: X-Spam-Status: No, score=-3.311 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fHFslpq2DKn for ; Thu, 3 Mar 2011 08:04:13 -0800 (PST) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id 74E2F3A6821 for ; Thu, 3 Mar 2011 08:04:12 -0800 (PST) Received: from fldsmtpi01.verizon.com (fldsmtpi01.verizon.com [166.68.71.143]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p23G5Hco024604 for ; Thu, 3 Mar 2011 11:05:17 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,258,1297036800"; d="scan'208";a="4848815" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi01.verizon.com with ESMTP; 03 Mar 2011 16:05:17 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.147]) by FHDP1LUMXC7HB02.us.one.verizon.com ([2002:a644:3bbd::a644:3bbd]) with mapi; Thu, 3 Mar 2011 11:05:17 -0500 To: "Woundy, Richard" , Toby Moncaster , =?iso-8859-1?Q?=27Jo=E3o_Taveira_Ara=FAjo=27?= Date: Thu, 3 Mar 2011 11:05:15 -0500 Thread-Topic: [conex] Discussion of new Use Cases pt 1 Thread-Index: AcvZvMl4biWTxT3CQ86FFPMVUvn9sw== Message-ID: In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD11343D198@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'conex' Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 03 Mar 2011 16:04:16 -0000 Here is another link that summarizes rate and usage caps for US and Japan: http://www.newamerica.net/files/Bandwidth%20Caps%20for%20High-Speed%20Inter net%20in%20the%20U.S.%20and%20Japan.pdf Dave On 3/3/11 10:57 AM, "Woundy, Richard" wrote: >>>No, you may be being shaped to make sure you don't suffer loss on your >>>DSL >>>link... Unless the UK is way out on a limb, ISPs seem to be moving >>>beyond >>>imposing rate caps as part of their business model, instead relying on >>>the >>>physical limits imposed by the access... > >>In the US, rate tiers are a common ISP practice for higher speed physical >>access networks (e.g., cable, FTTC, FTTH). > >Definitely agree with Dave. In the US ISPs use rate tiers on wireline >access (eg higher speeds for higher price tiers), although not as much >with wireless access. I see service tiers in other countries as well, eg >Sweden and Japan. Some US wireless providers charge different prices for >access to different wireless technologies, eg "3G" vs "4G". > >There may be different variations of "rate caps" in different >geographies, though. In the UK, Plusnet appears to deploy >"per-application rate caps" on a time of day basis. I don't think I've >seen rate shaping like this in the US among the larger ISPs. > >http://www.plus.net/support/broadband/speed_guide/download_speeds.shtml >http://www.plus.net/support/broadband/speed_guide/upload_speeds.shtml > >-- Rich > >-----Original Message----- >From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of >Mcdysan, David E >Sent: Thursday, March 03, 2011 9:41 AM >To: Toby Moncaster; 'Jo=E3o Taveira Ara=FAjo'; 'conex' >Subject: Re: [conex] Discussion of new Use Cases pt 1 > >Hi Toby, > >A few responses in line. > >Dave > >On 3/3/11 4:27 AM, "Toby Moncaster" wrote: > >> >> >>> -----Original Message----- >>> From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf >>> Of Jo=E3o Taveira Ara=FAjo >>> Sent: 03 March 2011 05:23 >>> To: conex >>> Subject: Re: [conex] Discussion of new Use Cases pt 1 >>>=20 >>> To play devil's advocate here .... >>>=20 >>> Excerpts from Toby Moncaster's message of Wed Mar 02 17:24:50 UTC 2011: >>> > > Congestion and shapers are similar in effect but different in >>> cause >>> > > and therefore response. >>> > > For congestion, the optimal application response is send >>> slower >>> > > now and try faster later. >>> > > For a shaper, the optimal application response is send slower >>> now >>> > > and somehow ask for better service if you need to go faster. >>>=20 >>> Isn't a shaper just an induced bottleneck? I agree that it would be >>> useful to know the nature of what is holding you back, but I don't >>> think the response can be different unless you know very specific >>> details of the shaper which would be outside the scope of ConEx (and >>> have probably been pursued before). >> >>Indeed it is just an artificial bottleneck, so (depending on why it is >>there) the best response is probably to try and get your rate to as close >>to >>that rate as possible >> >>>=20 >>> > Furthermore, the fact you have been shaped is not correlated with >>> whether >>> > you have had an adverse impact on other users. Consequently if you >>> include >>> > that form of congestion information in the ConEx signal then it needs >>> to be >>> > reacted to differently by the rest of the network... >>>=20 >>> Clearly you are having an adverse impact ... on the network's business >>> model.=20 >> >>No, you may be being shaped to make sure you don't suffer loss on your >>DSL >>link... Unless the UK is way out on a limb, ISPs seem to be moving beyond >>imposing rate caps as part of their business model, instead relying on >>the >>physical limits imposed by the access... > >In the US, rate tiers are a common ISP practice for higher speed physical >access networks (e.g., cable, FTTC, FTTH). > >> >>> Conflating all these causes into a single metric is not ideal, >>> but I think it's a lot better than trying to fine-tune separate signals >>> and risk using none (should checksum errors due to BER be treated as >>> congestion?). In the long term it seems simpler to provide a seemingly >>> loose definition of what this single metric means than trying to very >>> neatly compartmentalize what exists today. >> >>I think the best approach is for the mechanism draft to focus on an >>achievable measure of congestion but for the use cases draft to leave the >>door open to future more complex (or just richer) measures... The one >>thing >>I am desperate to avoid with ConEx is any further ossification of the >>Internet (read "Why the Internet Only Just Works", M. Handley, BTTJ Vol >>24, >>No 3, July 2006) >> >>>=20 >>> On a side note, a shaper in a conex setting should be much more readily >>> identifiable than at present, and would probably be used more sparingly >>> if congestion were used in addition to bandwidth to assess the quality >>> of an ISP. >> >>Again, it depends on the type of shaper and what it is seeking to >>achieve. I >>know that many UK ISPs throttle certain types of traffic at peak times, >>regardless of whether they cause congestion, just because they believe >>they >>are "heavy" users of the network. ConEx can certainly achieve a similar >>aim >>in a far better manner. > >Not all ISPs will have the same use cases, and some have other constraints >(e.g., regulatory). IMHO, assuming that the Internet is homogeneous and >the same everywhere is too simple of an assumption, and the use case draft >should capture the scenarios where conex can improve matters beyond the >status quo, such as the one Toby mentions above. > >> >>Toby >> >>>=20 >>> J. >>>=20 >>>=20 >>> > My current instinct is that we should include of Dave's burstiness >>> measure, >>> > but give it its own section that looks at forms of congestion beyond >>> the >>> > classical queue-related congestion represented by packet drop, queue >>> delay >>> > and ECN marking. I guess that is what you are implying in the >>> sentence >>> > below... >>> > >>> > > I seems worth keeping the two separate in terminology for the >>> time >>> > > being. >>> > > >>> > > Regards, >>> > > >>> > > Stuart >>> > > >>> > > -----Original Message----- >>> > > From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com] >>> > > Sent: Wednesday, March 02, 2011 8:02 AM >>> > > To: STUART VENTERS; conex@ietf.org >>> > > Subject: Re: [conex] Discussion of new Use Cases pt 1 >>> > > >>> > > >>> > > Hi Stuart, >>> > > >>> > > An individual flow will experience the effect of loss or increased >>> > > delay >>> > > if a shaper (more generally a non-work conserving scheduler) that >>> is >>> > > similar to congestion of a shared resource. The current use case >>> draft >>> > > only mentions congestion of a shared resources. This only covers a >>> > > (subset) of the things which both "feel" like congestion to a an >>> > > individual flow. >>> > > >>> > > IMHO, somehow the use case (and mechanism) draft need to describe >>> and >>> > > address this shaper/non-work conserving scheduler case which will >>> > > appear >>> > > as congestion to an individual flow. One simple way to address this >>> > > would >>> > > be to declare it out of scope, but then in my opinion the wg has >>> not >>> > > addressed an important use case that will be difficult to >>> distinguish >>> > > from >>> > > shared resource congestion. >>> > > >>> > > >>> > > Thanks, >>> > > >>> > > Dave >>> > > >>> > > On 3/1/11 11:56 AM, "STUART VENTERS" >>> wrote: >>> > > >>> > > >All, >>> > > > >>> > > >After thinking about Allissa and Dave's discussion, here's my 2c >>> for a >>> > > >CONEX congestion definition: >>> > > > >>> > > > >>> > > > >>> > > > >>> > > >Definition for the kind of congestion that CONEX is trying to >>> expose >>> > > in a >>> > > >statistically multiplexed routing cloud: >>> > > > >>> > > >Congestion is when a packet's forwarding behavior is adversely >>> > > affected >>> > > >because of the traffic load caused by other packets in the cloud. >>> > > > 'Adversely affected' means dropped or delayed more than the >>> minimum >>> > > >delay seen in an otherwise idle cloud. >>> > > > 'Other packets' means either packets from other users or >>> packets >>> > > from >>> > > >the same user. >>> > > > >>> > > >When a packet gets affected simply because a shaper or policer >>> says >>> > > that >>> > > >a specific flow or user is sending more bits that the traffic >>> contract >>> > > >allows, >>> > > > that doesn't feel like congestion, but rather traffic >>> management. >>> > > > >>> > > >On the other hand, if the shaper were affecting packets because it >>> > > sees >>> > > >the cloud is near or at congestion, then that effect feels like >>> > > >congestion. >>> > > > (Because traffic management is telling the user that there is, >>> or >>> > > >soon will be congestion.) >>> > > > >>> > > > >>> > > > >>> > > >The definition is focused on the discussion, so I may have >>> completely >>> > > >missed some other aspect of congestion? >>> > > > >>> > > >Under this definition, it might turn out that CONEX needs to >>> expose >>> > > both >>> > > >traffic management and congestion behaviors. >>> > > > I don't yet see the need for this, but could easily be persuaded >>> by >>> > > a >>> > > >use case. >>> > > > It would just be unfortunate if we had to muddy the definitions >>> for >>> > > the >>> > > >two in order to include the TM behaviors. >>> > > > >>> > > > >>> > > >Cheers, >>> > > > >>> > > >Stuart >>> > > >_______________________________________________ >>> > > >conex mailing list >>> > > >conex@ietf.org >>> > > >https://www.ietf.org/mailman/listinfo/conex >>> > > >>> > > _______________________________________________ >>> > > conex mailing list >>> > > conex@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/conex >>> > >>> _______________________________________________ >>> conex mailing list >>> conex@ietf.org >>> https://www.ietf.org/mailman/listinfo/conex >> >>_______________________________________________ >>conex mailing list >>conex@ietf.org >>https://www.ietf.org/mailman/listinfo/conex > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex From stuart.venters@adtran.com Thu Mar 3 09:35:20 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F7143A6838 for ; Thu, 3 Mar 2011 09:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWz3mPArdTPL for ; Thu, 3 Mar 2011 09:35:19 -0800 (PST) Received: from p02c12o144.mxlogic.net (p02c12o144.mxlogic.net [208.65.145.77]) by core3.amsl.com (Postfix) with ESMTP id 31D0B3A6810 for ; Thu, 3 Mar 2011 09:35:17 -0800 (PST) Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by p02c12o144.mxlogic.net(mxl_mta-6.9.0-1) over TLS secured channel with ESMTP id 991df6d4.0.12674.00-303.30876.p02c12o144.mxlogic.net (envelope-from ); Thu, 03 Mar 2011 10:36:26 -0700 (MST) X-MXL-Hash: 4d6fd19a43b98305-836bc3a98485c9ce545b914027c74c214b77afae Received: from corp-exfr2.corp.adtran.com (172.23.101.22) by ex-hc2.corp.adtran.com (172.22.50.75) with Microsoft SMTP Server id 14.1.270.1; Thu, 3 Mar 2011 11:36:25 -0600 Received: from EXV1.corp.adtran.com ([172.22.48.215]) by corp-exfr2.corp.adtran.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Mar 2011 11:36:24 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Mar 2011 11:36:24 -0600 Message-ID: <8F242B230AD6474C8E7815DE0B4982D7179FB938@EXV1.corp.adtran.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] Discussion of new Use Cases pt 1 Thread-Index: AcvZqo8GehwnAI9+QCGSSbo4Triz2wAHTdpA From: STUART VENTERS To: "Mcdysan, David E" X-OriginalArrivalTime: 03 Mar 2011 17:36:24.0960 (UTC) FILETIME=[84C8D800:01CBD9C9] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.83] X-AnalysisOut: [v=1.0 c=1 a=G9T4uwCCN8UA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-] X-AnalysisOut: [IA:10 a=5zDNsY1we+1mvVcp/5+1jQ==:17 a=ZsyXEVtvAAAA:8 a=48v] X-AnalysisOut: [gC7mUAAAA:8 a=eJNrpioGAAAA:8 a=7lMASTaqsMaf79kb9wcA:9 a=cq] X-AnalysisOut: [bryAkicRloDXg7q0MA:7 a=aLbJi6Kvyehkil8Rqp98iRa_4TAA:4 a=wP] X-AnalysisOut: [NLvfGTeEIA:10 a=TRFw3Wk1wdAA:10 a=lZB815dzVvQA:10 a=DvnSUQ] X-AnalysisOut: [UdWHYA:10 a=cqSE7bj8bXPKfuQr:21 a=jd-2BQyctrfJT2tj:21] Cc: conex@ietf.org Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 03 Mar 2011 17:35:20 -0000 Dave, Yes, I was thinking that the optimal thing for a customer to do, when facing a limit from a traffic management shaper, was to change the service subscription parameters through either signaling or talking to a person. This was probably not a useful direction for CONEX purposes except to highlight that there is a difference=20 between losses due to congestion and losses due to a traffic management shaper. After sleeping on it, a more interesting difference is how others in the = cloud are affected. If a user ignores losses due to congestion and continues sending, = others are affected. If a user ignores losses due to a shaper enforcing his traffic = contract and continues sending, only he is affected. Maybe a key component in the definition for congestion causing behavior = is that the behavior must affect others. Regards, Stuart -----Original Message----- From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com] Sent: Thursday, March 03, 2011 7:55 AM To: conex@ietf.org; STUART VENTERS Subject: Re: [conex] Discussion of new Use Cases pt 1 Hi Stuart, A Beer BoF to discuss the 3rd paragraph sounds great to me, since the = beer in Prague is so good. :-) In your opinion (and others in the working group who wish to comment), = is "somehow ask for better service if you need to go faster" about making = the service we already have (i.e., the shaper/ non-work conserving scheduler rate) better?=20 The choices (so far) seem to be: 1. Treat the shaper queue the same as all other queues since they all appear to create congestion as perceived by the flow user. 2. Signal more information to the receiver about the cause of loss = since the remedy differs: A. For a shared queue, use current draft of abstract mechanism signals to reduce load and choose packets for different treatments. B. For a queue dedicated to a receiver (e.g., shaper) signal = information that the shaper rate is the bottleneck, so that somehow (specific mechanism not in the current conex wg charter) the user could make a request to "go faster." Thanks, Dave On 3/2/11 3:04 PM, "STUART VENTERS" wrote: >Dave, > >Not sure I understand the 3rd paragraph enough to agree or not. > Perhaps a discussion about the psychology getting folks to part with >their money would be a good subject for a beer BOF. > >Hopefully, CONEX is more about making the service we already have work >better. > >Regards, > >Stuart > >-----Original Message----- >From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com] >Sent: Wednesday, March 02, 2011 11:59 AM >To: STUART VENTERS >Cc: conex@ietf.org >Subject: Re: [conex] Discussion of new Use Cases pt 1 > > >Hi Stuart, > >I agree that although the user perceived effect is different, the = cause >is important and the response may indeed be different. We need to = document >this. There may be a need to distinguish how these are signaled as = well. >For example, if loss is implicitly determined by the receiver then = there >currently may not be a way to distinguish between congestion of a = shared >queue and shaper buffer overflow. > >Your last comment "somehow ask for better service if you need to go >faster" made me think of who would pay for making the service "go = faster." >There is a burst mode service offered by some ISPs; and in some cases = the >user pays and in others it involves recharging (i.e., someone else = pays). > >This reminds me of a comment as recorded in the Beijing minutes by an >unnamed person from Ericsson that recharging had been tried for 100 = years >in telephony and it did not work and would not work in the Internet. I = did >not have time to respond in the meeting, and am doing so here. Isn't = toll >free service in telephony a form of recharging (i.e., called party pays >instead of caller)? Are you saying that toll-free service has not = worked? >The assertion made by that speaker was that therefore recharging should >not be considered. I think that in at least the consideration of who = pays >for adjusting the rate of a shaper that it is something to be = mentioned. >Any disagreement? > >Thanks, > >Dave > > >On 3/2/11 12:09 PM, "STUART VENTERS" wrote: > >>Dave, >> >>I support your direction >> (somehow, the use case draft needs to cover the shaper/non-work >>conserving scheduler) >> because it will get the issue on the table for discussion. >> >>I'm just quibbling over the terminology. >> Congestion and shapers are similar in effect but different in cause >>and therefore response. >> For congestion, the optimal application response is send slower = now >>and try faster later. >> For a shaper, the optimal application response is send slower now >>and somehow ask for better service if you need to go faster. >> I seems worth keeping the two separate in terminology for the time >>being. >> >>Regards, >> >>Stuart >> >>-----Original Message----- >>From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com] >>Sent: Wednesday, March 02, 2011 8:02 AM >>To: STUART VENTERS; conex@ietf.org >>Subject: Re: [conex] Discussion of new Use Cases pt 1 >> >> >>Hi Stuart, >> >>An individual flow will experience the effect of loss or increased = delay >>if a shaper (more generally a non-work conserving scheduler) that is >>similar to congestion of a shared resource. The current use case draft >>only mentions congestion of a shared resources. This only covers a >>(subset) of the things which both "feel" like congestion to a an >>individual flow.=20 >> >>IMHO, somehow the use case (and mechanism) draft need to describe and >>address this shaper/non-work conserving scheduler case which will = appear >>as congestion to an individual flow. One simple way to address this = would >>be to declare it out of scope, but then in my opinion the wg has not >>addressed an important use case that will be difficult to distinguish >>from >>shared resource congestion. >> >> >>Thanks, >> >>Dave >> >>On 3/1/11 11:56 AM, "STUART VENTERS" = wrote: >> >>>All, >>> >>>After thinking about Allissa and Dave's discussion, here's my 2c for = a >>>CONEX congestion definition: >>> >>> >>> >>> >>>Definition for the kind of congestion that CONEX is trying to expose = in >>>a >>>statistically multiplexed routing cloud: >>> >>>Congestion is when a packet's forwarding behavior is adversely = affected >>>because of the traffic load caused by other packets in the cloud. >>> 'Adversely affected' means dropped or delayed more than the = minimum >>>delay seen in an otherwise idle cloud. >>> 'Other packets' means either packets from other users or packets = from >>>the same user. >>> >>>When a packet gets affected simply because a shaper or policer says = that >>>a specific flow or user is sending more bits that the traffic = contract >>>allows,=20 >>> that doesn't feel like congestion, but rather traffic management. >>> >>>On the other hand, if the shaper were affecting packets because it = sees >>>the cloud is near or at congestion, then that effect feels like >>>congestion. >>> (Because traffic management is telling the user that there is, or >>>soon will be congestion.) >>> >>> >>> >>>The definition is focused on the discussion, so I may have completely >>>missed some other aspect of congestion? >>> >>>Under this definition, it might turn out that CONEX needs to expose = both >>>traffic management and congestion behaviors. >>> I don't yet see the need for this, but could easily be persuaded by = a >>>use case. >>> It would just be unfortunate if we had to muddy the definitions for >>>the >>>two in order to include the TM behaviors. >>> >>> >>>Cheers, >>> >>>Stuart >>>_______________________________________________ >>>conex mailing list >>>conex@ietf.org >>>https://www.ietf.org/mailman/listinfo/conex >> > From cait@asomi.com Thu Mar 3 09:58:42 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5D0F3A6A0C for ; Thu, 3 Mar 2011 09:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MfQzOvBPr30 for ; Thu, 3 Mar 2011 09:58:42 -0800 (PST) Received: from mail8.sea5.speakeasy.net (mail8.sea5.speakeasy.net [69.17.117.53]) by core3.amsl.com (Postfix) with ESMTP id EF8053A6A08 for ; Thu, 3 Mar 2011 09:58:41 -0800 (PST) Received: (qmail 11870 invoked from network); 3 Mar 2011 17:59:49 -0000 Received: from imac.asomi.com (cait@asomi.com@[66.92.48.27]) (envelope-sender ) by mail8.sea5.speakeasy.net (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 3 Mar 2011 17:59:49 -0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Caitlin Bestler In-Reply-To: <001201cbd984$19e8d1b0$4dba7510$@com> Date: Thu, 3 Mar 2011 09:59:47 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <001201cbd984$19e8d1b0$4dba7510$@com> To: Toby Moncaster X-Mailer: Apple Mail (2.1082) Cc: conex@ietf.org Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 03 Mar 2011 17:58:42 -0000 On Mar 3, 2011, at 1:19 AM, Toby Moncaster wrote: > > >> -----Original Message----- >> From: Caitlin Bestler [mailto:cait@asomi.com] >> Sent: 03 March 2011 07:36 >> To: Mcdysan, David E >> Cc: Toby Moncaster; 'Alissa Cooper'; conex@ietf.org >> Subject: Re: [conex] Discussion of new Use Cases pt 1 >> >> > > > > >>> >>> NOw I understand your point. I was proposing burstiness as (one >> possible) >>> measure of "heaviness." It could be quantized as two values, and the >> title >>> "heavy vs light" does imply this. However, I would not want to >> preclude >>> more levels of quantization or a conex response that was some related >> to >>> such a "heaviness" measure in a more continuous manner. >>> >> >> >> Burstiness is only "heavy" when it is uncorrelated with network >> congestion. >> An ideal LEDBAT-algorithm would be perceived as being 'bursty'. >> Therefore >> I believe equating any form of burstiness that a router could measure >> with >> being a "heavy" user is a poor metric. > > But when coupled with a measure of their actual contribution to congestion > (what we call congestion volume in the draft) it gives a very good measure. > You essentially end up with 4 groups - heavy users (high congestion, high > burstinesss), LEDBAT users (low congestion, low burstiness), "bursty" users > (low congestion, high burstiness) and light users (low congestion, low > burstiness). > > Agreed, that sort of classification would avoid the problem. -- Caitlin Bestler cait@asomi.com From cait@asomi.com Thu Mar 3 10:04:46 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29B2628C0E9 for ; Thu, 3 Mar 2011 10:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4r62tLVzS8t for ; Thu, 3 Mar 2011 10:04:45 -0800 (PST) Received: from mail5.sea5.speakeasy.net (mail5.sea5.speakeasy.net [69.17.117.49]) by core3.amsl.com (Postfix) with ESMTP id 0DDB628C0E2 for ; Thu, 3 Mar 2011 10:04:45 -0800 (PST) Received: (qmail 24279 invoked from network); 3 Mar 2011 18:05:52 -0000 Received: from imac.asomi.com (cait@asomi.com@[66.92.48.27]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 3 Mar 2011 18:05:52 -0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Caitlin Bestler In-Reply-To: <5FDC413D5FA246468C200652D63E627A0D12CDA8@LDCMVEXC1-PRD.hq.netapp.com> Date: Thu, 3 Mar 2011 10:05:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2F246B0F-0AD2-463B-9C3D-E17F3709FC76@nokia.com><003b01cbceaa$f85540d0$e8ffc270$@com><34EEDAE3-A7CF-413C-9182-A13608473622@asomi.com> <20110217180411.GK86652@verdi> <5FDC413D5FA246468C200652D63E627A0D12CDA8@LDCMVEXC1-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1082) Cc: conex@ietf.org Subject: Re: [conex] WG energy X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 03 Mar 2011 18:04:46 -0000 On Feb 24, 2011, at 2:21 AM, Scheffenegger, Richard wrote: >=20 >=20 >=20 >>> In particular, the degree to which an implementation could be > synergistic >>> with 802.1 DCB ccongestion control is still very vague. >>=20 >> Hmm... >>=20 >> I suspect most of us on this list aren't terribly familiar with >> 802.1Qau. (That is what you're referring to, right?) >>=20 >>> An ideal conex draft, in my evaluation, would allow forwarding > elements >>> to implement *both* DCB and Conex, and suggest a method by which DCB >>> congestion could be reported to the IP stack as though it had been >>> reported by a CONEX device. >>=20 >> I'm guessing here...=20 >>=20 >> We've been writing in terms of something very like ECN to mark >> congestion, which marks according to a queue filling. >>=20 >> 802.1Qau has an out-of-band mechanism to report "percent congestion" >> from receiving switch to sender (if I read it correctly, I presume > that >> to be between two routers). This does sound like promising > information, >> but it's not immediately clear how it should get reported to a Layer = 3 >> device. >=20 > Isn't 802.1Qau supposed to throttle / stop all traffic of an offending > flow (as classified by 802.1Qau - which could be of variable = granularity > depending on the capabilities of the device IIRC) when congestion is > experienced? >=20 > Also, the sender in the 802.1Qau case is a L2 MAC device - which is > doing the throttling.=20 >=20 > The only thing a L3+ sender would notice would either be queues = building > at the L3/L2 interface, or calls to send data would block instead of > immediately return.=20 >=20 > Obvioulsy, filling some queue right in the sender (be it a hardware or > software queue) is a bad thing (www.bufferbloat.net), so there might = be > some merit in signaling this between layers. However, as all that is > required happens within the same host, it's more of an API question > between device driver and software stack, rather than a protocol issue > concerning the explicit signaling in a L3 header...=20 >=20 > Of course, if the egress side of a Router is 802.1Qau, but the ingress > side is not, the router may want to inform the flow - but standard ECN > marking (available with IPv4 and IPv6) should do that...=20 >=20 > Or am I missing something more? >=20 If bufferbloat in switches/routers is bad, it is nothing compared to the = buffering available in hosts. A classic L4 congestion algorithm will respond only to drops or ECNs, = which a successful QCN deployment will prevent. So unless L4 is responsive to=20= queuing delays the predictable impact of QCN on L4 is for L4 to continue = to "floor it" until things finally break. Explicitly sharing the information that a flow is being throttled by = some form of queue management, as opposed to wireless retransmissions, would be useful in helping the L4 algorithms take the optimal response. Ideally = this would be an abstract measurement, rather than requiring the L4 algorithm understand the specifics of whatever form of Queue Management is being employed. -- Caitlin Bestler cait@asomi.com From dave.mcdysan@verizon.com Thu Mar 3 12:29:25 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5752F3A6843 for ; Thu, 3 Mar 2011 12:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faCBG8JDwyno for ; Thu, 3 Mar 2011 12:29:23 -0800 (PST) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id E65463A6800 for ; Thu, 3 Mar 2011 12:29:23 -0800 (PST) Received: from fldsmtpi02.verizon.com (fldsmtpi02.verizon.com [166.68.71.144]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p23KUH9Z010544 for ; Thu, 3 Mar 2011 15:30:22 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,259,1297036800"; d="scan'208";a="5066481" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi02.verizon.com with ESMTP; 03 Mar 2011 20:30:16 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.147]) by FHDP1LUMXC7HB02.us.one.verizon.com ([2002:a644:3bbd::a644:3bbd]) with mapi; Thu, 3 Mar 2011 15:30:16 -0500 To: STUART VENTERS Date: Thu, 3 Mar 2011 15:30:13 -0500 Thread-Topic: [conex] Discussion of new Use Cases pt 1 Thread-Index: AcvZ4c4Chkau9joYSHi+AHPXhkK0BA== Message-ID: In-Reply-To: <8F242B230AD6474C8E7815DE0B4982D7179FB938@EXV1.corp.adtran.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 03 Mar 2011 20:29:25 -0000 Hi Stuart, A few responses in line below. Thanks, Dave On 3/3/11 12:36 PM, "STUART VENTERS" wrote: >Dave, > >Yes, I was thinking that the optimal thing for a customer to do, > when facing a limit from a traffic management shaper, > was to change the service subscription parameters > through either signaling or talking to a person. >This was probably not a useful direction for CONEX purposes > except to highlight that there is a difference > between losses due to congestion > and losses due to a traffic management shaper. > >After sleeping on it, a more interesting difference is how others in the >cloud are affected. > If a user ignores losses due to congestion and continues sending, >others are affected. > If a user ignores losses due to a shaper enforcing his traffic >contract and continues sending, only he is affected. However, since loss (is usually)implicitly determined, there is no (easy) way for the current conex abstract mechanism proposal to tell the difference between these cases. A question I have for the experts on the abstract mechanism and the associated mechanism is a high-level analysis and explanation as to whether this distinction has no impact or makes a substantial difference. > >Maybe a key component in the definition for congestion causing behavior >is that the behavior must affect others. A statement to this effect is already in the first paragraph of section 4 of the use-case draft: We argue that current traffic-control mechanisms seek to control the wrong quantity. What matters in the network is neither the volume of traffic nor the rate of traffic: it is the contribution to congestion over time -- congestion means that your traffic impacts other users, and conversely that their traffic impacts you. So if there is no congestion there need not be any restriction on the amount a user can send; restrictions only need to apply when others are sending traffic such that there is congestion. The intent of the first sentence may be to assume that there are no traffic-control mechanisms in place (e.g., shaping as described in this thread which is not (yet) described in section 3.1 as an existing approach). Would look to the authors to clarify the intent. However, as mentioned on this thread shaping is deployed in a number of ISPs in some countries. Seems like the draft should describe a use case where shaping is present. > >Regards, > >Stuart > > > > >-----Original Message----- >From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com] >Sent: Thursday, March 03, 2011 7:55 AM >To: conex@ietf.org; STUART VENTERS >Subject: Re: [conex] Discussion of new Use Cases pt 1 > > >Hi Stuart, > >A Beer BoF to discuss the 3rd paragraph sounds great to me, since the beer >in Prague is so good. :-) > >In your opinion (and others in the working group who wish to comment), is >"somehow ask for better service if you need to go faster" about making the >service we already have (i.e., the shaper/ non-work conserving scheduler >rate) better?=20 > >The choices (so far) seem to be: > 1. Treat the shaper queue the same as all other queues since they all >appear to create congestion as perceived by the flow user. > 2. Signal more information to the receiver about the cause of loss since >the remedy differs: > A. For a shared queue, use current draft of abstract mechanism signals >to reduce load and choose packets for different treatments. > B. For a queue dedicated to a receiver (e.g., shaper) signal information >that the shaper rate is the bottleneck, so that somehow (specific >mechanism not in the current conex wg charter) the user could make a >request to "go faster." > >Thanks, > >Dave > >On 3/2/11 3:04 PM, "STUART VENTERS" wrote: > >>Dave, >> >>Not sure I understand the 3rd paragraph enough to agree or not. >> Perhaps a discussion about the psychology getting folks to part with >>their money would be a good subject for a beer BOF. >> >>Hopefully, CONEX is more about making the service we already have work >>better. >> >>Regards, >> >>Stuart >> >>-----Original Message----- >>From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com] >>Sent: Wednesday, March 02, 2011 11:59 AM >>To: STUART VENTERS >>Cc: conex@ietf.org >>Subject: Re: [conex] Discussion of new Use Cases pt 1 >> >> >>Hi Stuart, >> >>I agree that although the user perceived effect is different, the cause >>is important and the response may indeed be different. We need to >>document >>this. There may be a need to distinguish how these are signaled as well. >>For example, if loss is implicitly determined by the receiver then there >>currently may not be a way to distinguish between congestion of a shared >>queue and shaper buffer overflow. >> >>Your last comment "somehow ask for better service if you need to go >>faster" made me think of who would pay for making the service "go >>faster." >>There is a burst mode service offered by some ISPs; and in some cases the >>user pays and in others it involves recharging (i.e., someone else pays). >> >>This reminds me of a comment as recorded in the Beijing minutes by an >>unnamed person from Ericsson that recharging had been tried for 100 years >>in telephony and it did not work and would not work in the Internet. I >>did >>not have time to respond in the meeting, and am doing so here. Isn't toll >>free service in telephony a form of recharging (i.e., called party pays >>instead of caller)? Are you saying that toll-free service has not worked? >>The assertion made by that speaker was that therefore recharging should >>not be considered. I think that in at least the consideration of who pays >>for adjusting the rate of a shaper that it is something to be mentioned. >>Any disagreement? >> >>Thanks, >> >>Dave >> >> >>On 3/2/11 12:09 PM, "STUART VENTERS" wrote: >> >>>Dave, >>> >>>I support your direction >>> (somehow, the use case draft needs to cover the shaper/non-work >>>conserving scheduler) >>> because it will get the issue on the table for discussion. >>> >>>I'm just quibbling over the terminology. >>> Congestion and shapers are similar in effect but different in cause >>>and therefore response. >>> For congestion, the optimal application response is send slower now >>>and try faster later. >>> For a shaper, the optimal application response is send slower now >>>and somehow ask for better service if you need to go faster. >>> I seems worth keeping the two separate in terminology for the time >>>being. >>> >>>Regards, >>> >>>Stuart >>> >>>-----Original Message----- >>>From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com] >>>Sent: Wednesday, March 02, 2011 8:02 AM >>>To: STUART VENTERS; conex@ietf.org >>>Subject: Re: [conex] Discussion of new Use Cases pt 1 >>> >>> >>>Hi Stuart, >>> >>>An individual flow will experience the effect of loss or increased delay >>>if a shaper (more generally a non-work conserving scheduler) that is >>>similar to congestion of a shared resource. The current use case draft >>>only mentions congestion of a shared resources. This only covers a >>>(subset) of the things which both "feel" like congestion to a an >>>individual flow. >>> >>>IMHO, somehow the use case (and mechanism) draft need to describe and >>>address this shaper/non-work conserving scheduler case which will appear >>>as congestion to an individual flow. One simple way to address this >>>would >>>be to declare it out of scope, but then in my opinion the wg has not >>>addressed an important use case that will be difficult to distinguish >>>from >>>shared resource congestion. >>> >>> >>>Thanks, >>> >>>Dave >>> >>>On 3/1/11 11:56 AM, "STUART VENTERS" wrote: >>> >>>>All, >>>> >>>>After thinking about Allissa and Dave's discussion, here's my 2c for a >>>>CONEX congestion definition: >>>> >>>> >>>> >>>> >>>>Definition for the kind of congestion that CONEX is trying to expose in >>>>a >>>>statistically multiplexed routing cloud: >>>> >>>>Congestion is when a packet's forwarding behavior is adversely affected >>>>because of the traffic load caused by other packets in the cloud. >>>> 'Adversely affected' means dropped or delayed more than the minimum >>>>delay seen in an otherwise idle cloud. >>>> 'Other packets' means either packets from other users or packets >>>>from >>>>the same user. >>>> >>>>When a packet gets affected simply because a shaper or policer says >>>>that >>>>a specific flow or user is sending more bits that the traffic contract >>>>allows,=20 >>>> that doesn't feel like congestion, but rather traffic management. >>>> >>>>On the other hand, if the shaper were affecting packets because it sees >>>>the cloud is near or at congestion, then that effect feels like >>>>congestion. >>>> (Because traffic management is telling the user that there is, or >>>>soon will be congestion.) >>>> >>>> >>>> >>>>The definition is focused on the discussion, so I may have completely >>>>missed some other aspect of congestion? >>>> >>>>Under this definition, it might turn out that CONEX needs to expose >>>>both >>>>traffic management and congestion behaviors. >>>> I don't yet see the need for this, but could easily be persuaded by a >>>>use case. >>>> It would just be unfortunate if we had to muddy the definitions for >>>>the >>>>two in order to include the TM behaviors. >>>> >>>> >>>>Cheers, >>>> >>>>Stuart >>>>_______________________________________________ >>>>conex mailing list >>>>conex@ietf.org >>>>https://www.ietf.org/mailman/listinfo/conex >>> >> > From john@jlc.net Thu Mar 3 12:33:49 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C11C3A6973 for ; Thu, 3 Mar 2011 12:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ir7Xdek7iRp1 for ; Thu, 3 Mar 2011 12:33:48 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 56D693A688F for ; Thu, 3 Mar 2011 12:33:48 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id BC1C933C26; Thu, 3 Mar 2011 15:34:56 -0500 (EST) Date: Thu, 3 Mar 2011 15:34:56 -0500 From: John Leslie To: "Mcdysan, David E" Message-ID: <20110303203456.GB89966@verdi> References: <20110226145616.GH7663@verdi> 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.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 03 Mar 2011 20:33:49 -0000 Mcdysan, David E wrote: > On 2/26/11 9:56 AM, "John Leslie" wrote: > >> Clearly, we do have to produce a use-cases document, though I would >> prefer that at least an "abstract mechanism" could be agreed to as a >> basis for it. > > Not sure I understand what you are proposing. I was stating a preference (not expecting it to be satisfied). > The wg decided to take mechanism largely out of the use case draft in > IETF 78, and in IETF 79 the exclusion of a use case that did not match > the adopted abstract mechanism was explicitly agreed (see meeting > minutes snippet in my response to Allison). My preference was that we might have had sufficient agreement on an abstract mechanism so that we didn't have to dance-around that issue (which IMHO tends to confuse readers). >> I am hesitant to go the path of labeling use-cases according to what >> metric best serves them. IMHO, our use-cases document should only include >> things achievable with a particular metric, which I have been assuming >> to be congestion-expected-during-transit. > > Metric is mentioned once in the use case document in section 3 in the > context of existing approaches. Are you referring to the measures in > definitions of use cases, or something in the abstract mechanism draft? > (where the term metric is not used at all) I have explained elsewhere what I mean by "metric". I may well continue to use that term (to mean what I said I meant) in preference to "measure" until we come up with an agreed meaning for "measure". (Alas, the mathematical usage of "measure" is IMHO a poor fit to what I hope we mean to talk about. (I do not wish to argue semantics -- I merely reserve the right to speak exactly instead of vaguely, where what I say will mean different things to different readers.) >> Certainly, ConEx will need to operate in an environment where such >> "shaping" occurs. I am considerably less sure how (if at all) it should >> be discussed in a use-cases document. > > I asked this question in IETF 78 of Bob regarding a non-work conserving > scheduler (e.g., shaper), which can experiences the congestion measure as > defined in the current use case draft. Now _I'm_ not sure I understand what you're proposing... "Shaper" is a vague term -- and AFAICT must remain vague because its function(s) will be determined by many parties so as to satisfy their (many different) business models. Discussion elsewhere throws light on what some of us are thinking: that whether or not we accept "shaping" as "congestion", it is not "contention" -- it doesn't reflect an attempt to take resources away from other flows. IMHO, if we go the ECN route, we have to accept ECN marks as indicating "congestion": if a "shaper" ECN-marks, that's "congestion" we must expose. OTOH, if the "shaper" drops, it's no longer a "must"; and if a "shaper" merely delays, we don't necessarily have to do anything. Speaking for myself, I don't believe we can cover all the cases of "shaper" actions. At some point, we have to "treat it as damage" (and assume routing-around-it is Somebody Else's Problem). ;^) > At a minimum I think the statement in the first paragraph of section 4 > that describes what I called "inter-user congestion" as "---- congestion > means that your traffic impacts other users, and conversely that their > traffic impacts you." needs to exclude the use case of what I called > "self-congestion" needs to address the use case employed by many ISPs (as > Toby points out). I agree -- that's not a sufficient definition of "congestion". >> To me, it is "congestion" even if it is not resource-congestion. >> Congestion-expected markings could better inform decisions about >> "shaping". The issues about whether ConEx marking is considered at >> any point of congestion are much the same... > > I didn't follow this. Could you please elaborate. So far, I don't see a practical way to distinguish ECN-marking due to queue-filling from ECN-marking due to shaping. I have little desire to try; and I suggest that deserves to be an area-for-future-work. I consider both to be "congestion" that we are charged to "expose". -- John Leslie From john@jlc.net Thu Mar 3 12:41:45 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56CC43A6973 for ; Thu, 3 Mar 2011 12:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.568 X-Spam-Level: X-Spam-Status: No, score=-106.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRQeYYlKuJ-D for ; Thu, 3 Mar 2011 12:41:44 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 707273A688F for ; Thu, 3 Mar 2011 12:41:44 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 1F21933C25; Thu, 3 Mar 2011 15:42:52 -0500 (EST) Date: Thu, 3 Mar 2011 15:42:52 -0500 From: John Leslie To: Steve Bauer Message-ID: <20110303204252.GC89966@verdi> References: <20110226145616.GH7663@verdi> <001301cbd7f8$9540e330$bfc2a990$@com> <20110301165902.GN7663@verdi> <003d01cbd834$8d463a40$a7d2aec0$@com> 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.org Subject: Re: [conex] "Metric" X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 03 Mar 2011 20:41:45 -0000 Steve Bauer wrote: > > Awhile ago we wrote the following paper which may be relevant to > inject at this point: > > The Evolution of Internet Congestion > http://mitas.csail.mit.edu/papers/Bauer_Clark_Lehr_2009.pdf > > In particular see section 3, "Defining Congestion". I have read through this carefully. Section 3 feels as if you were reading my mind (or I yours)! I most thoroughly agree that people of differing backgrounds naturally attach very different meanings to "congestion". We've gotten as far as we have in "congestion control" because we've proposed things that do a decent job of controlling whichever of those meanings we attach. I seriously would like to reach agreement on what we mean (rather than wordsmith until the poor reader can no longer tell which). This is hard! I do recommend this paper to anyone willing to put forth the effort. -- John Leslie From john@jlc.net Thu Mar 3 12:51:50 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B85C63A6800 for ; Thu, 3 Mar 2011 12:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPGqnSO0x3BS for ; Thu, 3 Mar 2011 12:51:46 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 54ECC3A69FD for ; Thu, 3 Mar 2011 12:51:46 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id E581733C22; Thu, 3 Mar 2011 15:52:54 -0500 (EST) Date: Thu, 3 Mar 2011 15:52:54 -0500 From: John Leslie To: "Mcdysan, David E" Message-ID: <20110303205254.GD89966@verdi> References: <201103021749.54967.mirja.kuehlewind@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.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 03 Mar 2011 20:51:50 -0000 Mcdysan, David E wrote: > On 3/2/11 11:49 AM, "Mirja Kuehlewind" > wrote: > >>>> I agree it would be good to have some idea of how broad the >>>> applicability of the abstract mechanism is. I actually think that >>>> there is very little real disagreement between what we are both >>>> saying. The only significant difference seems to be you are >>>> suggesting an explicit measure of long-term "heaviness" of use, >>>> whereas I feel that such a measure can be derived from the short >>>> term congestion measure. >>> >>> I am OK with a comparable measure that can be derived from the >>> abstract mechanism draft. But we should agree as to what the form of >>> the result of such a variation would like. That is, what are the >>> characterisitics. (I'm hoping Dave will capture some of this in the language he's drafting.) >> I agree with Toby here. You can derive something like "heaviness" >> or "burtiness" from the (long-term evaluation of) ConEx information. >> Thus the use case would be that those information can be derived. >> The use case should _NOT_ cover _HOW_ those information will be >> derived as this is a different mechanism and out of scope. I don't fully agree with Mirja here... > I don't believe that saying a derivation is possible is sufficient. > I believe the working group needs to see some level of description > of the derivation to confirm this assertion. I tend to agree. Further, I think there's little point of _only_ showing how it "could" be derived -- I think a use-case should talk about how such a derivative could be _used_. > (It is not immediately obvious to me.) Nonetheless, I think Dave should make the first pass at sending text. -- John Leslie From john@jlc.net Thu Mar 3 13:00:44 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF0F63A6A4F for ; Thu, 3 Mar 2011 13:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.57 X-Spam-Level: X-Spam-Status: No, score=-106.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSaFAFFCMEpd for ; Thu, 3 Mar 2011 13:00:44 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 5A24D3A6893 for ; Thu, 3 Mar 2011 13:00:32 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 9215133C25; Thu, 3 Mar 2011 16:01:40 -0500 (EST) Date: Thu, 3 Mar 2011 16:01:40 -0500 From: John Leslie To: Caitlin Bestler Message-ID: <20110303210140.GE89966@verdi> References: <64069EFF-C572-4088-9EF0-9CDE66B20390@cdt.org> <8F242B230AD6474C8E7815DE0B4982D7179FB92C@EXV1.corp.adtran.com> <20110301173738.GO7663@verdi> <86D4248D-F176-46A0-AC1D-B8C9F41D9287@asomi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86D4248D-F176-46A0-AC1D-B8C9F41D9287@asomi.com> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] "Congestion" definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 03 Mar 2011 21:00:44 -0000 Caitlin Bestler wrote: > On Mar 1, 2011, at 9:37 AM, John Leslie wrote: >> STUART VENTERS wrote: >>> >>> Congestion is when a packet's forwarding behavior is adversely affected >>> because of the traffic load caused by other packets in the cloud. >>> - 'Adversely affected' means dropped or delayed more than the minimum >>> delay seen in an otherwise idle cloud. >>> - 'Other packets' means either packets from other users or packets from >>> the same user. > > Two aspects of this definition strike me as needing refinement. > > First, other packets come from other flows. Switches/routers do not > know what this "user" entity is. Agreed. > Secondly the definition of "delay" is far too inclusive. It could be > interpreted as simply delay waiting for a round-robin turn at the > transmitter. Agreed. > QCN (802.1Qau) focuses strictly on queue depth (whether the queue is > actual or virtual). I think that is appropriate. The results of > round-robin algorithms are already felt in the queue depth, so there > is no need to separately measure them. Queue depth, IMHO, is a better measure than most things available to us. > Queue depth is also easily measured. Combined with a delta measurment > the results give a very complete understanding of the network, and > even the delta can be measured inexpensively. Predicting delay caused > by other queues that share a given transmitter is fairly complex, and > ultimately unnecessary. The queue is either backing up (which can > already be measured) or it is not. I agree with all of this, but... "The light's much better over here!" ;^) Can Caitlin (or anyone else) come up with a way to deploy this throughout enough of the Internet? Or, is the bottom-line that we can't design a single Experimental protocol? -- John Leslie From bob.briscoe@bt.com Thu Mar 3 15:00:45 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A73328C0EF for ; Thu, 3 Mar 2011 15:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgurNWaMKD8R for ; Thu, 3 Mar 2011 15:00:43 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id E6D0028C0E7 for ; Thu, 3 Mar 2011 15:00:42 -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, 3 Mar 2011 23:01:49 +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, 3 Mar 2011 23:01:49 +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 1299193308558; Thu, 3 Mar 2011 23:01:48 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.144.96]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p23N1kAN030843; Thu, 3 Mar 2011 23:01:46 GMT Message-Id: <201103032301.p23N1kAN030843@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 03 Mar 2011 23:01:44 +0000 To: Caitlin Bestler From: Bob Briscoe In-Reply-To: References: <2F246B0F-0AD2-463B-9C3D-E17F3709FC76@nokia.com> <003b01cbceaa$f85540d0$e8ffc270$@com> <34EEDAE3-A7CF-413C-9182-A13608473622@asomi.com> <20110217180411.GK86652@verdi> <5FDC413D5FA246468C200652D63E627A0D12CDA8@LDCMVEXC1-PRD.hq.netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 03 Mar 2011 23:01:49.0674 (UTC) FILETIME=[FA6BC4A0:01CBD9F6] Cc: conex@ietf.org Subject: Re: [conex] WG energy X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 03 Mar 2011 23:00:45 -0000 Caitlin, At 18:05 03/03/2011, Caitlin Bestler wrote: >On Feb 24, 2011, at 2:21 AM, Scheffenegger, Richard wrote: > > > > > > > > >>> In particular, the degree to which an implementation could be > > synergistic > >>> with 802.1 DCB ccongestion control is still very vague. > >> > >> Hmm... > >> > >> I suspect most of us on this list aren't terribly familiar with > >> 802.1Qau. (That is what you're referring to, right?) > >> > >>> An ideal conex draft, in my evaluation, would allow forwarding > > elements > >>> to implement *both* DCB and Conex, and suggest a method by which DCB > >>> congestion could be reported to the IP stack as though it had been > >>> reported by a CONEX device. As well as my response to your most recent posting (later) I wanted to pick up on these sentences, which I let go at the time... I think you meant an ECN device not a ConEx device? Or do I misunderstand? ConEx is an e2e signal in the L3 internetwork protocol, enabling the source transport to provide a measure of congestion on the whole path between L4 endpoints. Forwarding elements don't implement ConEx. A device that *monitors* ConEx might also be a forwarding element, but it doesn't "report ConEx signals to the IP stack". The aim is to take congestion signalling from L2 subnets and propagate it upwards into IP-ECN at L3 alongside this e2e ConEx signal. Then ConEx & ECN are over comparable scopes (both between the L4 endpoints). > >> > >> I'm guessing here... > >> > >> We've been writing in terms of something very like ECN to mark > >> congestion, which marks according to a queue filling. > >> > >> 802.1Qau has an out-of-band mechanism to report "percent congestion" > >> from receiving switch to sender (if I read it correctly, I presume > > that > >> to be between two routers). This does sound like promising > > information, > >> but it's not immediately clear how it should get reported to a Layer 3 > >> device. > > > > Isn't 802.1Qau supposed to throttle / stop all traffic of an offending > > flow (as classified by 802.1Qau - which could be of variable granularity > > depending on the capabilities of the device IIRC) when congestion is > > experienced? > > > > Also, the sender in the 802.1Qau case is a L2 MAC device - which is > > doing the throttling. > > > > The only thing a L3+ sender would notice would either be queues building > > at the L3/L2 interface, or calls to send data would block instead of > > immediately return. > > > > Obvioulsy, filling some queue right in the sender (be it a hardware or > > software queue) is a bad thing (www.bufferbloat.net), so there might be > > some merit in signaling this between layers. However, as all that is > > required happens within the same host, it's more of an API question > > between device driver and software stack, rather than a protocol issue > > concerning the explicit signaling in a L3 header... > > > > Of course, if the egress side of a Router is 802.1Qau, but the ingress > > side is not, the router may want to inform the flow - but standard ECN > > marking (available with IPv4 and IPv6) should do that... > > > > Or am I missing something more? > > > > >If bufferbloat in switches/routers is bad, it is nothing compared to >the buffering >available in hosts. > >A classic L4 congestion algorithm will respond only to drops or ECNs, which >a successful QCN deployment will prevent. So unless L4 is responsive to >queuing delays the predictable impact of QCN on L4 is for L4 to continue to >"floor it" until things finally break. The second sentence seems to agree with Richard, but the first sentence seems to disagree. The 2nd sentence says that the 802.1Qau L2 scheme can only prevent traffic building up at the source of this L2 subnet, while the L3 sitting over this L2 source and feeding it data will just back up into its own buffer unless somehow something can stop the remote L4 sending into this DCB subnet. But then the first sentence cannot be true. QCN alone cannot prevent drops or ECN. QCN can prevent them *at L2*, but not in the L3 above this L2, which is feeding this DC Bridging system from the (probably remote) L4. QCN can only reduce ECN or drops if it has some way to signal up the layers (i.e. ECN or drop). Otherwise, yes, things will finally just break. >Explicitly sharing the information that a flow is being throttled by some form >of queue management, as opposed to wireless retransmissions, would be >useful in helping the L4 algorithms take the optimal response. Ideally this >would be an abstract measurement, rather than requiring the L4 algorithm >understand the specifics of whatever form of Queue Management is being >employed. Much as this is interesting to most of us in the ConEx w-g, we need to be clear that *generating* congestion signals at forwarding devices isn't in the ConEx charter. Generally congestion notification in IP and in lower layers (e.g. MPLS) has been handled in tsvwg. The ADs might want to change that. But that's how it is at the moment. I just posted a new -00 draft to tsvwg: "Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP" It's mostly about propagating congestion signalling from L2 to L3. I tried to deal with QCN alongside similar schemes, but none in great detail. After posting it, I realised it will need a section on the possible different layouts of the layered feedback loops. They're all in there: QCN, ATM, Frame Relay etc, but I didn't explicitly bring out the distinction between these and the way the loops are laid out in ECN-MPLS [RFC5129], for instance. Frankly, given L3 generally uses forward signalling, feedback to the source of a L2 subnet would add unnecessary delay, if that source was then going to signal forwards at L3 towards the L4 destination. The L2 destination might as well signal up to L3 directly at its end. Incidentally, Lei Zhu has been talking about this in ConEx too: Altho again, it's been pointed out that this is off-charter for ConEx. Perhaps we should have a little ad hoc bar BoF in Prague about L2 & ECN? Taking Lars's advice, we should make sure we have it in a real bar. Bob >-- >Caitlin Bestler >cait@asomi.com > > > > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design From toby@moncaster.com Fri Mar 4 01:40:57 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E164A3A695D for ; Fri, 4 Mar 2011 01:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2OElc+m5RTC for ; Fri, 4 Mar 2011 01:40:57 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by core3.amsl.com (Postfix) with ESMTP id C87933A6889 for ; Fri, 4 Mar 2011 01:40:56 -0800 (PST) Received: from TobysHP (host81-158-50-164.range81-158.btcentralplus.com [81.158.50.164]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MCdN8-1Pn9mU0apu-009pyB; Fri, 04 Mar 2011 10:42:00 +0100 From: "Toby Moncaster" To: "'John Leslie'" , "'Caitlin Bestler'" References: <64069EFF-C572-4088-9EF0-9CDE66B20390@cdt.org> <8F242B230AD6474C8E7815DE0B4982D7179FB92C@EXV1.corp.adtran.com> <20110301173738.GO7663@verdi> <86D4248D-F176-46A0-AC1D-B8C9F41D9287@asomi.com> <20110303210140.GE89966@verdi> In-Reply-To: <20110303210140.GE89966@verdi> Date: Fri, 4 Mar 2011 09:42:00 -0000 Message-ID: <000d01cbda50$6979f430$3c6ddc90$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvZ5lkOwI3i8tjeS+uXu/Bi3g4HZAAaYYeg Content-Language: en-gb X-Provags-ID: V02:K0:ECeBbKkZp7zoCKRaxJJ6EvHKdaLS4Wanx9fRkuP5u+2 SrSdyEGXKW/WYCod8acyr98tV/ZXuqsfSi5Thy1nKIdY5RmzwA lr3NvWRAEdJVvtftfWvHSKTd7/Cva2gfvZxyO4zgpLy1G8kfz6 6wWdVXFQ0VovdrkKZQLP6tOv5cH3JzzUkB+Mzp1aIqZ2H8NUhI sWVWUJYLQhKL4nZUW4QkBKSFFUU6vM5aqSQzD58dGY= Cc: conex@ietf.org Subject: Re: [conex] "Congestion" definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2011 09:40:58 -0000 > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of John Leslie > Sent: 03 March 2011 21:02 > To: Caitlin Bestler > Cc: conex@ietf.org > Subject: Re: [conex] "Congestion" definition > > Caitlin Bestler wrote: > > On Mar 1, 2011, at 9:37 AM, John Leslie wrote: > >> STUART VENTERS wrote: > >>> > >>> Congestion is when a packet's forwarding behavior is adversely > affected > >>> because of the traffic load caused by other packets in the cloud. > >>> - 'Adversely affected' means dropped or delayed more than the > minimum > >>> delay seen in an otherwise idle cloud. > >>> - 'Other packets' means either packets from other users or packets > from > >>> the same user. > > > > Two aspects of this definition strike me as needing refinement. > > > > First, other packets come from other flows. Switches/routers do not > > know what this "user" entity is. > > Agreed. So the beter wording would be to remove "'Other packets' means either packets from other users or packets from the same user." And then insert "..., whatever their source, ..." after "caused by other packets..." in the first sentence > > > Secondly the definition of "delay" is far too inclusive. It could be > > interpreted as simply delay waiting for a round-robin turn at the > > transmitter. > > Agreed. I think one could get locked into an endless debate here about sources of delay... > > > QCN (802.1Qau) focuses strictly on queue depth (whether the queue is > > actual or virtual). I think that is appropriate. The results of > > round-robin algorithms are already felt in the queue depth, so there > > is no need to separately measure them. > > Queue depth, IMHO, is a better measure than most things available > to us. And queue depth is effectively what ECN tries to encode, albeit in a slightly odd manner... > > > Queue depth is also easily measured. Combined with a delta measurment > > the results give a very complete understanding of the network, and > > even the delta can be measured inexpensively. Predicting delay caused > > by other queues that share a given transmitter is fairly complex, and > > ultimately unnecessary. The queue is either backing up (which can > > already be measured) or it is not. > > I agree with all of this, but... > > "The light's much better over here!" ;^) > > Can Caitlin (or anyone else) come up with a way to deploy this > throughout enough of the Internet? > > Or, is the bottom-line that we can't design a single Experimental > protocol? I don't think designing them is the problem. Deploying them might be an issue though ;) > > -- > John Leslie > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From dave.mcdysan@verizon.com Fri Mar 4 08:37:02 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 756553A6817 for ; Fri, 4 Mar 2011 08:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p18JVhTUbxDV for ; Fri, 4 Mar 2011 08:36:58 -0800 (PST) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id 971CF3A67AF for ; Fri, 4 Mar 2011 08:36:58 -0800 (PST) Received: from fldsmtpi01.verizon.com (fldsmtpi01.verizon.com [166.68.71.143]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p24GbeOl012901 for ; Fri, 4 Mar 2011 11:37:57 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,264,1297036800"; d="scan'208,217";a="5628540" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi01.verizon.com with ESMTP; 04 Mar 2011 16:37:40 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.147]) by FHDP1LUMXC7HB05.us.one.verizon.com ([2002:a644:3bc0::a644:3bc0]) with mapi; Fri, 4 Mar 2011 11:37:40 -0500 To: "conex@ietf.org" Date: Fri, 4 Mar 2011 11:37:37 -0500 Thread-Topic: Proposed Text for New Section in Use Case Draft - Statistical multiplexing over Longer Timescales Thread-Index: Acvainpgpmw5K8ddSbGxleLC2p6amQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C9967F7E102C5davemcdysanoneverizoncom_" MIME-Version: 1.0 Subject: [conex] Proposed Text for New Section in Use Case Draft - Statistical multiplexing over Longer Timescales X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2011 16:37:02 -0000 --_000_C9967F7E102C5davemcdysanoneverizoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, As documented in the IETF79 Beijing meeting minutes it was agreed that the = concepts from the section titled "Inequity of Heavy versus Light Users" fr= om draft-mcdysan-conex-other-usecases should be included in the WG Concepts= and Use Cases draft. After much discussion (that ranged well beyond this topic, and spawned seve= ral other threads that are not addressed by this proposed text), Toby propo= sed adding a new section to the use case draft and I volunteered to draft c= ontent based upon the original draft as well as the relevant list discussio= n from the thread titled "Discussion of new Use Cases pt 1," along with rel= evant text from the spawned threads. I tried to list all of the people whos= e inputs I used to draft this text and am requesting the use-case draft aut= hors to include your names in the Acknowledgement section (if it was not al= ready there). The title of the proposed new section X has been changed to represent the p= rincipal aspects of the use case, namely statistical multiplexing over long= er timescales. Thanks, Dave ----------------------------------------------------------------- X. Statistical multiplexing over Longer Timescales In this use case the assumption is that "flat rate" or "bandwidth tier" pri= cing is in place. A simplifying assumption is made that there is no very lo= ng term (e.g., monthly) usage tier pricing in place. X.1 Problems Encountered in Existing Networks The principal problem addressed by this use case is that 20% of the users g= enerate 80% of the traffic volume and create unfairness with certain resour= ce sharing [Varian], often without paying any extra for doing so when "flat= rate" or "bandwidth tier" pricing is in effect. The timescale over which t= his difference in traffic volume exists can range from seconds, to many min= utes to hours. The peak rate at which a user can send may be set by the phy= sical transmission system, a non-work conserving scheduler, and/or a police= r. The access network is usually not provisioned and traffic engineered for th= e peak rate for all users but is instead provisioned assuming statistical m= ultiplexing where a longer term (many seconds to minutes to hours) average = capacity is assumed for all users during the busy period. The many minutes = timescale is commonly used by network operators to determine when a portion= of a network is near congestion [section 3.3, Bauer]. During non-busy peri= ods, the service provider network is underutilized and hence there is no co= ngestion of shared resources. During busy periods where congestion (i.e., loss or ECN marking) of a share= d resource (e.g., a queue or scheduler) can occur, heavier users may send a= t speeds up to the peak rate while lighter users may send at a rate much le= ss than the peak rate. The result is that all users see the same congestion= (i.e., loss or ECN marking probability) although the lighter users are sen= ding at much less than the peak rate. Furthermore, when the shared resource= is congested, heavy users create much more congestion volume than light us= ers. In this sense, the response of current networks is "unfair," which is = also called "economic congestion" [section 3.4, Bauer]. The above situation occurs in flat rate pricing where all user flows share = the same resource (e.g., queue, scheduler). In many networks a non work conserving scheduler (e.g., a shaper) implement= s a per-user peak rate over an interval O(100 ms). See Appendix B of [DSL F= orum TR-059] for a DSL specific example of non-work conserving schedulers. = Similar techniques are used in access network equipment across a range of a= ccess technologies. Thus, the "bandwidth tier" incentive is that a user pay= s more if he/she wants more peak rate bandwidth. Such non-work conserving schedulers create apparent congestion (i.e., loss = or ECN marking) within their queue(s) which impact only a single user that = need to be considered in the set of conex use cases. Further discussion on = this topic is covered in the section "Self-Congestion versus Inter-User Con= gestion." X.2 Conex Objectives for a Solution to this Problem The general objective for conex is to provide better information for a prov= ider to address the "unfairness" or "economic congestion" problem described= in the previous section. A specific objective is to achieve a "fairness" measure of bandwidth delive= red in proportion to the user peak rate when congestion of a shared resourc= e occurs. A specific objective is to distinguish heavier users from lighter users ove= r a the statistical multiplexing time interval that can range from seconds,= to minutes, to hours so that network provider traffic management functions= can provide "fairer" allocation of bandwidth. A desirable objective is to distinguish between "self-congestion" and "inte= r-user congestion" so that users could use a mechanism external to conex to= "go faster" in the event that only "self-congestion" is limiting their thr= oughput. X.2 Self-Congestion versus Inter-User Congestion If the user sends at more than the shaper peak rate and there is no congest= ion at a shared resource, then other users are not impacted, and in a sense= this user creates "self-congestion." There is also the case when congestio= n occurs at a shared resource, which causes "inter-user-congestion," where = congestion volume from one user impacts other users. Note that "Self-Conges= tion" can occur when "Inter-User Congestion" occurs. However, a heavier use= r may not create "self-congestion" (i.e., loss or ECN marking) if that user= sends at slightly less than a shaper peak rate (e.g., using LEDBAT). There are (at least) three approaches for addressing this issue. Approaches= 1, 2.a require no change to the conex abstract mechanism [wg-abstract-mech= anism]. Approach 2.b would require signaling of additional information to t= he receiver (could be done separately from conex), and approach 3 may be ab= le to use the conex abstract mechanism, albeit potentially in a different c= onfiguration. 1. Treat "self-congestion" the same as "inter-user congestion" since they b= oth create congestion as perceived by the flow user. 2. Signal more information to the receiver about the cause of loss since the remedy differs: a. For a shared queue, use current draft of abstract mechanism signals to reduce load and choose packets for different treatments. b. For a queue dedicated to a receiver (e.g., shaper) signal information = that the shaper peak rate is the bottleneck to the receiver, so that someho= w (specific mechanism may not fit within the current conex wg charter) the = user could make a request to "go faster." 3. Process and generate conex information at the network element which impl= ements the shaper, which has knowledge of the configured peak rates for the= users as well as local shared resource congestion. This network element ca= n also use information about upstream shared resource congestion as deliver= ed buy the conex protocol. Note that during busy periods "self congestion" may not be the limiting fac= tor, but during non-busy periods it will be the biggest source of apparent = congestion. X.3 Potential Support Using Abstract Mechanism [Editorial Note from Dave: The following was derived list comments as well = as a private input from Toby Moncaster.] The following scenario assumes that all user flows implement conex. The cas= e where not all flows implement conex still needs to be addressed. (Some fo= rm of localized "conex-like" marking may handle this case, since heavier us= ers may have a significant incentive to not implement conex). Also to be ad= dressed is the scenario where heavy users do not create congestion (e.g., u= sing LEDBAT), but there is still a significant difference in average rate, = or burstiness (peak/average). Using the abstract mechanism a heavier user never gets a chance to build u= p any congestion credit, which will not impact their service during non-bus= y periods. However, at peak times it means their service is degraded long b= efore a light user sees any impact. In turn this means the congestion seen = by the light user is less, meeting an important objective. Additional local computations are done as follows. Over a time period rela= ted to the statistical multiplexing interval (e.g., many seconds to minutes= to hours) total up the number of bytes that have been congestion marked an= d the total number of bytes sent per user. Compute the ratio of congested b= ytes to total bytes. The total is a measure of the average rate per user (averaged over the time= period of the total). For example, quantizing users into classes using one threshold on total and= and another threshold on ratio results in a grid that identifies four dist= inct classes of user as follows: +----------------+-------------+-------------+ | Total volume>| | | |v Ratio | Large | Small | +----------------+-------------+-------------+ | High | Heavy User | Bursty User | +----------------+-------------+-------------+ | Low | LEDBAT User | Light User | +----------------+-------------+-------------+ X.4 Additional Support Using other Measures and Mechanisms An additional congestion measure of burstiness (e.g., ratio of peak rate to= average rate over a longer interval than the tiered bandwidth shaper) woul= d allow nodes upstream from the node implementing the shaper to implement t= raffic management. This measure could be derived from signals in the abstra= ct mechanism but would require (a majority) of the heavier senders and rece= ivers to implement conex and also would only work if loss or ECN marking oc= curs. Heavier users may have a significant incentive to not implement conex= , and some additional mechanism to address this issue may be required. Also= , signaling a measure of the burstiness (or something related to it) would = address the scenario where no loss or ECN marking occurs. As an alternative, if a "light weight" TCP proxy were implemented at the ne= twork element containing the shaper (e.g., an access router) and an upstrea= m network element (e.g., a router at ingress to the service provider networ= k), then potentially a conex control loop could be created between these ne= twork elements to provide fairer treatment between heavier and lighter user= s during congested intervals. In this case, a subset of conex features coul= d potentially be used since this would be a closed domain where the signals= could be implicitly trusted. The burstiness measure could be communicated = using TCP extensions between these proxies. There is also the aspect of "self congestion" when a non-work conserving sc= heduler (e.g., shaper) is employed at the access node. Even when "inter-use= r congestion" is not occurring (e.g., during a non-busy period), "self cong= estion" may occur. However, as discussed in the section on "Self Congestion= versus Inter-User Congestion," using current mechanisms (i.e., implicitly = determined loss or ECN marking) the receiver cannot tell the difference bet= ween "self-congestion" and "inter-user congestion." Adding a signal to the = abstract mechanism could be quite useful so that a receiver can inform the = sender regarding the cause of congestion, and enable the sender (or the rec= eiver) to communicate with the network element controlling the shaper param= eters enabling the flow to "go faster." using some non-conex mechanism. --------------------- [Editorial Note: Please add the following] Acknowledgements Add the following: Stuart Venters, Mikael Abrahamsson, Mirja Kuehlewind, = Jo=E3o Taveira Ara=FAjo, Caitlin Bestler, Steven Bauer, =85 [Editorial Note: My thanks for inputs from authors, folks already listed in= Acknowledgements: Toby Moncaster, John Leslie, Alissa Cooper, Rich Woundy,= =85] References [DSL Forum TR-059] Technical Report DSL Forum TR-059, "DSL Evolution - Arch= itecture Requirements for the Support of QoS-Enabled IP Services," Septembe= r 2003, http://www.broadband-forum.org/technical/download/TR-059.pdf [Varian] Hal Varian, Google, "Congestion pricing principles," IETF 78 Techn= ical Plenary, 29 July 2010 [Bauer] Steven Bauer, David Clark, William Lehr, "The Evolution of Interne= t Congestion," Massachusetts Institute of Technology, 2009 --_000_C9967F7E102C5davemcdysanoneverizoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi,
&n= bsp;
As documented = in the IETF79 Beijing meeting minutes it was agreed that the concepts from = the section titled "Inequity of Heavy versus Light Users"  f= rom draft-mcdysan-conex-other-usecases should be included in the WG Concept= s and Use Cases draft. 

Afte= r much discussion (that ranged well beyond this topic, and spawned several = other threads that are not addressed by this proposed text), Toby proposed = adding a new section to the use case draft and I volunteered to draft conte= nt based upon the original draft as well as the relevant list discussion fr= om the thread titled "Discussion of new Use Cases pt 1," along wi= th relevant text from the spawned threads. I tried to list all of the peopl= e whose inputs I used to draft this text and am requesting the use-case dra= ft authors to include your names in the Acknowledgement section (if it was = not already there).

The title of = the proposed new section X has been changed to represent the principal aspe= cts of the use case, namely statistical multiplexing over longer timescales= .

=
Thanks,

Dave
-----------------------------------------------------------------

<= span style=3D"font-family: Courier; ">X.  Statistical multiplexing ove= r Longer Timescales

In this use c= ase the assumption is that "flat rate" or "bandwidth tier&qu= ot; pricing is in place. A simplifying assumption is made that there is no = very long term (e.g., monthly) usage tier pricing in place.

X.1 Problems Encountered in Existing Networks

The principal problem addressed by= this use case is that 20% of the users generate 80% of the traffic volume = and create unfairness with certain resource sharing [Varian], often without= paying any extra for doing so when "flat rate" or "bandwidt= h tier" pricing is in effect. The timescale over which this difference= in traffic volume exists can range from seconds, to many minutes to hours.= The peak rate at which a user can send may be set by the physical transmis= sion system, a non-work conserving scheduler, and/or a policer. 

The access network is usually not prov= isioned and traffic engineered for the peak rate for all users but is inste= ad provisioned assuming statistical multiplexing where a longer term (many = seconds to minutes to hours) average capacity is assumed for all users duri= ng the busy period. The many minutes timescale is commonly used by network = operators to determine when a portion of a network is near congestion [sect= ion 3.3, Bauer]. During non-busy periods, the service provider network is u= nderutilized and hence there is no congestion of shared resources. 

During busy periods where congestio= n (i.e., loss or ECN marking) of a shared resource (e.g., a queue or schedu= ler) can occur, heavier users may send at speeds up to the peak rate while = lighter users may send at a rate much less than the peak rate. The result i= s that all users see the same congestion (i.e., loss or ECN marking probabi= lity) although the lighter users are sending at much less than the peak rat= e. Furthermore, when the shared resource is congested, heavy users create m= uch more congestion volume than light users. In this sense, the response of= current networks is "unfair," which is also called "economi= c congestion" [section 3.4, Bauer].

The above situation occurs in flat rate pricing where all user flow= s share the same resource (e.g., queue, scheduler). 
=
In many networks a non work conserving scheduler (= e.g., a shaper) implements a per-user peak rate over an interval O(100 ms).= See Appendix B of [DSL Forum TR-059] for a DSL specific example of non-wor= k conserving schedulers. Similar techniques are used in access network equi= pment across a range of access technologies. Thus, the "bandwidth tier= " incentive is that a user pays more if he/she wants more peak rate ba= ndwidth. 

=
Such non-work cons= erving schedulers create apparent congestion (i.e., loss or ECN marking) wi= thin their queue(s) which impact only a single user that need to be conside= red in the set of conex use cases. Further discussion on this topic is cove= red in the section "Self-Congestion versus Inter-User Congestion."= ;

=
X.2 Conex Objectives for a Solu= tion to this Problem
The general = objective for conex is to provide better information for a provider to addr= ess the "unfairness" or "economic congestion" problem d= escribed in the previous section.  

A specific objective is to achieve a "fairness" measure o= f bandwidth delivered in proportion to the user peak rate when congestion o= f a shared resource occurs. 

A specific objective is to distinguish heavier users from lighter users ov= er a the statistical multiplexing time interval that can range from seconds= , to minutes, to hours so that network provider traffic management function= s can provide "fairer" allocation of bandwidth.
=
A desirable objective is to distinguish between &q= uot;self-congestion" and "inter-user congestion" so that use= rs could use a mechanism external to conex to "go faster" in the = event that only "self-congestion" is limiting their throughput.

X.2 Self-Congestion versus Inter-U= ser Congestion

=
If the user sends = at more than the shaper peak rate and there is no congestion at a shared re= source, then other users are not impacted, and in a sense this user creates= "self-congestion." There is also the case when congestion occurs= at a shared resource, which causes "inter-user-congestion," wher= e congestion volume from one user impacts other users. Note that "Self= -Congestion" can occur when "Inter-User Congestion" occurs. = However, a heavier user may not create "self-congestion" (i.e., l= oss or ECN marking) if that user sends at slightly less than a shaper peak = rate (e.g., using LEDBAT). 

= There are (at least) three approaches for addressing this issue. Approaches= 1, 2.a require no change to the conex abstract mechanism [wg-abstract-mech= anism]. Approach 2.b would require signaling of additional information to t= he receiver (could be done separately from conex), and approach 3 may be ab= le to use the conex abstract mechanism, albeit potentially in a different c= onfiguration. 

1. Treat &quo= t;self-congestion" the same as "inter-user congestion" since= they both create congestion as perceived by the flow user.

2. Signal more information to the receiver abou= t the cause of loss since
the remedy differs:
  a. For a shared queue, use current draft of abstract me= chanism signals
to = reduce load and choose packets for different treatments.
<= span style=3D"font-family: Courier; ">  b. For a queue dedicated = to a receiver (e.g., shaper) signal information that the shaper peak rate i= s the bottleneck to the receiver, so that somehow (specific mechanism may n= ot fit within the current conex wg charter) the user could make a request t= o "go faster."

3. Proce= ss and generate conex information at the network element which implements t= he shaper, which has knowledge of the configured peak rates for the users a= s well as local shared resource congestion. This network element can also u= se information about upstream shared resource congestion as delivered buy t= he conex protocol.
=
Note that duri= ng busy periods "self congestion" may not be the limiting factor,= but during non-busy periods it will be the biggest source of apparent cong= estion.

=
X.3 Potential Support Usi= ng Abstract Mechanism
[Editorial = Note from Dave: The following was derived list comments as well as a privat= e input from Toby Moncaster.]

The= following scenario assumes that all user flows implement conex. The case w= here not all flows implement conex still needs to be addressed. (Some form = of localized "conex-like" marking may handle this case, since hea= vier users may have a significant incentive to not implement conex). Also t= o be addressed is the scenario where heavy users do not create congestion (= e.g., using LEDBAT), but there is still a significant difference in average= rate, or burstiness (peak/average).

Using the abstract mechanism a heavier user  never gets a chance t= o build up any congestion credit, which will not impact their service durin= g non-busy periods. However, at peak times it means their service is degrad= ed long before a light user sees any impact. In turn this means the congest= ion seen by the light user is less, meeting an important objective. 

Additional local computations are = done as follows. Over a  time period related to the statistical multip= lexing interval (e.g., many seconds to minutes to hours) total up the numbe= r of bytes that have been congestion marked and the total number of bytes s= ent per user. Compute the ratio of congested bytes to total bytes. 

The total is a measure of the avera= ge rate per user (averaged over the time period of the total).=

For example, quantizing users into classes us= ing one threshold on total and and another threshold on ratio results in a = grid that identifies four distinct classes of user as follows:
=

+----------------+-------------+-= ------------+
|=   Total volume>|             |  = ;           |
|v Ratio         |    Lar= ge    |    Small    |
+----------------+-------------= 3;-------------+
+----------= ------+-------------+-------------+
|   Low          = ;| LEDBAT User | Light User  |
+----------------+-------------+-------------&= #43;

X.4 Additional Support Using= other Measures and Mechanisms

An= additional congestion measure of burstiness (e.g., ratio of peak rate to a= verage rate over a longer interval than the tiered bandwidth shaper) would = allow nodes upstream from the node implementing the shaper to implement tra= ffic management. This measure could be derived from signals in the abstract= mechanism but would require (a majority) of the heavier senders and receiv= ers to implement conex and also would only work if loss or ECN marking occu= rs. Heavier users may have a significant incentive to not implement conex, = and some additional mechanism to address this issue may be required. Also, = signaling a measure of the burstiness (or something related to it) would ad= dress the scenario where no loss or ECN marking occurs.

As an alternative, if a "light weight" TCP= proxy were implemented at the network element containing the shaper (e.g.,= an access router) and an upstream network element (e.g., a router at ingre= ss to the service provider network), then potentially a conex control loop = could be created between these network elements to provide fairer treatment= between heavier and lighter users during congested intervals. In this case= , a subset of conex features could potentially be used since this would be = a closed domain where the signals could be implicitly trusted. The burstine= ss measure could be communicated using TCP extensions between these proxies= .

=
There is also the aspect of &qu= ot;self congestion" when a non-work conserving scheduler (e.g., shaper= ) is employed at the access node. Even when "inter-user congestion&quo= t; is not occurring (e.g., during a non-busy period), "self congestion= " may occur. However, as discussed in the section on "Self Conges= tion versus Inter-User Congestion," using current mechanisms (i.e., im= plicitly determined loss or ECN marking) the receiver cannot tell the diffe= rence between "self-congestion" and "inter-user congestion.&= quot; Adding a signal to the abstract mechanism could be quite useful so th= at a receiver can inform the sender regarding the cause of congestion, and = enable the sender (or the receiver) to communicate with the network element= controlling the shaper parameters enabling the flow to "go faster.&qu= ot; using some non-conex mechanism.

-----------= ----------

[Editorial Note: Pleas= e add the following]
Acknowledgem= ents

Add the following:  Stu= art Venters, Mikael Abrahamsson, Mirja Kuehlewind,  Jo=E3o Taveira Ara= =FAjo, Caitlin Bestler, Steven Bauer, =85

[Editorial Note: My thanks for inputs from authors, folks already = listed in Acknowledgements: Toby Moncaster, John Leslie, Alissa Cooper, Ric= h Woundy, =85]

=
References<= /div>

[DSL Forum TR-059] Technical Report DSL = Forum TR-059, "DSL Evolution - Architecture Requirements for the Suppo= rt of QoS-Enabled IP Services," September 2003, http://www.broadband-f= orum.org/technical/download/TR-059.pdf

[Varian] Hal Varian, Google, "Congestion pricing principles,&quo= t; IETF 78 Technical Plenary, 29 July 2010

[Bauer] Steven Bauer, David Clark, William Lehr,  "The = Evolution of Internet Congestion," Massachusetts Institute of Technolo= gy, 2009


 
--_000_C9967F7E102C5davemcdysanoneverizoncom_-- From toby@moncaster.com Fri Mar 4 09:46:01 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 317483A67B1 for ; Fri, 4 Mar 2011 09:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnIRZ9jWYPhN for ; Fri, 4 Mar 2011 09:45:45 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id 7DA343A6856 for ; Fri, 4 Mar 2011 09:45:43 -0800 (PST) Received: from TobysHP (host81-158-50-164.range81-158.btcentralplus.com [81.158.50.164]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MErUc-1Pl6qL3zgo-00Fzgw; Fri, 04 Mar 2011 18:46:49 +0100 From: "Toby Moncaster" To: "'Mcdysan, David E'" , References: In-Reply-To: Date: Fri, 4 Mar 2011 17:46:49 -0000 Message-ID: <005c01cbda94$239ae5c0$6ad0b140$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005D_01CBDA94.239AE5C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvainpgpmw5K8ddSbGxleLC2p6amQACUAGg Content-Language: en-gb X-Provags-ID: V02:K0:3V0k16WfrOjVWJ3SIrYOcmMT7j8Y7qBhnnhbh4Mam+o yCu5+avL7Stzq7Ucrbv1ww/gw0IAPkZIImv5rzFJ6NSDLQVP72 w3aepOe1F2pSBQkH3nVp6vblCoGqqfs+M+vh2Y1OtGBj1cotHR QiL2lxDFOSc2kJ887ui11oaX/l+9gA2lgO9eR/syJ8Gcw7KzpS hE6iAvLTdc5PgYA+560TNAqnxUvFPVUF4rdr+ivrT0= Subject: Re: [conex] Proposed Text for New Section in Use Case Draft - Statistical multiplexing over Longer Timescales X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2011 17:46:01 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_005D_01CBDA94.239AE5C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dave, =20 Thanks for this text. I haven=92t actually read through it yet. I will incorporate it in the new version of the draft which I am hoping to = release by next weekend. =20 I will also update the acknowledgements list (something we had been = asked to do already by the WG chairs). =20 Toby =20 From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf = Of Mcdysan, David E Sent: 04 March 2011 16:38 To: conex@ietf.org Subject: [conex] Proposed Text for New Section in Use Case Draft - Statistical multiplexing over Longer Timescales =20 Hi, =20 As documented in the IETF79 Beijing meeting minutes it was agreed that = the concepts from the section titled "Inequity of Heavy versus Light Users" from draft-mcdysan-conex-other-usecases should be included in the WG Concepts and Use Cases draft.=20 =20 After much discussion (that ranged well beyond this topic, and spawned several other threads that are not addressed by this proposed text), = Toby proposed adding a new section to the use case draft and I volunteered to draft content based upon the original draft as well as the relevant list discussion from the thread titled "Discussion of new Use Cases pt 1," = along with relevant text from the spawned threads. I tried to list all of the people whose inputs I used to draft this text and am requesting the = use-case draft authors to include your names in the Acknowledgement section (if = it was not already there). =20 The title of the proposed new section X has been changed to represent = the principal aspects of the use case, namely statistical multiplexing over longer timescales. =20 Thanks, =20 Dave ----------------------------------------------------------------- =20 X. Statistical multiplexing over Longer Timescales =20 In this use case the assumption is that "flat rate" or "bandwidth tier" pricing is in place. A simplifying assumption is made that there is no = very long term (e.g., monthly) usage tier pricing in place. =20 X.1 Problems Encountered in Existing Networks =20 The principal problem addressed by this use case is that 20% of the = users generate 80% of the traffic volume and create unfairness with certain resource sharing [Varian], often without paying any extra for doing so = when "flat rate" or "bandwidth tier" pricing is in effect. The timescale over which this difference in traffic volume exists can range from seconds, = to many minutes to hours. The peak rate at which a user can send may be set = by the physical transmission system, a non-work conserving scheduler, = and/or a policer.=20 =20 The access network is usually not provisioned and traffic engineered for = the peak rate for all users but is instead provisioned assuming statistical multiplexing where a longer term (many seconds to minutes to hours) = average capacity is assumed for all users during the busy period. The many = minutes timescale is commonly used by network operators to determine when a = portion of a network is near congestion [section 3.3, Bauer]. During non-busy periods, the service provider network is underutilized and hence there = is no congestion of shared resources.=20 =20 During busy periods where congestion (i.e., loss or ECN marking) of a = shared resource (e.g., a queue or scheduler) can occur, heavier users may send = at speeds up to the peak rate while lighter users may send at a rate much = less than the peak rate. The result is that all users see the same congestion (i.e., loss or ECN marking probability) although the lighter users are sending at much less than the peak rate. Furthermore, when the shared resource is congested, heavy users create much more congestion volume = than light users. In this sense, the response of current networks is = "unfair," which is also called "economic congestion" [section 3.4, Bauer]. =20 The above situation occurs in flat rate pricing where all user flows = share the same resource (e.g., queue, scheduler).=20 =20 In many networks a non work conserving scheduler (e.g., a shaper) = implements a per-user peak rate over an interval O(100 ms). See Appendix B of [DSL Forum TR-059] for a DSL specific example of non-work conserving = schedulers. Similar techniques are used in access network equipment across a range = of access technologies. Thus, the "bandwidth tier" incentive is that a user pays more if he/she wants more peak rate bandwidth.=20 =20 Such non-work conserving schedulers create apparent congestion (i.e., = loss or ECN marking) within their queue(s) which impact only a single user = that need to be considered in the set of conex use cases. Further discussion = on this topic is covered in the section "Self-Congestion versus Inter-User Congestion." =20 X.2 Conex Objectives for a Solution to this Problem =20 The general objective for conex is to provide better information for a provider to address the "unfairness" or "economic congestion" problem described in the previous section. =20 =20 A specific objective is to achieve a "fairness" measure of bandwidth delivered in proportion to the user peak rate when congestion of a = shared resource occurs.=20 =20 A specific objective is to distinguish heavier users from lighter users = over a the statistical multiplexing time interval that can range from = seconds, to minutes, to hours so that network provider traffic management functions = can provide "fairer" allocation of bandwidth. =20 A desirable objective is to distinguish between "self-congestion" and "inter-user congestion" so that users could use a mechanism external to conex to "go faster" in the event that only "self-congestion" is = limiting their throughput. =20 X.2 Self-Congestion versus Inter-User Congestion =20 If the user sends at more than the shaper peak rate and there is no congestion at a shared resource, then other users are not impacted, and = in a sense this user creates "self-congestion." There is also the case when congestion occurs at a shared resource, which causes "inter-user-congestion," where congestion volume from one user impacts = other users. Note that "Self-Congestion" can occur when "Inter-User = Congestion" occurs. However, a heavier user may not create "self-congestion" (i.e., = loss or ECN marking) if that user sends at slightly less than a shaper peak = rate (e.g., using LEDBAT).=20 =20 There are (at least) three approaches for addressing this issue. = Approaches 1, 2.a require no change to the conex abstract mechanism [wg-abstract-mechanism]. Approach 2.b would require signaling of = additional information to the receiver (could be done separately from conex), and approach 3 may be able to use the conex abstract mechanism, albeit potentially in a different configuration.=20 =20 1. Treat "self-congestion" the same as "inter-user congestion" since = they both create congestion as perceived by the flow user. =20 2. Signal more information to the receiver about the cause of loss since the remedy differs: a. For a shared queue, use current draft of abstract mechanism signals to reduce load and choose packets for different treatments. b. For a queue dedicated to a receiver (e.g., shaper) signal = information that the shaper peak rate is the bottleneck to the receiver, so that = somehow (specific mechanism may not fit within the current conex wg charter) the user could make a request to "go faster." =20 3. Process and generate conex information at the network element which implements the shaper, which has knowledge of the configured peak rates = for the users as well as local shared resource congestion. This network = element can also use information about upstream shared resource congestion as delivered buy the conex protocol. =20 Note that during busy periods "self congestion" may not be the limiting factor, but during non-busy periods it will be the biggest source of apparent congestion. =20 X.3 Potential Support Using Abstract Mechanism =20 [Editorial Note from Dave: The following was derived list comments as = well as a private input from Toby Moncaster.] =20 The following scenario assumes that all user flows implement conex. The = case where not all flows implement conex still needs to be addressed. (Some = form of localized "conex-like" marking may handle this case, since heavier = users may have a significant incentive to not implement conex). Also to be addressed is the scenario where heavy users do not create congestion = (e.g., using LEDBAT), but there is still a significant difference in average = rate, or burstiness (peak/average). =20 Using the abstract mechanism a heavier user never gets a chance to = build up any congestion credit, which will not impact their service during = non-busy periods. However, at peak times it means their service is degraded long before a light user sees any impact. In turn this means the congestion = seen by the light user is less, meeting an important objective.=20 =20 Additional local computations are done as follows. Over a time period related to the statistical multiplexing interval (e.g., many seconds to minutes to hours) total up the number of bytes that have been congestion marked and the total number of bytes sent per user. Compute the ratio of congested bytes to total bytes.=20 =20 The total is a measure of the average rate per user (averaged over the = time period of the total). =20 For example, quantizing users into classes using one threshold on total = and and another threshold on ratio results in a grid that identifies four distinct classes of user as follows: =20 +----------------+-------------+-------------+ | Total volume>| | | |v Ratio | Large | Small | +----------------+-------------+-------------+ | High | Heavy User | Bursty User | +----------------+-------------+-------------+ | Low | LEDBAT User | Light User | +----------------+-------------+-------------+ =20 X.4 Additional Support Using other Measures and Mechanisms =20 An additional congestion measure of burstiness (e.g., ratio of peak rate = to average rate over a longer interval than the tiered bandwidth shaper) = would allow nodes upstream from the node implementing the shaper to implement traffic management. This measure could be derived from signals in the abstract mechanism but would require (a majority) of the heavier senders = and receivers to implement conex and also would only work if loss or ECN = marking occurs. Heavier users may have a significant incentive to not implement conex, and some additional mechanism to address this issue may be = required. Also, signaling a measure of the burstiness (or something related to it) would address the scenario where no loss or ECN marking occurs. =20 As an alternative, if a "light weight" TCP proxy were implemented at the network element containing the shaper (e.g., an access router) and an upstream network element (e.g., a router at ingress to the service = provider network), then potentially a conex control loop could be created between these network elements to provide fairer treatment between heavier and lighter users during congested intervals. In this case, a subset of = conex features could potentially be used since this would be a closed domain = where the signals could be implicitly trusted. The burstiness measure could be communicated using TCP extensions between these proxies. =20 There is also the aspect of "self congestion" when a non-work conserving scheduler (e.g., shaper) is employed at the access node. Even when "inter-user congestion" is not occurring (e.g., during a non-busy = period), "self congestion" may occur. However, as discussed in the section on = "Self Congestion versus Inter-User Congestion," using current mechanisms = (i.e., implicitly determined loss or ECN marking) the receiver cannot tell the difference between "self-congestion" and "inter-user congestion." Adding = a signal to the abstract mechanism could be quite useful so that a = receiver can inform the sender regarding the cause of congestion, and enable the sender (or the receiver) to communicate with the network element = controlling the shaper parameters enabling the flow to "go faster." using some = non-conex mechanism. =20 =20 --------------------- =20 [Editorial Note: Please add the following] =20 Acknowledgements =20 Add the following: Stuart Venters, Mikael Abrahamsson, Mirja = Kuehlewind, Jo=E3o Taveira Ara=FAjo, Caitlin Bestler, Steven Bauer, =85 =20 [Editorial Note: My thanks for inputs from authors, folks already listed = in Acknowledgements: Toby Moncaster, John Leslie, Alissa Cooper, Rich = Woundy, =85] =20 References =20 [DSL Forum TR-059] Technical Report DSL Forum TR-059, "DSL Evolution - Architecture Requirements for the Support of QoS-Enabled IP Services," September 2003, = http://www.broadband-forum.org/technical/download/TR-059.pdf =20 [Varian] Hal Varian, Google, "Congestion pricing principles," IETF 78 Technical Plenary, 29 July 2010 =20 [Bauer] Steven Bauer, David Clark, William Lehr, "The Evolution of = Internet Congestion," Massachusetts Institute of Technology, 2009 =20 =20 =20 ------=_NextPart_000_005D_01CBDA94.239AE5C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Dave,

 

Thanks for this text. I haven’t actually read through it yet. I = will incorporate it in the new version of the draft which I am hoping to = release by next weekend.

 

I will also update the acknowledgements list (something we had been = asked to do already by the WG chairs).

 

Toby

 

From:= = conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of = Mcdysan, David E
Sent: 04 March 2011 16:38
To: = conex@ietf.org
Subject: [conex] Proposed Text for New Section = in Use Case Draft - Statistical multiplexing over Longer = Timescales

 

Hi,

 <= span = style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'= >

As documented = in the IETF79 Beijing meeting minutes it was agreed that the concepts = from the section titled "Inequity of Heavy versus Light Users" =  from draft-mcdysan-conex-other-usecases should be included in the = WG Concepts and Use Cases draft. 

 

After much = discussion (that ranged well beyond this topic, and spawned several = other threads that are not addressed by this proposed text), Toby = proposed adding a new section to the use case draft and I volunteered to = draft content based upon the original draft as well as the relevant list = discussion from the thread titled "Discussion of new Use Cases pt = 1," along with relevant text from the spawned threads. I tried to = list all of the people whose inputs I used to draft this text and am = requesting the use-case draft authors to include your names in the = Acknowledgement section (if it was not already there).

 

The title of = the proposed new section X has been changed to represent the principal = aspects of the use case, namely statistical multiplexing over longer = timescales.

 

Thanks,=

 

Dave

--------------= ---------------------------------------------------

 

X. =  Statistical multiplexing over Longer Timescales

 

In this use = case the assumption is that "flat rate" or "bandwidth = tier" pricing is in place. A simplifying assumption is made that = there is no very long term (e.g., monthly) usage tier pricing in = place.

 

X.1 Problems = Encountered in Existing Networks

 

The principal = problem addressed by this use case is that 20% of the users generate 80% = of the traffic volume and create unfairness with certain resource = sharing [Varian], often without paying any extra for doing so when = "flat rate" or "bandwidth tier" pricing is in = effect. The timescale over which this difference in traffic volume = exists can range from seconds, to many minutes to hours. The peak rate = at which a user can send may be set by the physical transmission system, = a non-work conserving scheduler, and/or a policer. 

 

The access = network is usually not provisioned and traffic engineered for the peak = rate for all users but is instead provisioned assuming statistical = multiplexing where a longer term (many seconds to minutes to hours) = average capacity is assumed for all users during the busy period. The = many minutes timescale is commonly used by network operators to = determine when a portion of a network is near congestion [section 3.3, = Bauer]. During non-busy periods, the service provider network is = underutilized and hence there is no congestion of shared = resources. 

 

During busy = periods where congestion (i.e., loss or ECN marking) of a shared = resource (e.g., a queue or scheduler) can occur, heavier users may send = at speeds up to the peak rate while lighter users may send at a rate = much less than the peak rate. The result is that all users see the same = congestion (i.e., loss or ECN marking probability) although the lighter = users are sending at much less than the peak rate. Furthermore, when the = shared resource is congested, heavy users create much more congestion = volume than light users. In this sense, the response of current networks = is "unfair," which is also called "economic = congestion" [section 3.4, Bauer].

 

The above = situation occurs in flat rate pricing where all user flows share the = same resource (e.g., queue, scheduler). 

 

In many = networks a non work conserving scheduler (e.g., a shaper) implements a = per-user peak rate over an interval O(100 ms). See Appendix B of [DSL = Forum TR-059] for a DSL specific example of non-work conserving = schedulers. Similar techniques are used in access network equipment = across a range of access technologies. Thus, the "bandwidth = tier" incentive is that a user pays more if he/she wants more peak = rate bandwidth. 

 

Such non-work = conserving schedulers create apparent congestion (i.e., loss or ECN = marking) within their queue(s) which impact only a single user that need = to be considered in the set of conex use cases. Further discussion on = this topic is covered in the section "Self-Congestion versus = Inter-User Congestion."

 

X.2 Conex = Objectives for a Solution to this Problem

 

The general = objective for conex is to provide better information for a provider to = address the "unfairness" or "economic congestion" = problem described in the previous section.  

 

A specific = objective is to achieve a "fairness" measure of bandwidth = delivered in proportion to the user peak rate when congestion of a = shared resource occurs. 

 

A specific = objective is to distinguish heavier users from lighter users over a the = statistical multiplexing time interval that can range from seconds, to = minutes, to hours so that network provider traffic management functions = can provide "fairer" allocation of bandwidth.

 

A desirable = objective is to distinguish between "self-congestion" and = "inter-user congestion" so that users could use a mechanism = external to conex to "go faster" in the event that only = "self-congestion" is limiting their throughput.

 

X.2 = Self-Congestion versus Inter-User Congestion

 

If the user = sends at more than the shaper peak rate and there is no congestion at a = shared resource, then other users are not impacted, and in a sense this = user creates "self-congestion." There is also the case when = congestion occurs at a shared resource, which causes = "inter-user-congestion," where congestion volume from one user = impacts other users. Note that "Self-Congestion" can occur = when "Inter-User Congestion" occurs. However, a heavier user = may not create "self-congestion" (i.e., loss or ECN marking) = if that user sends at slightly less than a shaper peak rate (e.g., using = LEDBAT). 

 

There are (at = least) three approaches for addressing this issue. Approaches 1, 2.a = require no change to the conex abstract mechanism = [wg-abstract-mechanism]. Approach 2.b would require signaling of = additional information to the receiver (could be done separately from = conex), and approach 3 may be able to use the conex abstract mechanism, = albeit potentially in a different configuration. 

 

1. Treat = "self-congestion" the same as "inter-user = congestion" since they both create congestion as perceived by the = flow user.

 

2. Signal = more information to the receiver about the cause of loss = since

the remedy = differs:

  a.= For a shared queue, use current draft of abstract mechanism = signals

to reduce = load and choose packets for different treatments.

  b.= For a queue dedicated to a receiver (e.g., shaper) signal information = that the shaper peak rate is the bottleneck to the receiver, so that = somehow (specific mechanism may not fit within the current conex wg = charter) the user could make a request to "go = faster."

 

3. Process = and generate conex information at the network element which implements = the shaper, which has knowledge of the configured peak rates for the = users as well as local shared resource congestion. This network element = can also use information about upstream shared resource congestion as = delivered buy the conex protocol.

 

Note that = during busy periods "self congestion" may not be the limiting = factor, but during non-busy periods it will be the biggest source of = apparent congestion.

 

X.3 Potential = Support Using Abstract Mechanism

 

[Editorial = Note from Dave: The following was derived list comments as well as a = private input from Toby Moncaster.]

 

The following = scenario assumes that all user flows implement conex. The case where not = all flows implement conex still needs to be addressed. (Some form of = localized "conex-like" marking may handle this case, since = heavier users may have a significant incentive to not implement conex). = Also to be addressed is the scenario where heavy users do not create = congestion (e.g., using LEDBAT), but there is still a significant = difference in average rate, or burstiness (peak/average).

 

Using the = abstract mechanism a heavier user  never gets a chance to build up = any congestion credit, which will not impact their service during = non-busy periods. However, at peak times it means their service is = degraded long before a light user sees any impact. In turn this means = the congestion seen by the light user is less, meeting an important = objective. 

 

Additional = local computations are done as follows. Over a  time period related = to the statistical multiplexing interval (e.g., many seconds to minutes = to hours) total up the number of bytes that have been congestion marked = and the total number of bytes sent per user. Compute the ratio of = congested bytes to total bytes. 

 

The total is = a measure of the average rate per user (averaged over the time period of = the total).

 

For example, = quantizing users into classes using one threshold on total and and = another threshold on ratio results in a grid that identifies four = distinct classes of user as follows:

 

+-------------= ---+-------------+-------------+

|   = Total volume>|             |   =           |

|v Ratio =         |    Large    |   =  Small    |

+-------------= ---+-------------+-------------+

|   High =         | Heavy User  | Bursty User = |

+-------------= ---+-------------+-------------+

|   Low =          | LEDBAT User | Light User =  |

+-------------= ---+-------------+-------------+

 

X.4 = Additional Support Using other Measures and Mechanisms

 

An additional = congestion measure of burstiness (e.g., ratio of peak rate to average = rate over a longer interval than the tiered bandwidth shaper) would = allow nodes upstream from the node implementing the shaper to implement = traffic management. This measure could be derived from signals in the = abstract mechanism but would require (a majority) of the heavier senders = and receivers to implement conex and also would only work if loss or ECN = marking occurs. Heavier users may have a significant incentive to not = implement conex, and some additional mechanism to address this issue may = be required. Also, signaling a measure of the burstiness (or something = related to it) would address the scenario where no loss or ECN marking = occurs.

 

As an = alternative, if a "light weight" TCP proxy were implemented at = the network element containing the shaper (e.g., an access router) and = an upstream network element (e.g., a router at ingress to the service = provider network), then potentially a conex control loop could be = created between these network elements to provide fairer treatment = between heavier and lighter users during congested intervals. In this = case, a subset of conex features could potentially be used since this = would be a closed domain where the signals could be implicitly trusted. = The burstiness measure could be communicated using TCP extensions = between these proxies.

 

There is also = the aspect of "self congestion" when a non-work conserving = scheduler (e.g., shaper) is employed at the access node. Even when = "inter-user congestion" is not occurring (e.g., during a = non-busy period), "self congestion" may occur. However, as = discussed in the section on "Self Congestion versus Inter-User = Congestion," using current mechanisms (i.e., implicitly determined = loss or ECN marking) the receiver cannot tell the difference between = "self-congestion" and "inter-user congestion." = Adding a signal to the abstract mechanism could be quite useful so that = a receiver can inform the sender regarding the cause of congestion, and = enable the sender (or the receiver) to communicate with the network = element controlling the shaper parameters enabling the flow to "go = faster." using some non-conex mechanism.

 

 

--------------= -------

 

[Editorial = Note: Please add the following]

 

Acknowledgemen= ts

 

Add the = following:  Stuart Venters, Mikael Abrahamsson, Mirja Kuehlewind, =  Jo=E3o Taveira Ara=FAjo, Caitlin Bestler, Steven Bauer, = …

 

[Editorial = Note: My thanks for inputs from authors, folks already listed in = Acknowledgements: Toby Moncaster, John Leslie, Alissa Cooper, Rich = Woundy, …]

 

References

 

[DSL Forum = TR-059] Technical Report DSL Forum TR-059, "DSL Evolution - = Architecture Requirements for the Support of QoS-Enabled IP = Services," September 2003, = http://www.broadband-forum.org/technical/download/TR-059.pdf

 

[Varian] Hal = Varian, Google, "Congestion pricing principles," IETF 78 = Technical Plenary, 29 July 2010

 

[Bauer] = Steven Bauer, David Clark, William Lehr,  "The Evolution of = Internet Congestion," Massachusetts Institute of Technology, = 2009

 

 

 <= span = style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'= >

------=_NextPart_000_005D_01CBDA94.239AE5C0-- From john@jlc.net Fri Mar 4 12:42:26 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0D2F3A69F3 for ; Fri, 4 Mar 2011 12:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.571 X-Spam-Level: X-Spam-Status: No, score=-106.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7jqFPWz-WEz for ; Fri, 4 Mar 2011 12:42:26 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id D096D3A69BE for ; Fri, 4 Mar 2011 12:42:25 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 9CE3A33C28; Fri, 4 Mar 2011 15:43:35 -0500 (EST) Date: Fri, 4 Mar 2011 15:43:35 -0500 From: John Leslie To: "Mcdysan, David E" Message-ID: <20110304204335.GF89966@verdi> References: 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.org" Subject: Re: [conex] Proposed Text for New Section in Use Case Draft - Statistical multiplexing over Longer Timescales X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2011 20:42:26 -0000 Mcdysan, David E wrote: > > X. Statistical multiplexing over Longer Timescales >... Thanks to Dave for the effort to put this together -- it's a real challenge to organize one's thoughts on something this complex. Nonetheless, I found it quite hard to understand, largely because of mixing ideas and lack of definitions of some important terms. I volunteer to give it an editing pass this weekend; and will send the result privately to Dave before posting to the list. In particular: - I quite despair of defining "fairness" -- I think it a lost cause, and will try to substitute "economic congestion" where that seems to be the intent. - "congestion" seems to be used in several different senses. I will try to substitute "queue filling" where that is appropriate. - I'm not sure there is a need to separate out Approach 2a from 2b. The distinction is very confusing to me. I'll edit it out and we can see whether it needs to go back in (but later in the presentation). - I believe that re-ordering the presentation can cut the number of words considerably at the same time it becomes easier for the average reader to grok. - As I proceed, I'll put some questions to Dave privately. If Dave and I fail to reach agreement, most of these will probably be posted to the list later. This is an editing pass only -- not an attempt to push my views on the issues involved. I'm likely to raise that sort of questions later. -- John Leslie From dave.mcdysan@verizon.com Mon Mar 7 10:02:15 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7199E3A680C for ; Mon, 7 Mar 2011 10:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.472 X-Spam-Level: X-Spam-Status: No, score=-3.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLrJ-BxgBK3L for ; Mon, 7 Mar 2011 10:02:14 -0800 (PST) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id 6BE553A67EC for ; Mon, 7 Mar 2011 10:02:14 -0800 (PST) Received: from fldsmtpi01.verizon.com (fldsmtpi01.verizon.com [166.68.71.143]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p27I3N8E000559 for ; Mon, 7 Mar 2011 13:03:27 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,278,1297036800"; d="scan'208";a="6933152" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi01.verizon.com with ESMTP; 07 Mar 2011 18:03:23 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.147]) by FHDP1LUMXC7HB02.us.one.verizon.com ([2002:a644:3bbd::a644:3bbd]) with mapi; Mon, 7 Mar 2011 13:03:23 -0500 To: "conex@ietf.org" Date: Mon, 7 Mar 2011 13:03:20 -0500 Thread-Topic: New Version Notification for draft-mcdysan-conex-volumetier-usecase-00 Thread-Index: Acvc8fLrPMmC6vZlRsqzC1Ug4UE+6g== Message-ID: In-Reply-To: <20110307175339.BB1873A67EC@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [conex] FW: New Version Notification for draft-mcdysan-conex-volumetier-usecase-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 18:02:15 -0000 Hi, This is the individual draft requested in Beijing regarding usage/volume tier congestion. http://www.ietf.org/internet-drafts/draft-mcdysan-conex-volumetier-usecase- 00.txt Since this is (currently) outside the charter, I propose putting it last on the agenda. Of course, comments on the list or private comments would be most welcome. Thanks, Dave On 3/7/11 12:53 PM, "IETF I-D Submission Tool" wrote: > >A new version of I-D, draft-mcdysan-conex-volumetier-usecase-00.txt has >been successfully submitted by Dave McDysan and posted to the IETF >repository. > >Filename: draft-mcdysan-conex-volumetier-usecase >Revision: 00 >Title: Usage/Volume Tier Feedback Use Case for Congestion Exposure >Creation_date: 2011-03-07 >WG ID: Independent Submission >Number_of_pages: 9 > >Abstract: >As requested in the Beijing meeting, this is an individual draft that >expands on the usage tier/volume use case from [McDysan]. The >feedback recorded in the Beijing conex meeting minutes was that a >number of people were potentially interested in this use case, but >that it was out of scope of the current charter, and/or could >potentially be built out of the conex abstract mechanism. > =20 > =20 > > >The IETF Secretariat. > > From mirja.kuehlewind@ikr.uni-stuttgart.de Tue Mar 8 04:23:15 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB22B3A6810 for ; Tue, 8 Mar 2011 04:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUou9pCVAA2k for ; Tue, 8 Mar 2011 04:23:13 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id 5CC9A3A6767 for ; Tue, 8 Mar 2011 04:23:12 -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 DBCE8633B9; Tue, 8 Mar 2011 13:24:25 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id CA30159A8A; Tue, 8 Mar 2011 13:24:25 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: conex@ietf.org Date: Tue, 8 Mar 2011 13:24:25 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20090731.1005176) References: In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201103081324.25218.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: Re: [conex] Proposed Text for New Section in Use Case Draft - Statistical multiplexing over Longer Timescales X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 12:23:15 -0000 Hi David, sorry, reading the text I really don't see the problems you are talking abo= ut: 1. self-congestion vs. inter-user congestion =2D First, there is no difference between having a shaper or having a limit= ed=20 access bandwidth.=20 =2D Second, the principle of TCP congestion control is to probe for availab= le=20 bandwidth until congestion occurs. That's nothing bad because thats the onl= y=20 feedback TCP has. And as long as you are alone on the link, the number of=20 losses/marking will be very small. If you even want to avoid these congesti= on=20 markings than you can go for something like LEDBAT which will keep the queu= e=20 small and no congestion will occur. If there is only self-congestion its=20 under the user's control how much congestion he/she will cause. Where's the= =20 problem? 2. heavy vs. light users Heavy user in general are not a problem, only heavy unresponsive user are. = And=20 heavy unresponsive user will have a high congestion volume (whereas light o= r=20 LEDBAT user will have a small congestion volume). Thus the congestion volum= e=20 given by the ConEx mechanism is the only metric needed to figure out who ar= e=20 the bad guys! 3. congestion vs. congestion volume Somewhere your text is saying "The result is that all users see the same=20 congestion...". That's not true. The point is that a heavy unresponsive use= r=20 is seeing more losses/marking than a light user because he/she is sending=20 with a higher rate over a longer period of time. ConEx is not only giving a= =20 notification that there has been a congestion event, ConEX is giving a=20 congestion volume. And if you have dropper the ones with a high congestion= =20 volume will consume their allowances quickly and will be penalized by the=20 dropper afterwards. Thus if you have ConEX you can have a dropper instead o= f=20 the shaper and this will actually allow you to penalize the bad guys (where= as=20 a shaper will penalize the heavy users, which is the wrong metric as e.g.=20 LEDBAT user are nice guys).=20 Mirja On Friday 04 March 2011 17:37:37 Mcdysan, David E wrote: > Hi, > > As documented in the IETF79 Beijing meeting minutes it was agreed that the > concepts from the section titled "Inequity of Heavy versus Light Users"=20 > from draft-mcdysan-conex-other-usecases should be included in the WG > Concepts and Use Cases draft. > > After much discussion (that ranged well beyond this topic, and spawned > several other threads that are not addressed by this proposed text), Toby > proposed adding a new section to the use case draft and I volunteered to > draft content based upon the original draft as well as the relevant list > discussion from the thread titled "Discussion of new Use Cases pt 1," alo= ng > with relevant text from the spawned threads. I tried to list all of the > people whose inputs I used to draft this text and am requesting the > use-case draft authors to include your names in the Acknowledgement secti= on > (if it was not already there). > > The title of the proposed new section X has been changed to represent the > principal aspects of the use case, namely statistical multiplexing over > longer timescales. > > Thanks, > > Dave > ----------------------------------------------------------------- > > X. Statistical multiplexing over Longer Timescales > > In this use case the assumption is that "flat rate" or "bandwidth tier" > pricing is in place. A simplifying assumption is made that there is no ve= ry > long term (e.g., monthly) usage tier pricing in place. > > X.1 Problems Encountered in Existing Networks > > The principal problem addressed by this use case is that 20% of the users > generate 80% of the traffic volume and create unfairness with certain > resource sharing [Varian], often without paying any extra for doing so wh= en > "flat rate" or "bandwidth tier" pricing is in effect. The timescale over > which this difference in traffic volume exists can range from seconds, to > many minutes to hours. The peak rate at which a user can send may be set = by > the physical transmission system, a non-work conserving scheduler, and/or= a > policer. > > The access network is usually not provisioned and traffic engineered for > the peak rate for all users but is instead provisioned assuming statistic= al > multiplexing where a longer term (many seconds to minutes to hours) avera= ge > capacity is assumed for all users during the busy period. The many minutes > timescale is commonly used by network operators to determine when a porti= on > of a network is near congestion [section 3.3, Bauer]. During non-busy > periods, the service provider network is underutilized and hence there is > no congestion of shared resources. > > During busy periods where congestion (i.e., loss or ECN marking) of a > shared resource (e.g., a queue or scheduler) can occur, heavier users may > send at speeds up to the peak rate while lighter users may send at a rate > much less than the peak rate. The result is that all users see the same > congestion (i.e., loss or ECN marking probability) although the lighter > users are sending at much less than the peak rate. Furthermore, when the > shared resource is congested, heavy users create much more congestion > volume than light users. In this sense, the response of current networks = is > "unfair," which is also called "economic congestion" [section 3.4, Bauer]. > > The above situation occurs in flat rate pricing where all user flows share > the same resource (e.g., queue, scheduler). > > In many networks a non work conserving scheduler (e.g., a shaper) > implements a per-user peak rate over an interval O(100 ms). See Appendix B > of [DSL Forum TR-059] for a DSL specific example of non-work conserving > schedulers. Similar techniques are used in access network equipment across > a range of access technologies. Thus, the "bandwidth tier" incentive is > that a user pays more if he/she wants more peak rate bandwidth. > > Such non-work conserving schedulers create apparent congestion (i.e., loss > or ECN marking) within their queue(s) which impact only a single user that > need to be considered in the set of conex use cases. Further discussion on > this topic is covered in the section "Self-Congestion versus Inter-User > Congestion." > > X.2 Conex Objectives for a Solution to this Problem > > The general objective for conex is to provide better information for a > provider to address the "unfairness" or "economic congestion" problem > described in the previous section. > > A specific objective is to achieve a "fairness" measure of bandwidth > delivered in proportion to the user peak rate when congestion of a shared > resource occurs. > > A specific objective is to distinguish heavier users from lighter users > over a the statistical multiplexing time interval that can range from > seconds, to minutes, to hours so that network provider traffic management > functions can provide "fairer" allocation of bandwidth. > > A desirable objective is to distinguish between "self-congestion" and > "inter-user congestion" so that users could use a mechanism external to > conex to "go faster" in the event that only "self-congestion" is limiting > their throughput. > > X.2 Self-Congestion versus Inter-User Congestion > > If the user sends at more than the shaper peak rate and there is no > congestion at a shared resource, then other users are not impacted, and in > a sense this user creates "self-congestion." There is also the case when > congestion occurs at a shared resource, which causes > "inter-user-congestion," where congestion volume from one user impacts > other users. Note that "Self-Congestion" can occur when "Inter-User > Congestion" occurs. However, a heavier user may not create > "self-congestion" (i.e., loss or ECN marking) if that user sends at > slightly less than a shaper peak rate (e.g., using LEDBAT). > > There are (at least) three approaches for addressing this issue. Approach= es > 1, 2.a require no change to the conex abstract mechanism > [wg-abstract-mechanism]. Approach 2.b would require signaling of addition= al > information to the receiver (could be done separately from conex), and > approach 3 may be able to use the conex abstract mechanism, albeit > potentially in a different configuration. > > 1. Treat "self-congestion" the same as "inter-user congestion" since they > both create congestion as perceived by the flow user. > > 2. Signal more information to the receiver about the cause of loss since > the remedy differs: > a. For a shared queue, use current draft of abstract mechanism signals > to reduce load and choose packets for different treatments. > b. For a queue dedicated to a receiver (e.g., shaper) signal information > that the shaper peak rate is the bottleneck to the receiver, so that > somehow (specific mechanism may not fit within the current conex wg > charter) the user could make a request to "go faster." > > 3. Process and generate conex information at the network element which > implements the shaper, which has knowledge of the configured peak rates f= or > the users as well as local shared resource congestion. This network eleme= nt > can also use information about upstream shared resource congestion as > delivered buy the conex protocol. > > Note that during busy periods "self congestion" may not be the limiting > factor, but during non-busy periods it will be the biggest source of > apparent congestion. > > X.3 Potential Support Using Abstract Mechanism > > [Editorial Note from Dave: The following was derived list comments as well > as a private input from Toby Moncaster.] > > The following scenario assumes that all user flows implement conex. The > case where not all flows implement conex still needs to be addressed. (So= me > form of localized "conex-like" marking may handle this case, since heavier > users may have a significant incentive to not implement conex). Also to be > addressed is the scenario where heavy users do not create congestion (e.g= =2E, > using LEDBAT), but there is still a significant difference in average rat= e, > or burstiness (peak/average). > > Using the abstract mechanism a heavier user never gets a chance to build > up any congestion credit, which will not impact their service during > non-busy periods. However, at peak times it means their service is degrad= ed > long before a light user sees any impact. In turn this means the congesti= on > seen by the light user is less, meeting an important objective. > > Additional local computations are done as follows. Over a time period > related to the statistical multiplexing interval (e.g., many seconds to > minutes to hours) total up the number of bytes that have been congestion > marked and the total number of bytes sent per user. Compute the ratio of > congested bytes to total bytes. > > The total is a measure of the average rate per user (averaged over the ti= me > period of the total). > > For example, quantizing users into classes using one threshold on total a= nd > and another threshold on ratio results in a grid that identifies four > distinct classes of user as follows: > > +----------------+-------------+-------------+ > > | Total volume>| | | > |v Ratio | Large | Small | > > +----------------+-------------+-------------+ > > | High | Heavy User | Bursty User | > > +----------------+-------------+-------------+ > > | Low | LEDBAT User | Light User | > > +----------------+-------------+-------------+ > > X.4 Additional Support Using other Measures and Mechanisms > > An additional congestion measure of burstiness (e.g., ratio of peak rate = to > average rate over a longer interval than the tiered bandwidth shaper) wou= ld > allow nodes upstream from the node implementing the shaper to implement > traffic management. This measure could be derived from signals in the > abstract mechanism but would require (a majority) of the heavier senders > and receivers to implement conex and also would only work if loss or ECN > marking occurs. Heavier users may have a significant incentive to not > implement conex, and some additional mechanism to address this issue may = be > required. Also, signaling a measure of the burstiness (or something relat= ed > to it) would address the scenario where no loss or ECN marking occurs. > > As an alternative, if a "light weight" TCP proxy were implemented at the > network element containing the shaper (e.g., an access router) and an > upstream network element (e.g., a router at ingress to the service provid= er > network), then potentially a conex control loop could be created between > these network elements to provide fairer treatment between heavier and > lighter users during congested intervals. In this case, a subset of conex > features could potentially be used since this would be a closed domain > where the signals could be implicitly trusted. The burstiness measure cou= ld > be communicated using TCP extensions between these proxies. > > There is also the aspect of "self congestion" when a non-work conserving > scheduler (e.g., shaper) is employed at the access node. Even when > "inter-user congestion" is not occurring (e.g., during a non-busy period), > "self congestion" may occur. However, as discussed in the section on "Self > Congestion versus Inter-User Congestion," using current mechanisms (i.e., > implicitly determined loss or ECN marking) the receiver cannot tell the > difference between "self-congestion" and "inter-user congestion." Adding a > signal to the abstract mechanism could be quite useful so that a receiver > can inform the sender regarding the cause of congestion, and enable the > sender (or the receiver) to communicate with the network element > controlling the shaper parameters enabling the flow to "go faster." using > some non-conex mechanism. > > > --------------------- > > [Editorial Note: Please add the following] > > Acknowledgements > > Add the following: Stuart Venters, Mikael Abrahamsson, Mirja Kuehlewind,= =20 > Jo=C3=A3o Taveira Ara=C3=BAjo, Caitlin Bestler, Steven Bauer, =E2=80=A6 > > [Editorial Note: My thanks for inputs from authors, folks already listed = in > Acknowledgements: Toby Moncaster, John Leslie, Alissa Cooper, Rich Woundy, > =E2=80=A6] > > References > > [DSL Forum TR-059] Technical Report DSL Forum TR-059, "DSL Evolution - > Architecture Requirements for the Support of QoS-Enabled IP Services," > September 2003, > http://www.broadband-forum.org/technical/download/TR-059.pdf > > [Varian] Hal Varian, Google, "Congestion pricing principles," IETF 78 > Technical Plenary, 29 July 2010 > > [Bauer] Steven Bauer, David Clark, William Lehr, "The Evolution of > Internet Congestion," Massachusetts Institute of Technology, 2009 =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=C3=BChlewind 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 Dirk.Kutscher@neclab.eu Tue Mar 8 04:26:09 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 095433A67D9 for ; Tue, 8 Mar 2011 04:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+wTAL6KJL5P for ; Tue, 8 Mar 2011 04:26:06 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 1010F3A6767 for ; Tue, 8 Mar 2011 04:26:06 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id DF0982C000208 for ; Tue, 8 Mar 2011 13:28:49 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4D+J1tQmQYO for ; Tue, 8 Mar 2011 13:28:49 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.neclab.eu (Postfix) with ESMTP id C46452C0001DE for ; Tue, 8 Mar 2011 13:28:44 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.136]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Tue, 8 Mar 2011 13:27:15 +0100 From: Dirk Kutscher To: "conex@ietf.org" Thread-Topic: Mobile Communication Congestion Exposure Scenario Thread-Index: AcvdjCeCqk9Wtvl3QaOPfugwKgKhyw== Date: Tue, 8 Mar 2011 12:27:14 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F524905AEFA73@DAPHNIS.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.105] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [conex] Mobile Communication Congestion Exposure Scenario X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 12:26:09 -0000 Hi all, We have started a draft on describing how CONEX could be useful in mobile c= ommunication networks such as LTE: https://datatracker.ietf.org/doc/draft-kutscher-conex-mobile/ The text currently describes how the CONEX uses cases (from draft-ietf-cone= x-concepts-uses) could help in a mobile communication network, how you woul= d use CONEX mechanisms most likely, and what we should consider for designi= ng the CONEX mechanism. It's a first draft that we plan to advance a bit in the future, but we hope= it's useful enough at this point as input to the current discussions. Any feedback would be appreciated. If there is interest, we would also be a= ble to present this in Prague. Best regards, Faisal, Rolf, Suresh, Ying, Dirk From swmike@swm.pp.se Tue Mar 8 06:29:24 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16C243A688F for ; Tue, 8 Mar 2011 06:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQqseG0yvoD5 for ; Tue, 8 Mar 2011 06:29:23 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 0EFE73A67B7 for ; Tue, 8 Mar 2011 06:29:22 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8A98F9C; Tue, 8 Mar 2011 15:30:35 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 87F919A; Tue, 8 Mar 2011 15:30:35 +0100 (CET) Date: Tue, 8 Mar 2011 15:30:35 +0100 (CET) From: Mikael Abrahamsson To: Dirk Kutscher In-Reply-To: <82AB329A76E2484D934BBCA77E9F524905AEFA73@DAPHNIS.office.hd> Message-ID: References: <82AB329A76E2484D934BBCA77E9F524905AEFA73@DAPHNIS.office.hd> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "conex@ietf.org" Subject: Re: [conex] Mobile Communication Congestion Exposure Scenario X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 14:29:24 -0000 On Tue, 8 Mar 2011, Dirk Kutscher wrote: > https://datatracker.ietf.org/doc/draft-kutscher-conex-mobile/ > > Any feedback would be appreciated. If there is interest, we would also be able to present this in Prague. In 3.1 it says that DPI is desireable because of increased traffic volume. DPI in itself doesn't help with traffic volume but can identify different traffic types that can then be acted on. I think the text should reflect this. DPI is identification, not action. 3.2 The scenario described in the first paragraph has already happened, at least where I am. Regarding the last paragraph, I'd say it'd work best if there was some kind of intelligent scheduling within the single bearer (which is the most common deployment for "mobile broadband"), instead of the currently used FIFO. This needs to be done at congestion points along the path, for instance egress at the base station. 4.2 There is talk about policers here. Do you really mean policing or do you mean delying traffic by use of buffering + tail drop when a certain length is exceeded? I've seen both done in EPC depending on vendor. 5. Doesn't the whole system already provide fairness by means of scheduling radio and other resources according to user profiles? The whole argument of "lots of TCP sessions using a lot of data than the single TCP session interactive content one" doesn't apply here since all users are in a single bearer anyway? Conclusion: In my mind, a mobile network is NOT ideal to deploy CONEX in, because it already has a lot of the fairness mechanisms already in it. A users total traffic is in a single bearer and users are differentiated on bearers, not what's in the bearers exactly. If this works as advertised, resources are already fairly distributed between users of the same traffic profile. -- Mikael Abrahamsson email: swmike@swm.pp.se From dave.mcdysan@verizon.com Tue Mar 8 06:52:28 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 820683A67BD for ; Tue, 8 Mar 2011 06:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.477 X-Spam-Level: X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuZrDBDT77Ta for ; Tue, 8 Mar 2011 06:52:24 -0800 (PST) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id 5C6073A67B7 for ; Tue, 8 Mar 2011 06:52:24 -0800 (PST) Received: from fldsmtpi03.verizon.com (fldsmtpi03.verizon.com [166.68.71.145]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p28ErOCk015546 for ; Tue, 8 Mar 2011 09:53:29 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,284,1297036800"; d="scan'208";a="7484887" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi03.verizon.com with ESMTP; 08 Mar 2011 14:53:23 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.240]) by FHDP1LUMXC7HB03.us.one.verizon.com ([2002:a644:3bbe::a644:3bbe]) with mapi; Tue, 8 Mar 2011 09:53:23 -0500 To: Mirja Kuehlewind , "conex@ietf.org" Date: Tue, 8 Mar 2011 09:53:17 -0500 Thread-Topic: [conex] Proposed Text for New Section in Use Case Draft - Statistical multiplexing over Longer Timescales Thread-Index: AcvdoJKRkQ0WJPPcTLCm92iib2KbAw== Message-ID: In-Reply-To: <201103081324.25218.mirja.kuehlewind@ikr.uni-stuttgart.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [conex] Proposed Text for New Section in Use Case Draft - Statistical multiplexing over Longer Timescales X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 14:52:28 -0000 Hi Mirja, Some responses in line in attempt to understand your points and identify where existing conex mechanisms solve some of the problems and highlight those which are (not yet) completely solved. Thanks, Dave On 3/8/11 7:24 AM, "Mirja Kuehlewind" wrote: >Hi David, > >sorry, reading the text I really don't see the problems you are talking >about: > >1. self-congestion vs. inter-user congestion >- First, there is no difference between having a shaper or having a >limited >access bandwidth. I think we tried to capture this point of view in item 1 in section X.2, but I am not sure if I understand your statement completely. "Treat "self-congestion" the same as "inter-user congestion" since they both create congestion as perceived by the flow user." There were other points of view expressed on the list which were captured in points 2 and 3. Please review those. What I am seeing is that people have different perspectives based upon their experience and motivations. IMHO, it is OK if not all people have the same the same opinion on the relevance of use cases. If we used the reasoning that everyone had to agree on each use case, then we could end up with very few use cases. For example, a number of people have expressed the point of view that policing is unnecessary and should not be done for various reasons. Should we remove the policing use case based upon this reasoning? >- Second, the principle of TCP congestion control is to probe for >available >bandwidth until congestion occurs. That's nothing bad because thats the >only >feedback TCP has. And as long as you are alone on the link, the number of >losses/marking will be very small. Not if the rate exceeds the bottleneck. >If you even want to avoid these congestion >markings than you can go for something like LEDBAT which will keep the >queue >small and no congestion will occur. If there is only self-congestion its >under the user's control how much congestion he/she will cause. Where's >the >problem? See X.2 case 2b. A user could request to "go faster." > >2. heavy vs. light users >Heavy user in general are not a problem, only heavy unresponsive user >are. And >heavy unresponsive user will have a high congestion volume (whereas light >or >LEDBAT user will have a small congestion volume). Thus the congestion >volume >given by the ConEx mechanism is the only metric needed to figure out who >are >the bad guys! Section X.3 (largely written by Toby) tries to capture similar reasoning of how the current mechanisms could be used. I think adding text on how best to address unresponsive users to that section would be good. X.3 also mentions the case where heavy users do not create congestion as currently defined in conex (I.e., loss, ECN marking) which is not covered in the current mechanism. > >3. congestion vs. congestion volume >Somewhere your text is saying "The result is that all users see the same >congestion...". That's not true. See definitions in section 3 - Congestion =3D probability of loss or (ECN) marking. Using this definition the above statement is true. >The point is that a heavy unresponsive user >is seeing more losses/marking than a light user because he/she is sending >with a higher rate over a longer period of time. I think what you may mean is that congestion volume (as defined in section 3 (this definition could use some clarification)) differs between heavy/light users, with which I agree. >ConEx is not only giving a >notification that there has been a congestion event, ConEX is giving a >congestion volume. And if you have dropper the ones with a high congestion >volume will consume their allowances quickly and will be penalized by the >dropper afterwards. Thus if you have ConEX you can have a dropper instead >of >the shaper and this will actually allow you to penalize the bad guys >(whereas >a shaper will penalize the heavy users, which is the wrong metric as e.g. >LEDBAT user are nice guys). I think this general approach could be used to expand X.3 and refer the "dropper" (I think this is called ingress policing, or traffic management in the current draft). We also have the issue with this approach mentioned earlier that some wg members have expressed the opinion that they don't want to implement policers. I am OK listing this as an option for operators, for the reasons mentioned above. However, there are still the unresolved problems of unresponsive users and those who do not create observable congestion (as it is currently defined). > >Mirja > > >On Friday 04 March 2011 17:37:37 Mcdysan, David E wrote: >> Hi, >> >> As documented in the IETF79 Beijing meeting minutes it was agreed that >>the >> concepts from the section titled "Inequity of Heavy versus Light Users" >> from draft-mcdysan-conex-other-usecases should be included in the WG >> Concepts and Use Cases draft. >> >> After much discussion (that ranged well beyond this topic, and spawned >> several other threads that are not addressed by this proposed text), >>Toby >> proposed adding a new section to the use case draft and I volunteered to >> draft content based upon the original draft as well as the relevant list >> discussion from the thread titled "Discussion of new Use Cases pt 1," >>along >> with relevant text from the spawned threads. I tried to list all of the >> people whose inputs I used to draft this text and am requesting the >> use-case draft authors to include your names in the Acknowledgement >>section >> (if it was not already there). >> >> The title of the proposed new section X has been changed to represent >>the >> principal aspects of the use case, namely statistical multiplexing over >> longer timescales. >> >> Thanks, >> >> Dave >> ----------------------------------------------------------------- >> >> X. Statistical multiplexing over Longer Timescales >> >> In this use case the assumption is that "flat rate" or "bandwidth tier" >> pricing is in place. A simplifying assumption is made that there is no >>very >> long term (e.g., monthly) usage tier pricing in place. >> >> X.1 Problems Encountered in Existing Networks >> >> The principal problem addressed by this use case is that 20% of the >>users >> generate 80% of the traffic volume and create unfairness with certain >> resource sharing [Varian], often without paying any extra for doing so >>when >> "flat rate" or "bandwidth tier" pricing is in effect. The timescale over >> which this difference in traffic volume exists can range from seconds, >>to >> many minutes to hours. The peak rate at which a user can send may be >>set by >> the physical transmission system, a non-work conserving scheduler, >>and/or a >> policer. >> >> The access network is usually not provisioned and traffic engineered for >> the peak rate for all users but is instead provisioned assuming >>statistical >> multiplexing where a longer term (many seconds to minutes to hours) >>average >> capacity is assumed for all users during the busy period. The many >>minutes >> timescale is commonly used by network operators to determine when a >>portion >> of a network is near congestion [section 3.3, Bauer]. During non-busy >> periods, the service provider network is underutilized and hence there >>is >> no congestion of shared resources. >> >> During busy periods where congestion (i.e., loss or ECN marking) of a >> shared resource (e.g., a queue or scheduler) can occur, heavier users >>may >> send at speeds up to the peak rate while lighter users may send at a >>rate >> much less than the peak rate. The result is that all users see the same >> congestion (i.e., loss or ECN marking probability) although the lighter >> users are sending at much less than the peak rate. Furthermore, when the >> shared resource is congested, heavy users create much more congestion >> volume than light users. In this sense, the response of current >>networks is >> "unfair," which is also called "economic congestion" [section 3.4, >>Bauer]. >> >> The above situation occurs in flat rate pricing where all user flows >>share >> the same resource (e.g., queue, scheduler). >> >> In many networks a non work conserving scheduler (e.g., a shaper) >> implements a per-user peak rate over an interval O(100 ms). See >>Appendix B >> of [DSL Forum TR-059] for a DSL specific example of non-work conserving >> schedulers. Similar techniques are used in access network equipment >>across >> a range of access technologies. Thus, the "bandwidth tier" incentive is >> that a user pays more if he/she wants more peak rate bandwidth. >> >> Such non-work conserving schedulers create apparent congestion (i.e., >>loss >> or ECN marking) within their queue(s) which impact only a single user >>that >> need to be considered in the set of conex use cases. Further discussion >>on >> this topic is covered in the section "Self-Congestion versus Inter-User >> Congestion." >> >> X.2 Conex Objectives for a Solution to this Problem >> >> The general objective for conex is to provide better information for a >> provider to address the "unfairness" or "economic congestion" problem >> described in the previous section. >> >> A specific objective is to achieve a "fairness" measure of bandwidth >> delivered in proportion to the user peak rate when congestion of a >>shared >> resource occurs. >> >> A specific objective is to distinguish heavier users from lighter users >> over a the statistical multiplexing time interval that can range from >> seconds, to minutes, to hours so that network provider traffic >>management >> functions can provide "fairer" allocation of bandwidth. >> >> A desirable objective is to distinguish between "self-congestion" and >> "inter-user congestion" so that users could use a mechanism external to >> conex to "go faster" in the event that only "self-congestion" is >>limiting >> their throughput. >> >> X.2 Self-Congestion versus Inter-User Congestion >> >> If the user sends at more than the shaper peak rate and there is no >> congestion at a shared resource, then other users are not impacted, and >>in >> a sense this user creates "self-congestion." There is also the case when >> congestion occurs at a shared resource, which causes >> "inter-user-congestion," where congestion volume from one user impacts >> other users. Note that "Self-Congestion" can occur when "Inter-User >> Congestion" occurs. However, a heavier user may not create >> "self-congestion" (i.e., loss or ECN marking) if that user sends at >> slightly less than a shaper peak rate (e.g., using LEDBAT). >> >> There are (at least) three approaches for addressing this issue. >>Approaches >> 1, 2.a require no change to the conex abstract mechanism >> [wg-abstract-mechanism]. Approach 2.b would require signaling of >>additional >> information to the receiver (could be done separately from conex), and >> approach 3 may be able to use the conex abstract mechanism, albeit >> potentially in a different configuration. >> >> 1. Treat "self-congestion" the same as "inter-user congestion" since >>they >> both create congestion as perceived by the flow user. >> >> 2. Signal more information to the receiver about the cause of loss since >> the remedy differs: >> a. For a shared queue, use current draft of abstract mechanism signals >> to reduce load and choose packets for different treatments. >> b. For a queue dedicated to a receiver (e.g., shaper) signal >>information >> that the shaper peak rate is the bottleneck to the receiver, so that >> somehow (specific mechanism may not fit within the current conex wg >> charter) the user could make a request to "go faster." >> >> 3. Process and generate conex information at the network element which >> implements the shaper, which has knowledge of the configured peak rates >>for >> the users as well as local shared resource congestion. This network >>element >> can also use information about upstream shared resource congestion as >> delivered buy the conex protocol. >> >> Note that during busy periods "self congestion" may not be the limiting >> factor, but during non-busy periods it will be the biggest source of >> apparent congestion. >> >> X.3 Potential Support Using Abstract Mechanism >> >> [Editorial Note from Dave: The following was derived list comments as >>well >> as a private input from Toby Moncaster.] >> >> The following scenario assumes that all user flows implement conex. The >> case where not all flows implement conex still needs to be addressed. >>(Some >> form of localized "conex-like" marking may handle this case, since >>heavier >> users may have a significant incentive to not implement conex). Also to >>be >> addressed is the scenario where heavy users do not create congestion >>(e.g., >> using LEDBAT), but there is still a significant difference in average >>rate, >> or burstiness (peak/average). >> >> Using the abstract mechanism a heavier user never gets a chance to >>build >> up any congestion credit, which will not impact their service during >> non-busy periods. However, at peak times it means their service is >>degraded >> long before a light user sees any impact. In turn this means the >>congestion >> seen by the light user is less, meeting an important objective. >> >> Additional local computations are done as follows. Over a time period >> related to the statistical multiplexing interval (e.g., many seconds to >> minutes to hours) total up the number of bytes that have been congestion >> marked and the total number of bytes sent per user. Compute the ratio of >> congested bytes to total bytes. >> >> The total is a measure of the average rate per user (averaged over the >>time >> period of the total). >> >> For example, quantizing users into classes using one threshold on total >>and >> and another threshold on ratio results in a grid that identifies four >> distinct classes of user as follows: >> >> +----------------+-------------+-------------+ >> >> | Total volume>| | | >> |v Ratio | Large | Small | >> >> +----------------+-------------+-------------+ >> >> | High | Heavy User | Bursty User | >> >> +----------------+-------------+-------------+ >> >> | Low | LEDBAT User | Light User | >> >> +----------------+-------------+-------------+ >> >> X.4 Additional Support Using other Measures and Mechanisms >> >> An additional congestion measure of burstiness (e.g., ratio of peak >>rate to >> average rate over a longer interval than the tiered bandwidth shaper) >>would >> allow nodes upstream from the node implementing the shaper to implement >> traffic management. This measure could be derived from signals in the >> abstract mechanism but would require (a majority) of the heavier senders >> and receivers to implement conex and also would only work if loss or ECN >> marking occurs. Heavier users may have a significant incentive to not >> implement conex, and some additional mechanism to address this issue >>may be >> required. Also, signaling a measure of the burstiness (or something >>related >> to it) would address the scenario where no loss or ECN marking occurs. >> >> As an alternative, if a "light weight" TCP proxy were implemented at the >> network element containing the shaper (e.g., an access router) and an >> upstream network element (e.g., a router at ingress to the service >>provider >> network), then potentially a conex control loop could be created between >> these network elements to provide fairer treatment between heavier and >> lighter users during congested intervals. In this case, a subset of >>conex >> features could potentially be used since this would be a closed domain >> where the signals could be implicitly trusted. The burstiness measure >>could >> be communicated using TCP extensions between these proxies. >> >> There is also the aspect of "self congestion" when a non-work conserving >> scheduler (e.g., shaper) is employed at the access node. Even when >> "inter-user congestion" is not occurring (e.g., during a non-busy >>period), >> "self congestion" may occur. However, as discussed in the section on >>"Self >> Congestion versus Inter-User Congestion," using current mechanisms >>(i.e., >> implicitly determined loss or ECN marking) the receiver cannot tell the >> difference between "self-congestion" and "inter-user congestion." >>Adding a >> signal to the abstract mechanism could be quite useful so that a >>receiver >> can inform the sender regarding the cause of congestion, and enable the >> sender (or the receiver) to communicate with the network element >> controlling the shaper parameters enabling the flow to "go faster." >>using >> some non-conex mechanism. >> >> >> --------------------- >> >> [Editorial Note: Please add the following] >> >> Acknowledgements >> >> Add the following: Stuart Venters, Mikael Abrahamsson, Mirja >>Kuehlewind, >> Jo=E3o Taveira Ara=FAjo, Caitlin Bestler, Steven Bauer, =8A >> >> [Editorial Note: My thanks for inputs from authors, folks already >>listed in >> Acknowledgements: Toby Moncaster, John Leslie, Alissa Cooper, Rich >>Woundy, >> =8A] >> >> References >> >> [DSL Forum TR-059] Technical Report DSL Forum TR-059, "DSL Evolution - >> Architecture Requirements for the Support of QoS-Enabled IP Services," >> September 2003, >> http://www.broadband-forum.org/technical/download/TR-059.pdf >> >> [Varian] Hal Varian, Google, "Congestion pricing principles," IETF 78 >> Technical Plenary, 29 July 2010 >> >> [Bauer] Steven Bauer, David Clark, William Lehr, "The Evolution of >> Internet Congestion," Massachusetts Institute of Technology, 2009 > > > >-- >------------------------------------------------------------------- >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 >------------------------------------------------------------------- From mirja.kuehlewind@ikr.uni-stuttgart.de Tue Mar 8 09:15:46 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D2CB3A68AF for ; Tue, 8 Mar 2011 09:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.054 X-Spam-Level: X-Spam-Status: No, score=-2.054 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBtVNoLx9EqP for ; Tue, 8 Mar 2011 09:15:44 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id B16333A6827 for ; Tue, 8 Mar 2011 09:15: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 9FCC1633B8; Tue, 8 Mar 2011 18:16:57 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 8944859A8A; Tue, 8 Mar 2011 18:16:57 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: "Mcdysan, David E" Date: Tue, 8 Mar 2011 18:16:55 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20090731.1005176) References: In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201103081816.55876.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: "conex@ietf.org" Subject: Re: [conex] Proposed Text for New Section in Use Case Draft - Statistical multiplexing over Longer Timescales X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 17:15:46 -0000 Hi Dave, I'm not saying that there are no further use cases and there are definitely= =20 relevant discussions on the list. There are also points of your draft which= =20 should definitely included into the use case draft. But the text you just=20 provided kind of confused me; I still try to figure out what the actual=20 problem is your use cases will solve.=20 > >1. self-congestion vs. inter-user congestion > >- First, there is no difference between having a shaper or having a > >limited > >access bandwidth. > > I think we tried to capture this point of view in item 1 in section X.2, > but I am not sure if I understand your statement completely. > > "Treat "self-congestion" the same as "inter-user congestion" since they > both create congestion as perceived by the flow user." I'm just saying that there is "self-congestion" because that's the way TCP = is=20 designed. There will be "self-congestion" with a shaper or without.=20 > There were other points of view expressed on the list which were captured > in points 2 and 3. Please review those. > > What I am seeing is that people have different perspectives based upon > their experience and motivations. IMHO, it is OK if not all people have > the same the same opinion on the relevance of use cases. If we used the > reasoning that everyone had to agree on each use case, then we could end > up with very few use cases. For example, a number of people have expressed > the point of view that policing is unnecessary and should not be done for > various reasons. Should we remove the policing use case based upon this > reasoning? Yes, it is okay to have different opinion about the relevance of a use case= =2E=20 But I'm still one step before that. I don't understand the problem which yo= ur=20 use case(s) could solve. As long as there is no problem, there is no use ca= se=20 from my point of view. And if there is no use case at all, we don't need to= =20 talk about the relevance.=20 Again, don't get me wrong, I think there are valid points in the draft you= =20 presented, but a can't really follow the text you just sent. > >- Second, the principle of TCP congestion control is to probe for > >available > >bandwidth until congestion occurs. That's nothing bad because thats the > >only > >feedback TCP has. And as long as you are alone on the link, the number of > >losses/marking will be very small. > > Not if the rate exceeds the bottleneck. If the sending rate exceeds the bottleneck rate, yes, there will be=20 losses/markings but the number of losses/marking will be small if TCP=20 congestion control is used (in the self-congestion case). Actually there wi= ll=20 be exactly one loss per loss event with TCP Reno. In the case of inter-user congestion, e.g. a second flow is slow-starting,= =20 there will be more losses/marking. =20 > >If you even want to avoid these congestion > >markings than you can go for something like LEDBAT which will keep the > >queue > >small and no congestion will occur. If there is only self-congestion its > >under the user's control how much congestion he/she will cause. Where's > >the > >problem? > > See X.2 case 2b. A user could request to "go faster." The user could also request a higher congestion allowance, but this is a=20 signaling mechanism on top of ConEx. Let's first design ConEx!=20 > >2. heavy vs. light users > >Heavy user in general are not a problem, only heavy unresponsive user > >are. And > >heavy unresponsive user will have a high congestion volume (whereas light > >or > >LEDBAT user will have a small congestion volume). Thus the congestion > >volume > >given by the ConEx mechanism is the only metric needed to figure out who > >are > >the bad guys! > > Section X.3 (largely written by Toby) tries to capture similar reasoning > of how the current mechanisms could be used. I think adding text on how > best to address unresponsive users to that section would be good. There is no need for 4 different types of users. You only have the nice guy= s,=20 who are responsive or anyway just light users or you have the bad guys, who= =20 are unresponsive and disturb other users. > X.3 also mentions the case where heavy users do not create congestion as > currently defined in conex (I.e., loss, ECN marking) which is not covered > in the current mechanism. Because the differentiation on heavy user and light user is the wrong metri= c.=20 You only need to distinguish between responsive and unresponsive or even=20 better between high and low congestion volume. > >3. congestion vs. congestion volume > >Somewhere your text is saying "The result is that all users see the same > >congestion...". That's not true. > > See definitions in section 3 - Congestion =3D probability of loss or (ECN) > marking. Using this definition the above statement is true. No because heavy unresponsive users (which means high sending rate over a l= ong=20 period of time) have a higher probability. Thus they don't see the same=20 congestion, they see more marking than a light user (and the quantity is=20 important here). Which is perfectly fine. > > >The point is that a heavy unresponsive user > >is seeing more losses/marking than a light user because he/she is sending > >with a higher rate over a longer period of time. > > I think what you may mean is that congestion volume (as defined in section > 3 (this definition could use some clarification)) differs between > heavy/light users, with which I agree. > > >ConEx is not only giving a > >notification that there has been a congestion event, ConEX is giving a > >congestion volume. And if you have dropper the ones with a high congesti= on > >volume will consume their allowances quickly and will be penalized by the > >dropper afterwards. Thus if you have ConEX you can have a dropper instead > >of > >the shaper and this will actually allow you to penalize the bad guys > >(whereas > >a shaper will penalize the heavy users, which is the wrong metric as e.g. > >LEDBAT user are nice guys). > > I think this general approach could be used to expand X.3 and refer the > "dropper" (I think this is called ingress policing, or traffic management > in the current draft). We also have the issue with this approach mentioned > earlier that some wg members have expressed the opinion that they don't > want to implement policers. I am OK listing this as an option for > operators, for the reasons mentioned above. Sorry I meant policer.=20 > > However, there are still the unresolved problems of unresponsive users and > those who do not create observable congestion (as it is currently defined= ). Which problem? ConEx will give you exactly the information needed to=20 distinguish those two classes of user. There is no additional mechanism=20 needed! I have the feeling that in the text you provided, there are several points= =20 mixed up. Maybe we can try to separate them again in smaller parts...? Mirja=20 > > >Mirja > > > >On Friday 04 March 2011 17:37:37 Mcdysan, David E wrote: > >> Hi, > >> > >> As documented in the IETF79 Beijing meeting minutes it was agreed that > >>the > >> concepts from the section titled "Inequity of Heavy versus Light Users" > >> from draft-mcdysan-conex-other-usecases should be included in the WG > >> Concepts and Use Cases draft. > >> > >> After much discussion (that ranged well beyond this topic, and spawned > >> several other threads that are not addressed by this proposed text), > >>Toby > >> proposed adding a new section to the use case draft and I volunteered = to > >> draft content based upon the original draft as well as the relevant li= st > >> discussion from the thread titled "Discussion of new Use Cases pt 1," > >>along > >> with relevant text from the spawned threads. I tried to list all of the > >> people whose inputs I used to draft this text and am requesting the > >> use-case draft authors to include your names in the Acknowledgement > >>section > >> (if it was not already there). > >> > >> The title of the proposed new section X has been changed to represent > >>the > >> principal aspects of the use case, namely statistical multiplexing over > >> longer timescales. > >> > >> Thanks, > >> > >> Dave > >> ----------------------------------------------------------------- > >> > >> X. Statistical multiplexing over Longer Timescales > >> > >> In this use case the assumption is that "flat rate" or "bandwidth tier" > >> pricing is in place. A simplifying assumption is made that there is no > >>very > >> long term (e.g., monthly) usage tier pricing in place. > >> > >> X.1 Problems Encountered in Existing Networks > >> > >> The principal problem addressed by this use case is that 20% of the > >>users > >> generate 80% of the traffic volume and create unfairness with certain > >> resource sharing [Varian], often without paying any extra for doing so > >>when > >> "flat rate" or "bandwidth tier" pricing is in effect. The timescale ov= er > >> which this difference in traffic volume exists can range from seconds, > >>to > >> many minutes to hours. The peak rate at which a user can send may be > >>set by > >> the physical transmission system, a non-work conserving scheduler, > >>and/or a > >> policer. > >> > >> The access network is usually not provisioned and traffic engineered f= or > >> the peak rate for all users but is instead provisioned assuming > >>statistical > >> multiplexing where a longer term (many seconds to minutes to hours) > >>average > >> capacity is assumed for all users during the busy period. The many > >>minutes > >> timescale is commonly used by network operators to determine when a > >>portion > >> of a network is near congestion [section 3.3, Bauer]. During non-busy > >> periods, the service provider network is underutilized and hence there > >>is > >> no congestion of shared resources. > >> > >> During busy periods where congestion (i.e., loss or ECN marking) of a > >> shared resource (e.g., a queue or scheduler) can occur, heavier users > >>may > >> send at speeds up to the peak rate while lighter users may send at a > >>rate > >> much less than the peak rate. The result is that all users see the same > >> congestion (i.e., loss or ECN marking probability) although the lighter > >> users are sending at much less than the peak rate. Furthermore, when t= he > >> shared resource is congested, heavy users create much more congestion > >> volume than light users. In this sense, the response of current > >>networks is > >> "unfair," which is also called "economic congestion" [section 3.4, > >>Bauer]. > >> > >> The above situation occurs in flat rate pricing where all user flows > >>share > >> the same resource (e.g., queue, scheduler). > >> > >> In many networks a non work conserving scheduler (e.g., a shaper) > >> implements a per-user peak rate over an interval O(100 ms). See > >>Appendix B > >> of [DSL Forum TR-059] for a DSL specific example of non-work conserving > >> schedulers. Similar techniques are used in access network equipment > >>across > >> a range of access technologies. Thus, the "bandwidth tier" incentive is > >> that a user pays more if he/she wants more peak rate bandwidth. > >> > >> Such non-work conserving schedulers create apparent congestion (i.e., > >>loss > >> or ECN marking) within their queue(s) which impact only a single user > >>that > >> need to be considered in the set of conex use cases. Further discussion > >>on > >> this topic is covered in the section "Self-Congestion versus Inter-User > >> Congestion." > >> > >> X.2 Conex Objectives for a Solution to this Problem > >> > >> The general objective for conex is to provide better information for a > >> provider to address the "unfairness" or "economic congestion" problem > >> described in the previous section. > >> > >> A specific objective is to achieve a "fairness" measure of bandwidth > >> delivered in proportion to the user peak rate when congestion of a > >>shared > >> resource occurs. > >> > >> A specific objective is to distinguish heavier users from lighter users > >> over a the statistical multiplexing time interval that can range from > >> seconds, to minutes, to hours so that network provider traffic > >>management > >> functions can provide "fairer" allocation of bandwidth. > >> > >> A desirable objective is to distinguish between "self-congestion" and > >> "inter-user congestion" so that users could use a mechanism external to > >> conex to "go faster" in the event that only "self-congestion" is > >>limiting > >> their throughput. > >> > >> X.2 Self-Congestion versus Inter-User Congestion > >> > >> If the user sends at more than the shaper peak rate and there is no > >> congestion at a shared resource, then other users are not impacted, and > >>in > >> a sense this user creates "self-congestion." There is also the case wh= en > >> congestion occurs at a shared resource, which causes > >> "inter-user-congestion," where congestion volume from one user impacts > >> other users. Note that "Self-Congestion" can occur when "Inter-User > >> Congestion" occurs. However, a heavier user may not create > >> "self-congestion" (i.e., loss or ECN marking) if that user sends at > >> slightly less than a shaper peak rate (e.g., using LEDBAT). > >> > >> There are (at least) three approaches for addressing this issue. > >>Approaches > >> 1, 2.a require no change to the conex abstract mechanism > >> [wg-abstract-mechanism]. Approach 2.b would require signaling of > >>additional > >> information to the receiver (could be done separately from conex), and > >> approach 3 may be able to use the conex abstract mechanism, albeit > >> potentially in a different configuration. > >> > >> 1. Treat "self-congestion" the same as "inter-user congestion" since > >>they > >> both create congestion as perceived by the flow user. > >> > >> 2. Signal more information to the receiver about the cause of loss sin= ce > >> the remedy differs: > >> a. For a shared queue, use current draft of abstract mechanism signa= ls > >> to reduce load and choose packets for different treatments. > >> b. For a queue dedicated to a receiver (e.g., shaper) signal > >>information > >> that the shaper peak rate is the bottleneck to the receiver, so that > >> somehow (specific mechanism may not fit within the current conex wg > >> charter) the user could make a request to "go faster." > >> > >> 3. Process and generate conex information at the network element which > >> implements the shaper, which has knowledge of the configured peak rates > >>for > >> the users as well as local shared resource congestion. This network > >>element > >> can also use information about upstream shared resource congestion as > >> delivered buy the conex protocol. > >> > >> Note that during busy periods "self congestion" may not be the limiting > >> factor, but during non-busy periods it will be the biggest source of > >> apparent congestion. > >> > >> X.3 Potential Support Using Abstract Mechanism > >> > >> [Editorial Note from Dave: The following was derived list comments as > >>well > >> as a private input from Toby Moncaster.] > >> > >> The following scenario assumes that all user flows implement conex. The > >> case where not all flows implement conex still needs to be addressed. > >>(Some > >> form of localized "conex-like" marking may handle this case, since > >>heavier > >> users may have a significant incentive to not implement conex). Also to > >>be > >> addressed is the scenario where heavy users do not create congestion > >>(e.g., > >> using LEDBAT), but there is still a significant difference in average > >>rate, > >> or burstiness (peak/average). > >> > >> Using the abstract mechanism a heavier user never gets a chance to > >>build > >> up any congestion credit, which will not impact their service during > >> non-busy periods. However, at peak times it means their service is > >>degraded > >> long before a light user sees any impact. In turn this means the > >>congestion > >> seen by the light user is less, meeting an important objective. > >> > >> Additional local computations are done as follows. Over a time period > >> related to the statistical multiplexing interval (e.g., many seconds to > >> minutes to hours) total up the number of bytes that have been congesti= on > >> marked and the total number of bytes sent per user. Compute the ratio = of > >> congested bytes to total bytes. > >> > >> The total is a measure of the average rate per user (averaged over the > >>time > >> period of the total). > >> > >> For example, quantizing users into classes using one threshold on total > >>and > >> and another threshold on ratio results in a grid that identifies four > >> distinct classes of user as follows: > >> > >> +----------------+-------------+-------------+ > >> > >> | Total volume>| | | > >> |v Ratio | Large | Small | > >> > >> +----------------+-------------+-------------+ > >> > >> | High | Heavy User | Bursty User | > >> > >> +----------------+-------------+-------------+ > >> > >> | Low | LEDBAT User | Light User | > >> > >> +----------------+-------------+-------------+ > >> > >> X.4 Additional Support Using other Measures and Mechanisms > >> > >> An additional congestion measure of burstiness (e.g., ratio of peak > >>rate to > >> average rate over a longer interval than the tiered bandwidth shaper) > >>would > >> allow nodes upstream from the node implementing the shaper to implement > >> traffic management. This measure could be derived from signals in the > >> abstract mechanism but would require (a majority) of the heavier sende= rs > >> and receivers to implement conex and also would only work if loss or E= CN > >> marking occurs. Heavier users may have a significant incentive to not > >> implement conex, and some additional mechanism to address this issue > >>may be > >> required. Also, signaling a measure of the burstiness (or something > >>related > >> to it) would address the scenario where no loss or ECN marking occurs. > >> > >> As an alternative, if a "light weight" TCP proxy were implemented at t= he > >> network element containing the shaper (e.g., an access router) and an > >> upstream network element (e.g., a router at ingress to the service > >>provider > >> network), then potentially a conex control loop could be created betwe= en > >> these network elements to provide fairer treatment between heavier and > >> lighter users during congested intervals. In this case, a subset of > >>conex > >> features could potentially be used since this would be a closed domain > >> where the signals could be implicitly trusted. The burstiness measure > >>could > >> be communicated using TCP extensions between these proxies. > >> > >> There is also the aspect of "self congestion" when a non-work conservi= ng > >> scheduler (e.g., shaper) is employed at the access node. Even when > >> "inter-user congestion" is not occurring (e.g., during a non-busy > >>period), > >> "self congestion" may occur. However, as discussed in the section on > >>"Self > >> Congestion versus Inter-User Congestion," using current mechanisms > >>(i.e., > >> implicitly determined loss or ECN marking) the receiver cannot tell the > >> difference between "self-congestion" and "inter-user congestion." > >>Adding a > >> signal to the abstract mechanism could be quite useful so that a > >>receiver > >> can inform the sender regarding the cause of congestion, and enable the > >> sender (or the receiver) to communicate with the network element > >> controlling the shaper parameters enabling the flow to "go faster." > >>using > >> some non-conex mechanism. > >> > >> > >> --------------------- > >> > >> [Editorial Note: Please add the following] > >> > >> Acknowledgements > >> > >> Add the following: Stuart Venters, Mikael Abrahamsson, Mirja > >>Kuehlewind, > >> Jo=E3o Taveira Ara=FAjo, Caitlin Bestler, Steven Bauer, =8A > >> > >> [Editorial Note: My thanks for inputs from authors, folks already > >>listed in > >> Acknowledgements: Toby Moncaster, John Leslie, Alissa Cooper, Rich > >>Woundy, > >> =8A] > >> > >> References > >> > >> [DSL Forum TR-059] Technical Report DSL Forum TR-059, "DSL Evolution - > >> Architecture Requirements for the Support of QoS-Enabled IP Services," > >> September 2003, > >> http://www.broadband-forum.org/technical/download/TR-059.pdf > >> > >> [Varian] Hal Varian, Google, "Congestion pricing principles," IETF 78 > >> Technical Plenary, 29 July 2010 > >> > >> [Bauer] Steven Bauer, David Clark, William Lehr, "The Evolution of > >> Internet Congestion," Massachusetts Institute of Technology, 2009 > > > >-- > >------------------------------------------------------------------- > >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 dave.mcdysan@verizon.com Tue Mar 8 09:36:09 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E827B3A6936 for ; Tue, 8 Mar 2011 09:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.482 X-Spam-Level: X-Spam-Status: No, score=-3.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvk79-r9Tzmh for ; Tue, 8 Mar 2011 09:36:07 -0800 (PST) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id 353453A6933 for ; Tue, 8 Mar 2011 09:36:06 -0800 (PST) Received: from fldsmtpi01.verizon.com (fldsmtpi01.verizon.com [166.68.71.143]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p28Hb67p005170 for ; Tue, 8 Mar 2011 12:37:11 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,285,1297036800"; d="scan'208";a="7627091" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi01.verizon.com with ESMTP; 08 Mar 2011 17:37:06 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.240]) by FHDP1LUMXC7HB02.us.one.verizon.com ([2002:a644:3bbd::a644:3bbd]) with mapi; Tue, 8 Mar 2011 12:37:06 -0500 To: Mirja Kuehlewind Date: Tue, 8 Mar 2011 12:36:46 -0500 Thread-Topic: [conex] Proposed Text for New Section in Use Case Draft - Statistical multiplexing over Longer Timescales Thread-Index: Acvdt3EGBEfDV7aPSA+mFJYGGY2i7Q== Message-ID: In-Reply-To: <201103081816.55876.mirja.kuehlewind@ikr.uni-stuttgart.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] Proposed Text for New Section in Use Case Draft - Statistical multiplexing over Longer Timescales X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 17:36:10 -0000 SGkgTWlyamEsDQoNCkpvaG4gTGVzbGllIGhhZCBzb21lIHRyb3VibGUgdW5kZXJzdGFuZGluZyB0 aGUgcHJvYmxlbSBzdGF0ZW1lbnQgYW5kIEkgYW0NCndvcmtpbmcgb24gYSBzdWJzdGFudGlhbCBy ZXdyaXRlIHdpdGggaGltLiBIZSBoYWQgZGlmZmljdWx0eSB1bmRlcnN0YW5kaW5nDQpzb21lIG9m IHRoaXMgdGV4dC4gQWxzbywgaGUgaGFkIHNvbWUgcGVyc3BlY3RpdmVzIHRoYXQgZGlmZmVyZWQg ZnJvbSBtaW5lLA0Kd2hpY2ggaW4gdGhlIHNwaXJpdCBvZiBpbmNsdWRpbmcgYWxsIHBvaW50cyBv ZiB2aWV3IEkgYW0gT0sgd2l0aCBoaW0NCmFkZGluZyB0aGVzZS4NCg0KV291bGQgcHJvYmFibHkg YmUgYmVzdCB0byB3YWl0IG9uIGhpcyByZXdyaXRlIGFuZCBjb250aW51ZSB0aGUgZGlzY3Vzc2lv bg0KYmFzZWQgdXBvbiB0aGF0IHRleHQgd2hpY2ggd2lsbCBob3BlZnVsbHkgaGF2ZSBiZXR0ZXIg ZGVzY3JpcHRpb25zIG9mDQpjb25jZXB0cyBzdWNoIGFzICJzZWxmIGNvbmdlc3Rpb24uIiBGcm9t IHlvdXIgcmVzcG9uc2VzIGl0IGFwcGVhcnMgdGhhdA0KeW91IGhhdmUgYSBkaWZmZXJlbnQgaW50 ZXJwcmV0YXRpb24gdGhhbiB3aGF0IHdhcyBkaXNjdXNzZWQgIG9uIHRoZSBsaXN0LA0Kd2hpY2gg dGhlIHRleHQgSSB3cm90ZSBkaWQgbm90IG1ha2UgY2xlYXIuDQoNCkl0IGFsc28gYXBwZWFycyB0 aGF0IHlvdSBhcmUgY29uc2lkZXJpbmcgdGhlIHNwZWNpZmljIGNhc2Ugd2hlcmUgYWxsIGZsb3dz DQplbXBsb3kgY29uZXgsIHdoZXJlIHRoZSBjdXJyZW50IHVzZSBjYXNlIGRyYWZ0IGluY2x1ZGVz IHRoZSBjYXNlIHdoZXJlIG5vdA0KYWxsIGZsb3dzIHVzZSBjb25leCwgd2hpY2ggbmVlZHMgdG8g YmUgYWRkcmVzc2VkIGluIHNvbWUgd2F5IGFzIHdlbGwuDQoNCkEgZmV3IHJlc3BvbnNlcyBpbiBs aW5lIGJlbG93Lg0KDQpUaGFua3MsDQoNCkRhdmUNCg0KT24gMy84LzExIDEyOjE2IFBNLCAiTWly amEgS3VlaGxld2luZCINCjxtaXJqYS5rdWVobGV3aW5kQGlrci51bmktc3R1dHRnYXJ0LmRlPiB3 cm90ZToNCg0KPkhpIERhdmUsDQo+DQo+SSdtIG5vdCBzYXlpbmcgdGhhdCB0aGVyZSBhcmUgbm8g ZnVydGhlciB1c2UgY2FzZXMgYW5kIHRoZXJlIGFyZQ0KPmRlZmluaXRlbHkNCj5yZWxldmFudCBk aXNjdXNzaW9ucyBvbiB0aGUgbGlzdC4gVGhlcmUgYXJlIGFsc28gcG9pbnRzIG9mIHlvdXIgZHJh ZnQNCj53aGljaA0KPnNob3VsZCBkZWZpbml0ZWx5IGluY2x1ZGVkIGludG8gdGhlIHVzZSBjYXNl IGRyYWZ0LiBCdXQgdGhlIHRleHQgeW91IGp1c3QNCj5wcm92aWRlZCBraW5kIG9mIGNvbmZ1c2Vk IG1lOyBJIHN0aWxsIHRyeSB0byBmaWd1cmUgb3V0IHdoYXQgdGhlIGFjdHVhbA0KPnByb2JsZW0g aXMgeW91ciB1c2UgY2FzZXMgd2lsbCBzb2x2ZS4NCj4NCj4+ID4xLiBzZWxmLWNvbmdlc3Rpb24g dnMuIGludGVyLXVzZXIgY29uZ2VzdGlvbg0KPj4gPi0gRmlyc3QsIHRoZXJlIGlzIG5vIGRpZmZl cmVuY2UgYmV0d2VlbiBoYXZpbmcgYSBzaGFwZXIgb3IgaGF2aW5nIGENCj4+ID5saW1pdGVkDQo+ PiA+YWNjZXNzIGJhbmR3aWR0aC4NCj4+DQo+PiBJIHRoaW5rIHdlIHRyaWVkIHRvIGNhcHR1cmUg dGhpcyBwb2ludCBvZiB2aWV3IGluIGl0ZW0gMSBpbiBzZWN0aW9uIFguMiwNCj4+IGJ1dCBJIGFt IG5vdCBzdXJlIGlmIEkgdW5kZXJzdGFuZCB5b3VyIHN0YXRlbWVudCBjb21wbGV0ZWx5Lg0KPj4N Cj4+ICJUcmVhdCAic2VsZi1jb25nZXN0aW9uIiB0aGUgc2FtZSBhcyAiaW50ZXItdXNlciBjb25n ZXN0aW9uIiBzaW5jZSB0aGV5DQo+PiBib3RoIGNyZWF0ZSBjb25nZXN0aW9uIGFzIHBlcmNlaXZl ZCBieSB0aGUgZmxvdyB1c2VyLiINCj5JJ20ganVzdCBzYXlpbmcgdGhhdCB0aGVyZSBpcyAic2Vs Zi1jb25nZXN0aW9uIiBiZWNhdXNlIHRoYXQncyB0aGUgd2F5DQo+VENQIGlzDQo+ZGVzaWduZWQu IFRoZXJlIHdpbGwgYmUgInNlbGYtY29uZ2VzdGlvbiIgd2l0aCBhIHNoYXBlciBvciB3aXRob3V0 Lg0KDQpUaGlzIHNlZW1zIGxpa2UgYSBkZWZpbml0aW9uYWwgaXNzdWUgdGhhdCBtYXkgYmUgdGhl IHJvb3Qgb2YgY29uZnVzaW9uLg0KTGV0J3MgbG9vayBhdCBKb2huJ3MgcmV3cml0ZSB0byB1bmRl cnN0YW5kIHRlcm1pbm9sb2d5IGZpcnN0Lg0KPg0KPg0KPj4gVGhlcmUgd2VyZSBvdGhlciBwb2lu dHMgb2YgdmlldyBleHByZXNzZWQgb24gdGhlIGxpc3Qgd2hpY2ggd2VyZQ0KPj5jYXB0dXJlZA0K Pj4gaW4gcG9pbnRzIDIgYW5kIDMuIFBsZWFzZSByZXZpZXcgdGhvc2UuDQo+Pg0KPj4gV2hhdCBJ IGFtIHNlZWluZyBpcyB0aGF0IHBlb3BsZSBoYXZlIGRpZmZlcmVudCBwZXJzcGVjdGl2ZXMgYmFz ZWQgdXBvbg0KPj4gdGhlaXIgZXhwZXJpZW5jZSBhbmQgbW90aXZhdGlvbnMuIElNSE8sIGl0IGlz IE9LIGlmIG5vdCBhbGwgcGVvcGxlIGhhdmUNCj4+IHRoZSBzYW1lIHRoZSBzYW1lIG9waW5pb24g b24gdGhlIHJlbGV2YW5jZSBvZiB1c2UgY2FzZXMuIElmIHdlIHVzZWQgdGhlDQo+PiByZWFzb25p bmcgdGhhdCBldmVyeW9uZSBoYWQgdG8gYWdyZWUgb24gZWFjaCB1c2UgY2FzZSwgdGhlbiB3ZSBj b3VsZCBlbmQNCj4+IHVwIHdpdGggdmVyeSBmZXcgdXNlIGNhc2VzLiBGb3IgZXhhbXBsZSwgYSBu dW1iZXIgb2YgcGVvcGxlIGhhdmUNCj4+ZXhwcmVzc2VkDQo+PiB0aGUgcG9pbnQgb2YgdmlldyB0 aGF0IHBvbGljaW5nIGlzIHVubmVjZXNzYXJ5IGFuZCBzaG91bGQgbm90IGJlIGRvbmUNCj4+Zm9y DQo+PiB2YXJpb3VzIHJlYXNvbnMuIFNob3VsZCB3ZSByZW1vdmUgdGhlIHBvbGljaW5nIHVzZSBj YXNlIGJhc2VkIHVwb24gdGhpcw0KPj4gcmVhc29uaW5nPw0KPlllcywgaXQgaXMgb2theSB0byBo YXZlIGRpZmZlcmVudCBvcGluaW9uIGFib3V0IHRoZSByZWxldmFuY2Ugb2YgYSB1c2UNCj5jYXNl Lg0KPkJ1dCBJJ20gc3RpbGwgb25lIHN0ZXAgYmVmb3JlIHRoYXQuIEkgZG9uJ3QgdW5kZXJzdGFu ZCB0aGUgcHJvYmxlbSB3aGljaA0KPnlvdXINCj51c2UgY2FzZShzKSBjb3VsZCBzb2x2ZS4gQXMg bG9uZyBhcyB0aGVyZSBpcyBubyBwcm9ibGVtLCB0aGVyZSBpcyBubyB1c2UNCj5jYXNlDQo+ZnJv bSBteSBwb2ludCBvZiB2aWV3LiBBbmQgaWYgdGhlcmUgaXMgbm8gdXNlIGNhc2UgYXQgYWxsLCB3 ZSBkb24ndCBuZWVkDQo+dG8NCj50YWxrIGFib3V0IHRoZSByZWxldmFuY2UuDQo+QWdhaW4sIGRv bid0IGdldCBtZSB3cm9uZywgSSB0aGluayB0aGVyZSBhcmUgdmFsaWQgcG9pbnRzIGluIHRoZSBk cmFmdCB5b3UNCj5wcmVzZW50ZWQsIGJ1dCBhIGNhbid0IHJlYWxseSBmb2xsb3cgdGhlIHRleHQg eW91IGp1c3Qgc2VudC4NCj4NCj4NCj4+ID4tIFNlY29uZCwgdGhlIHByaW5jaXBsZSBvZiBUQ1Ag Y29uZ2VzdGlvbiBjb250cm9sIGlzIHRvIHByb2JlIGZvcg0KPj4gPmF2YWlsYWJsZQ0KPj4gPmJh bmR3aWR0aCB1bnRpbCBjb25nZXN0aW9uIG9jY3Vycy4gVGhhdCdzIG5vdGhpbmcgYmFkIGJlY2F1 c2UgdGhhdHMgdGhlDQo+PiA+b25seQ0KPj4gPmZlZWRiYWNrIFRDUCBoYXMuIEFuZCBhcyBsb25n IGFzIHlvdSBhcmUgYWxvbmUgb24gdGhlIGxpbmssIHRoZSBudW1iZXINCj4+b2YNCj4+ID5sb3Nz ZXMvbWFya2luZyB3aWxsIGJlIHZlcnkgc21hbGwuDQo+Pg0KPj4gTm90IGlmIHRoZSByYXRlIGV4 Y2VlZHMgdGhlIGJvdHRsZW5lY2suDQo+SWYgdGhlIHNlbmRpbmcgcmF0ZSBleGNlZWRzIHRoZSBi b3R0bGVuZWNrIHJhdGUsIHllcywgdGhlcmUgd2lsbCBiZQ0KPmxvc3Nlcy9tYXJraW5ncyBidXQg dGhlIG51bWJlciBvZiBsb3NzZXMvbWFya2luZyB3aWxsIGJlIHNtYWxsIGlmIFRDUA0KPmNvbmdl c3Rpb24gY29udHJvbCBpcyB1c2VkIChpbiB0aGUgc2VsZi1jb25nZXN0aW9uIGNhc2UpLiBBY3R1 YWxseSB0aGVyZQ0KPndpbGwNCj5iZSBleGFjdGx5IG9uZSBsb3NzIHBlciBsb3NzIGV2ZW50IHdp dGggVENQIFJlbm8uDQo+SW4gdGhlIGNhc2Ugb2YgaW50ZXItdXNlciBjb25nZXN0aW9uLCBlLmcu IGEgc2Vjb25kIGZsb3cgaXMgc2xvdy1zdGFydGluZywNCj50aGVyZSB3aWxsIGJlIG1vcmUgbG9z c2VzL21hcmtpbmcuDQo+DQo+DQo+PiA+SWYgeW91IGV2ZW4gd2FudCB0byBhdm9pZCB0aGVzZSBj b25nZXN0aW9uDQo+PiA+bWFya2luZ3MgdGhhbiB5b3UgY2FuIGdvIGZvciBzb21ldGhpbmcgbGlr ZSBMRURCQVQgd2hpY2ggd2lsbCBrZWVwIHRoZQ0KPj4gPnF1ZXVlDQo+PiA+c21hbGwgYW5kIG5v IGNvbmdlc3Rpb24gd2lsbCBvY2N1ci4gSWYgdGhlcmUgaXMgb25seSBzZWxmLWNvbmdlc3Rpb24N Cj4+aXRzDQo+PiA+dW5kZXIgdGhlIHVzZXIncyBjb250cm9sIGhvdyBtdWNoIGNvbmdlc3Rpb24g aGUvc2hlIHdpbGwgY2F1c2UuIFdoZXJlJ3MNCj4+ID50aGUNCj4+ID5wcm9ibGVtPw0KPj4NCj4+ IFNlZSBYLjIgY2FzZSAyYi4gQSB1c2VyIGNvdWxkIHJlcXVlc3QgdG8gImdvIGZhc3Rlci4iDQo+ VGhlIHVzZXIgY291bGQgYWxzbyByZXF1ZXN0IGEgaGlnaGVyIGNvbmdlc3Rpb24gYWxsb3dhbmNl LCBidXQgdGhpcyBpcyBhDQo+c2lnbmFsaW5nIG1lY2hhbmlzbSBvbiB0b3Agb2YgQ29uRXguIExl dCdzIGZpcnN0IGRlc2lnbiBDb25FeCENCj4NCj4NCj4+ID4yLiBoZWF2eSB2cy4gbGlnaHQgdXNl cnMNCj4+ID5IZWF2eSB1c2VyIGluIGdlbmVyYWwgYXJlIG5vdCBhIHByb2JsZW0sIG9ubHkgaGVh dnkgdW5yZXNwb25zaXZlIHVzZXINCj4+ID5hcmUuIEFuZA0KPj4gPmhlYXZ5IHVucmVzcG9uc2l2 ZSB1c2VyIHdpbGwgaGF2ZSBhIGhpZ2ggY29uZ2VzdGlvbiB2b2x1bWUgKHdoZXJlYXMNCj4+bGln aHQNCj4+ID5vcg0KPj4gPkxFREJBVCB1c2VyIHdpbGwgaGF2ZSBhIHNtYWxsIGNvbmdlc3Rpb24g dm9sdW1lKS4gVGh1cyB0aGUgY29uZ2VzdGlvbg0KPj4gPnZvbHVtZQ0KPj4gPmdpdmVuIGJ5IHRo ZSBDb25FeCBtZWNoYW5pc20gaXMgdGhlIG9ubHkgbWV0cmljIG5lZWRlZCB0byBmaWd1cmUgb3V0 DQo+Pndobw0KPj4gPmFyZQ0KPj4gPnRoZSBiYWQgZ3V5cyENCj4+DQo+PiBTZWN0aW9uIFguMyAo bGFyZ2VseSB3cml0dGVuIGJ5IFRvYnkpIHRyaWVzIHRvIGNhcHR1cmUgc2ltaWxhciByZWFzb25p bmcNCj4+IG9mIGhvdyB0aGUgY3VycmVudCBtZWNoYW5pc21zIGNvdWxkIGJlIHVzZWQuIEkgdGhp bmsgYWRkaW5nIHRleHQgb24gaG93DQo+PiBiZXN0IHRvIGFkZHJlc3MgdW5yZXNwb25zaXZlIHVz ZXJzIHRvIHRoYXQgc2VjdGlvbiB3b3VsZCBiZSBnb29kLg0KPlRoZXJlIGlzIG5vIG5lZWQgZm9y IDQgZGlmZmVyZW50IHR5cGVzIG9mIHVzZXJzLiBZb3Ugb25seSBoYXZlIHRoZSBuaWNlDQo+Z3V5 cywNCj53aG8gYXJlIHJlc3BvbnNpdmUgb3IgYW55d2F5IGp1c3QgbGlnaHQgdXNlcnMgb3IgeW91 IGhhdmUgdGhlIGJhZCBndXlzLA0KPndobw0KPmFyZSB1bnJlc3BvbnNpdmUgYW5kIGRpc3R1cmIg b3RoZXIgdXNlcnMuDQo+DQo+PiBYLjMgYWxzbyBtZW50aW9ucyB0aGUgY2FzZSB3aGVyZSBoZWF2 eSB1c2VycyBkbyBub3QgY3JlYXRlIGNvbmdlc3Rpb24gYXMNCj4+IGN1cnJlbnRseSBkZWZpbmVk IGluIGNvbmV4IChJLmUuLCBsb3NzLCBFQ04gbWFya2luZykgd2hpY2ggaXMgbm90DQo+PmNvdmVy ZWQNCj4+IGluIHRoZSBjdXJyZW50IG1lY2hhbmlzbS4NCj5CZWNhdXNlIHRoZSBkaWZmZXJlbnRp YXRpb24gb24gaGVhdnkgdXNlciBhbmQgbGlnaHQgdXNlciBpcyB0aGUgd3JvbmcNCj5tZXRyaWMu DQo+WW91IG9ubHkgbmVlZCB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIHJlc3BvbnNpdmUgYW5kIHVu cmVzcG9uc2l2ZSBvciBldmVuDQo+YmV0dGVyIGJldHdlZW4gaGlnaCBhbmQgbG93IGNvbmdlc3Rp b24gdm9sdW1lLg0KPg0KPg0KPj4gPjMuIGNvbmdlc3Rpb24gdnMuIGNvbmdlc3Rpb24gdm9sdW1l DQo+PiA+U29tZXdoZXJlIHlvdXIgdGV4dCBpcyBzYXlpbmcgIlRoZSByZXN1bHQgaXMgdGhhdCBh bGwgdXNlcnMgc2VlIHRoZQ0KPj5zYW1lDQo+PiA+Y29uZ2VzdGlvbi4uLiIuIFRoYXQncyBub3Qg dHJ1ZS4NCj4+DQo+PiBTZWUgZGVmaW5pdGlvbnMgaW4gc2VjdGlvbiAzIC0gQ29uZ2VzdGlvbiA9 IHByb2JhYmlsaXR5IG9mIGxvc3Mgb3IgKEVDTikNCj4+IG1hcmtpbmcuIFVzaW5nIHRoaXMgZGVm aW5pdGlvbiB0aGUgYWJvdmUgc3RhdGVtZW50IGlzIHRydWUuDQo+Tm8gYmVjYXVzZSBoZWF2eSB1 bnJlc3BvbnNpdmUgdXNlcnMgKHdoaWNoIG1lYW5zIGhpZ2ggc2VuZGluZyByYXRlIG92ZXIgYQ0K PmxvbmcNCj5wZXJpb2Qgb2YgdGltZSkgaGF2ZSBhIGhpZ2hlciBwcm9iYWJpbGl0eS4gVGh1cyB0 aGV5IGRvbid0IHNlZSB0aGUgc2FtZQ0KPmNvbmdlc3Rpb24sIHRoZXkgc2VlIG1vcmUgbWFya2lu ZyB0aGFuIGEgbGlnaHQgdXNlciAoYW5kIHRoZSBxdWFudGl0eSBpcw0KPmltcG9ydGFudCBoZXJl KS4gV2hpY2ggaXMgcGVyZmVjdGx5IGZpbmUuDQo+DQo+Pg0KPj4gPlRoZSBwb2ludCBpcyB0aGF0 IGEgaGVhdnkgdW5yZXNwb25zaXZlIHVzZXINCj4+ID5pcyBzZWVpbmcgbW9yZSBsb3NzZXMvbWFy a2luZyB0aGFuIGEgbGlnaHQgdXNlciBiZWNhdXNlIGhlL3NoZSBpcw0KPj5zZW5kaW5nDQo+PiA+ d2l0aCBhIGhpZ2hlciByYXRlIG92ZXIgYSBsb25nZXIgcGVyaW9kIG9mIHRpbWUuDQo+Pg0KPj4g SSB0aGluayB3aGF0IHlvdSBtYXkgbWVhbiBpcyB0aGF0IGNvbmdlc3Rpb24gdm9sdW1lIChhcyBk ZWZpbmVkIGluDQo+PnNlY3Rpb24NCj4+IDMgKHRoaXMgZGVmaW5pdGlvbiBjb3VsZCB1c2Ugc29t ZSBjbGFyaWZpY2F0aW9uKSkgZGlmZmVycyBiZXR3ZWVuDQo+PiBoZWF2eS9saWdodCB1c2Vycywg d2l0aCB3aGljaCBJIGFncmVlLg0KPj4NCj4+ID5Db25FeCBpcyBub3Qgb25seSBnaXZpbmcgYQ0K Pj4gPm5vdGlmaWNhdGlvbiB0aGF0IHRoZXJlIGhhcyBiZWVuIGEgY29uZ2VzdGlvbiBldmVudCwg Q29uRVggaXMgZ2l2aW5nIGENCj4+ID5jb25nZXN0aW9uIHZvbHVtZS4gQW5kIGlmIHlvdSBoYXZl IGRyb3BwZXIgdGhlIG9uZXMgd2l0aCBhIGhpZ2gNCj4+Y29uZ2VzdGlvbg0KPj4gPnZvbHVtZSB3 aWxsIGNvbnN1bWUgdGhlaXIgYWxsb3dhbmNlcyBxdWlja2x5IGFuZCB3aWxsIGJlIHBlbmFsaXpl ZCBieQ0KPj50aGUNCj4+ID5kcm9wcGVyIGFmdGVyd2FyZHMuIFRodXMgaWYgeW91IGhhdmUgQ29u RVggeW91IGNhbiBoYXZlIGEgZHJvcHBlcg0KPj5pbnN0ZWFkDQo+PiA+b2YNCj4+ID50aGUgc2hh cGVyIGFuZCB0aGlzIHdpbGwgYWN0dWFsbHkgYWxsb3cgeW91IHRvIHBlbmFsaXplIHRoZSBiYWQg Z3V5cw0KPj4gPih3aGVyZWFzDQo+PiA+YSBzaGFwZXIgd2lsbCBwZW5hbGl6ZSB0aGUgaGVhdnkg dXNlcnMsIHdoaWNoIGlzIHRoZSB3cm9uZyBtZXRyaWMgYXMNCj4+ZS5nLg0KPj4gPkxFREJBVCB1 c2VyIGFyZSBuaWNlIGd1eXMpLg0KPj4NCj4+IEkgdGhpbmsgdGhpcyBnZW5lcmFsIGFwcHJvYWNo IGNvdWxkIGJlIHVzZWQgdG8gZXhwYW5kIFguMyBhbmQgcmVmZXIgdGhlDQo+PiAiZHJvcHBlciIg KEkgdGhpbmsgdGhpcyBpcyBjYWxsZWQgaW5ncmVzcyBwb2xpY2luZywgb3IgdHJhZmZpYw0KPj5t YW5hZ2VtZW50DQo+PiBpbiB0aGUgY3VycmVudCBkcmFmdCkuIFdlIGFsc28gaGF2ZSB0aGUgaXNz dWUgd2l0aCB0aGlzIGFwcHJvYWNoDQo+Pm1lbnRpb25lZA0KPj4gZWFybGllciB0aGF0IHNvbWUg d2cgbWVtYmVycyBoYXZlIGV4cHJlc3NlZCB0aGUgb3BpbmlvbiB0aGF0IHRoZXkgZG9uJ3QNCj4+ IHdhbnQgdG8gaW1wbGVtZW50IHBvbGljZXJzLiBJIGFtIE9LIGxpc3RpbmcgdGhpcyBhcyBhbiBv cHRpb24gZm9yDQo+PiBvcGVyYXRvcnMsIGZvciB0aGUgcmVhc29ucyBtZW50aW9uZWQgYWJvdmUu DQo+U29ycnkgSSBtZWFudCBwb2xpY2VyLg0KPg0KPj4NCj4+IEhvd2V2ZXIsIHRoZXJlIGFyZSBz dGlsbCB0aGUgdW5yZXNvbHZlZCBwcm9ibGVtcyBvZiB1bnJlc3BvbnNpdmUgdXNlcnMNCj4+YW5k DQo+PiB0aG9zZSB3aG8gZG8gbm90IGNyZWF0ZSBvYnNlcnZhYmxlIGNvbmdlc3Rpb24gKGFzIGl0 IGlzIGN1cnJlbnRseQ0KPj5kZWZpbmVkKS4NCj5XaGljaCBwcm9ibGVtPyBDb25FeCB3aWxsIGdp dmUgeW91IGV4YWN0bHkgdGhlIGluZm9ybWF0aW9uIG5lZWRlZCB0bw0KPmRpc3Rpbmd1aXNoIHRo b3NlIHR3byBjbGFzc2VzIG9mIHVzZXIuIFRoZXJlIGlzIG5vIGFkZGl0aW9uYWwgbWVjaGFuaXNt DQo+bmVlZGVkIQ0KPg0KPkkgaGF2ZSB0aGUgZmVlbGluZyB0aGF0IGluIHRoZSB0ZXh0IHlvdSBw cm92aWRlZCwgdGhlcmUgYXJlIHNldmVyYWwgcG9pbnRzDQo+bWl4ZWQgdXAuIE1heWJlIHdlIGNh biB0cnkgdG8gc2VwYXJhdGUgdGhlbSBhZ2FpbiBpbiBzbWFsbGVyIHBhcnRzLi4uPw0KDQpKb2hu J3MgcmV3cml0ZSBtYXkgaGVscCBoZXJlLCBidXQgbG9va2luZyBvdmVyIHRoZSB1c2UgY2FzZSBk cmFmdCBzb21lIG9mDQp0aGUgcGFydHMgb3ZlcmxhcCB3aXRoIGV4aXN0aW5nIHVzZSBjYXNlcy4g VGhlcmUgYXJlIGFjdHVhbGx5IHR3bw0KaW1wb3J0YW50IGNhc2VzIHRoYXQgYXJlIGNvbWJpbmVk IGhlcmUgYXMgd2VsbCAtIG5vIHBlciB1c2VyIHNoYXBlcnMgYW5kDQpwZXIgdXNlciBzaGFwZXJz IHRoYXQgY2VydGFpbmx5IGNvdWxkIGJlIHNlcGFyYXRlZC4NCj4NCj5NaXJqYQ0KPg0KPj4NCj4+ ID5NaXJqYQ0KPj4gPg0KPj4gPk9uIEZyaWRheSAwNCBNYXJjaCAyMDExIDE3OjM3OjM3IE1jZHlz YW4sIERhdmlkIEUgd3JvdGU6DQo+PiA+PiBIaSwNCj4+ID4+DQo+PiA+PiBBcyBkb2N1bWVudGVk IGluIHRoZSBJRVRGNzkgQmVpamluZyBtZWV0aW5nIG1pbnV0ZXMgaXQgd2FzIGFncmVlZA0KPj50 aGF0DQo+PiA+PnRoZQ0KPj4gPj4gY29uY2VwdHMgZnJvbSB0aGUgc2VjdGlvbiB0aXRsZWQgIklu ZXF1aXR5IG9mIEhlYXZ5IHZlcnN1cyBMaWdodA0KPj5Vc2VycyINCj4+ID4+IGZyb20gZHJhZnQt bWNkeXNhbi1jb25leC1vdGhlci11c2VjYXNlcyBzaG91bGQgYmUgaW5jbHVkZWQgaW4gdGhlIFdH DQo+PiA+PiBDb25jZXB0cyBhbmQgVXNlIENhc2VzIGRyYWZ0Lg0KPj4gPj4NCj4+ID4+IEFmdGVy IG11Y2ggZGlzY3Vzc2lvbiAodGhhdCByYW5nZWQgd2VsbCBiZXlvbmQgdGhpcyB0b3BpYywgYW5k DQo+PnNwYXduZWQNCj4+ID4+IHNldmVyYWwgb3RoZXIgdGhyZWFkcyB0aGF0IGFyZSBub3QgYWRk cmVzc2VkIGJ5IHRoaXMgcHJvcG9zZWQgdGV4dCksDQo+PiA+PlRvYnkNCj4+ID4+IHByb3Bvc2Vk IGFkZGluZyBhIG5ldyBzZWN0aW9uIHRvIHRoZSB1c2UgY2FzZSBkcmFmdCBhbmQgSQ0KPj52b2x1 bnRlZXJlZCB0bw0KPj4gPj4gZHJhZnQgY29udGVudCBiYXNlZCB1cG9uIHRoZSBvcmlnaW5hbCBk cmFmdCBhcyB3ZWxsIGFzIHRoZSByZWxldmFudA0KPj5saXN0DQo+PiA+PiBkaXNjdXNzaW9uIGZy b20gdGhlIHRocmVhZCB0aXRsZWQgIkRpc2N1c3Npb24gb2YgbmV3IFVzZSBDYXNlcyBwdCAxLCIN Cj4+ID4+YWxvbmcNCj4+ID4+IHdpdGggcmVsZXZhbnQgdGV4dCBmcm9tIHRoZSBzcGF3bmVkIHRo cmVhZHMuIEkgdHJpZWQgdG8gbGlzdCBhbGwgb2YNCj4+dGhlDQo+PiA+PiBwZW9wbGUgd2hvc2Ug aW5wdXRzIEkgdXNlZCB0byBkcmFmdCB0aGlzIHRleHQgYW5kIGFtIHJlcXVlc3RpbmcgdGhlDQo+ PiA+PiB1c2UtY2FzZSBkcmFmdCBhdXRob3JzIHRvIGluY2x1ZGUgeW91ciBuYW1lcyBpbiB0aGUg QWNrbm93bGVkZ2VtZW50DQo+PiA+PnNlY3Rpb24NCj4+ID4+IChpZiBpdCB3YXMgbm90IGFscmVh ZHkgdGhlcmUpLg0KPj4gPj4NCj4+ID4+IFRoZSB0aXRsZSBvZiB0aGUgcHJvcG9zZWQgbmV3IHNl Y3Rpb24gWCBoYXMgYmVlbiBjaGFuZ2VkIHRvIHJlcHJlc2VudA0KPj4gPj50aGUNCj4+ID4+IHBy aW5jaXBhbCBhc3BlY3RzIG9mIHRoZSB1c2UgY2FzZSwgbmFtZWx5IHN0YXRpc3RpY2FsIG11bHRp cGxleGluZw0KPj5vdmVyDQo+PiA+PiBsb25nZXIgdGltZXNjYWxlcy4NCj4+ID4+DQo+PiA+PiBU aGFua3MsDQo+PiA+Pg0KPj4gPj4gRGF2ZQ0KPj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+ID4+DQo+PiA+PiBY LiAgU3RhdGlzdGljYWwgbXVsdGlwbGV4aW5nIG92ZXIgTG9uZ2VyIFRpbWVzY2FsZXMNCj4+ID4+ DQo+PiA+PiBJbiB0aGlzIHVzZSBjYXNlIHRoZSBhc3N1bXB0aW9uIGlzIHRoYXQgImZsYXQgcmF0 ZSIgb3IgImJhbmR3aWR0aA0KPj50aWVyIg0KPj4gPj4gcHJpY2luZyBpcyBpbiBwbGFjZS4gQSBz aW1wbGlmeWluZyBhc3N1bXB0aW9uIGlzIG1hZGUgdGhhdCB0aGVyZSBpcw0KPj5ubw0KPj4gPj52 ZXJ5DQo+PiA+PiBsb25nIHRlcm0gKGUuZy4sIG1vbnRobHkpIHVzYWdlIHRpZXIgcHJpY2luZyBp biBwbGFjZS4NCj4+ID4+DQo+PiA+PiBYLjEgUHJvYmxlbXMgRW5jb3VudGVyZWQgaW4gRXhpc3Rp bmcgTmV0d29ya3MNCj4+ID4+DQo+PiA+PiBUaGUgcHJpbmNpcGFsIHByb2JsZW0gYWRkcmVzc2Vk IGJ5IHRoaXMgdXNlIGNhc2UgaXMgdGhhdCAyMCUgb2YgdGhlDQo+PiA+PnVzZXJzDQo+PiA+PiBn ZW5lcmF0ZSA4MCUgb2YgdGhlIHRyYWZmaWMgdm9sdW1lIGFuZCBjcmVhdGUgdW5mYWlybmVzcyB3 aXRoIGNlcnRhaW4NCj4+ID4+IHJlc291cmNlIHNoYXJpbmcgW1Zhcmlhbl0sIG9mdGVuIHdpdGhv dXQgcGF5aW5nIGFueSBleHRyYSBmb3IgZG9pbmcNCj4+c28NCj4+ID4+d2hlbg0KPj4gPj4gImZs YXQgcmF0ZSIgb3IgImJhbmR3aWR0aCB0aWVyIiBwcmljaW5nIGlzIGluIGVmZmVjdC4gVGhlIHRp bWVzY2FsZQ0KPj5vdmVyDQo+PiA+PiB3aGljaCB0aGlzIGRpZmZlcmVuY2UgaW4gdHJhZmZpYyB2 b2x1bWUgZXhpc3RzIGNhbiByYW5nZSBmcm9tDQo+PnNlY29uZHMsDQo+PiA+PnRvDQo+PiA+PiBt YW55IG1pbnV0ZXMgdG8gaG91cnMuIFRoZSBwZWFrIHJhdGUgYXQgd2hpY2ggYSB1c2VyIGNhbiBz ZW5kIG1heSBiZQ0KPj4gPj5zZXQgYnkNCj4+ID4+IHRoZSBwaHlzaWNhbCB0cmFuc21pc3Npb24g c3lzdGVtLCBhIG5vbi13b3JrIGNvbnNlcnZpbmcgc2NoZWR1bGVyLA0KPj4gPj5hbmQvb3IgYQ0K Pj4gPj4gcG9saWNlci4NCj4+ID4+DQo+PiA+PiBUaGUgYWNjZXNzIG5ldHdvcmsgaXMgdXN1YWxs eSBub3QgcHJvdmlzaW9uZWQgYW5kIHRyYWZmaWMgZW5naW5lZXJlZA0KPj5mb3INCj4+ID4+IHRo ZSBwZWFrIHJhdGUgZm9yIGFsbCB1c2VycyBidXQgaXMgaW5zdGVhZCBwcm92aXNpb25lZCBhc3N1 bWluZw0KPj4gPj5zdGF0aXN0aWNhbA0KPj4gPj4gbXVsdGlwbGV4aW5nIHdoZXJlIGEgbG9uZ2Vy IHRlcm0gKG1hbnkgc2Vjb25kcyB0byBtaW51dGVzIHRvIGhvdXJzKQ0KPj4gPj5hdmVyYWdlDQo+ PiA+PiBjYXBhY2l0eSBpcyBhc3N1bWVkIGZvciBhbGwgdXNlcnMgZHVyaW5nIHRoZSBidXN5IHBl cmlvZC4gVGhlIG1hbnkNCj4+ID4+bWludXRlcw0KPj4gPj4gdGltZXNjYWxlIGlzIGNvbW1vbmx5 IHVzZWQgYnkgbmV0d29yayBvcGVyYXRvcnMgdG8gZGV0ZXJtaW5lIHdoZW4gYQ0KPj4gPj5wb3J0 aW9uDQo+PiA+PiBvZiBhIG5ldHdvcmsgaXMgbmVhciBjb25nZXN0aW9uIFtzZWN0aW9uIDMuMywg QmF1ZXJdLiBEdXJpbmcgbm9uLWJ1c3kNCj4+ID4+IHBlcmlvZHMsIHRoZSBzZXJ2aWNlIHByb3Zp ZGVyIG5ldHdvcmsgaXMgdW5kZXJ1dGlsaXplZCBhbmQgaGVuY2UNCj4+dGhlcmUNCj4+ID4+aXMN Cj4+ID4+IG5vIGNvbmdlc3Rpb24gb2Ygc2hhcmVkIHJlc291cmNlcy4NCj4+ID4+DQo+PiA+PiBE dXJpbmcgYnVzeSBwZXJpb2RzIHdoZXJlIGNvbmdlc3Rpb24gKGkuZS4sIGxvc3Mgb3IgRUNOIG1h cmtpbmcpIG9mIGENCj4+ID4+IHNoYXJlZCByZXNvdXJjZSAoZS5nLiwgYSBxdWV1ZSBvciBzY2hl ZHVsZXIpIGNhbiBvY2N1ciwgaGVhdmllciB1c2Vycw0KPj4gPj5tYXkNCj4+ID4+IHNlbmQgYXQg c3BlZWRzIHVwIHRvIHRoZSBwZWFrIHJhdGUgd2hpbGUgbGlnaHRlciB1c2VycyBtYXkgc2VuZCBh dCBhDQo+PiA+PnJhdGUNCj4+ID4+IG11Y2ggbGVzcyB0aGFuIHRoZSBwZWFrIHJhdGUuIFRoZSBy ZXN1bHQgaXMgdGhhdCBhbGwgdXNlcnMgc2VlIHRoZQ0KPj5zYW1lDQo+PiA+PiBjb25nZXN0aW9u IChpLmUuLCBsb3NzIG9yIEVDTiBtYXJraW5nIHByb2JhYmlsaXR5KSBhbHRob3VnaCB0aGUNCj4+ bGlnaHRlcg0KPj4gPj4gdXNlcnMgYXJlIHNlbmRpbmcgYXQgbXVjaCBsZXNzIHRoYW4gdGhlIHBl YWsgcmF0ZS4gRnVydGhlcm1vcmUsIHdoZW4NCj4+dGhlDQo+PiA+PiBzaGFyZWQgcmVzb3VyY2Ug aXMgY29uZ2VzdGVkLCBoZWF2eSB1c2VycyBjcmVhdGUgbXVjaCBtb3JlIGNvbmdlc3Rpb24NCj4+ ID4+IHZvbHVtZSB0aGFuIGxpZ2h0IHVzZXJzLiBJbiB0aGlzIHNlbnNlLCB0aGUgcmVzcG9uc2Ug b2YgY3VycmVudA0KPj4gPj5uZXR3b3JrcyBpcw0KPj4gPj4gInVuZmFpciwiIHdoaWNoIGlzIGFs c28gY2FsbGVkICJlY29ub21pYyBjb25nZXN0aW9uIiBbc2VjdGlvbiAzLjQsDQo+PiA+PkJhdWVy XS4NCj4+ID4+DQo+PiA+PiBUaGUgYWJvdmUgc2l0dWF0aW9uIG9jY3VycyBpbiBmbGF0IHJhdGUg cHJpY2luZyB3aGVyZSBhbGwgdXNlciBmbG93cw0KPj4gPj5zaGFyZQ0KPj4gPj4gdGhlIHNhbWUg cmVzb3VyY2UgKGUuZy4sIHF1ZXVlLCBzY2hlZHVsZXIpLg0KPj4gPj4NCj4+ID4+IEluIG1hbnkg bmV0d29ya3MgYSBub24gd29yayBjb25zZXJ2aW5nIHNjaGVkdWxlciAoZS5nLiwgYSBzaGFwZXIp DQo+PiA+PiBpbXBsZW1lbnRzIGEgcGVyLXVzZXIgcGVhayByYXRlIG92ZXIgYW4gaW50ZXJ2YWwg TygxMDAgbXMpLiBTZWUNCj4+ID4+QXBwZW5kaXggQg0KPj4gPj4gb2YgW0RTTCBGb3J1bSBUUi0w NTldIGZvciBhIERTTCBzcGVjaWZpYyBleGFtcGxlIG9mIG5vbi13b3JrDQo+PmNvbnNlcnZpbmcN Cj4+ID4+IHNjaGVkdWxlcnMuIFNpbWlsYXIgdGVjaG5pcXVlcyBhcmUgdXNlZCBpbiBhY2Nlc3Mg bmV0d29yayBlcXVpcG1lbnQNCj4+ID4+YWNyb3NzDQo+PiA+PiBhIHJhbmdlIG9mIGFjY2VzcyB0 ZWNobm9sb2dpZXMuIFRodXMsIHRoZSAiYmFuZHdpZHRoIHRpZXIiIGluY2VudGl2ZQ0KPj5pcw0K Pj4gPj4gdGhhdCBhIHVzZXIgcGF5cyBtb3JlIGlmIGhlL3NoZSB3YW50cyBtb3JlIHBlYWsgcmF0 ZSBiYW5kd2lkdGguDQo+PiA+Pg0KPj4gPj4gU3VjaCBub24td29yayBjb25zZXJ2aW5nIHNjaGVk dWxlcnMgY3JlYXRlIGFwcGFyZW50IGNvbmdlc3Rpb24gKGkuZS4sDQo+PiA+Pmxvc3MNCj4+ID4+ IG9yIEVDTiBtYXJraW5nKSB3aXRoaW4gdGhlaXIgcXVldWUocykgd2hpY2ggaW1wYWN0IG9ubHkg YSBzaW5nbGUgdXNlcg0KPj4gPj50aGF0DQo+PiA+PiBuZWVkIHRvIGJlIGNvbnNpZGVyZWQgaW4g dGhlIHNldCBvZiBjb25leCB1c2UgY2FzZXMuIEZ1cnRoZXINCj4+ZGlzY3Vzc2lvbg0KPj4gPj5v bg0KPj4gPj4gdGhpcyB0b3BpYyBpcyBjb3ZlcmVkIGluIHRoZSBzZWN0aW9uICJTZWxmLUNvbmdl c3Rpb24gdmVyc3VzDQo+PkludGVyLVVzZXINCj4+ID4+IENvbmdlc3Rpb24uIg0KPj4gPj4NCj4+ ID4+IFguMiBDb25leCBPYmplY3RpdmVzIGZvciBhIFNvbHV0aW9uIHRvIHRoaXMgUHJvYmxlbQ0K Pj4gPj4NCj4+ID4+IFRoZSBnZW5lcmFsIG9iamVjdGl2ZSBmb3IgY29uZXggaXMgdG8gcHJvdmlk ZSBiZXR0ZXIgaW5mb3JtYXRpb24gZm9yDQo+PmENCj4+ID4+IHByb3ZpZGVyIHRvIGFkZHJlc3Mg dGhlICJ1bmZhaXJuZXNzIiBvciAiZWNvbm9taWMgY29uZ2VzdGlvbiIgcHJvYmxlbQ0KPj4gPj4g ZGVzY3JpYmVkIGluIHRoZSBwcmV2aW91cyBzZWN0aW9uLg0KPj4gPj4NCj4+ID4+IEEgc3BlY2lm aWMgb2JqZWN0aXZlIGlzIHRvIGFjaGlldmUgYSAiZmFpcm5lc3MiIG1lYXN1cmUgb2YgYmFuZHdp ZHRoDQo+PiA+PiBkZWxpdmVyZWQgaW4gcHJvcG9ydGlvbiB0byB0aGUgdXNlciBwZWFrIHJhdGUg d2hlbiBjb25nZXN0aW9uIG9mIGENCj4+ID4+c2hhcmVkDQo+PiA+PiByZXNvdXJjZSBvY2N1cnMu DQo+PiA+Pg0KPj4gPj4gQSBzcGVjaWZpYyBvYmplY3RpdmUgaXMgdG8gZGlzdGluZ3Vpc2ggaGVh dmllciB1c2VycyBmcm9tIGxpZ2h0ZXINCj4+dXNlcnMNCj4+ID4+IG92ZXIgYSB0aGUgc3RhdGlz dGljYWwgbXVsdGlwbGV4aW5nIHRpbWUgaW50ZXJ2YWwgdGhhdCBjYW4gcmFuZ2UgZnJvbQ0KPj4g Pj4gc2Vjb25kcywgdG8gbWludXRlcywgdG8gaG91cnMgc28gdGhhdCBuZXR3b3JrIHByb3ZpZGVy IHRyYWZmaWMNCj4+ID4+bWFuYWdlbWVudA0KPj4gPj4gZnVuY3Rpb25zIGNhbiBwcm92aWRlICJm YWlyZXIiIGFsbG9jYXRpb24gb2YgYmFuZHdpZHRoLg0KPj4gPj4NCj4+ID4+IEEgZGVzaXJhYmxl IG9iamVjdGl2ZSBpcyB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuICJzZWxmLWNvbmdlc3Rpb24iIGFu ZA0KPj4gPj4gImludGVyLXVzZXIgY29uZ2VzdGlvbiIgc28gdGhhdCB1c2VycyBjb3VsZCB1c2Ug YSBtZWNoYW5pc20gZXh0ZXJuYWwNCj4+dG8NCj4+ID4+IGNvbmV4IHRvICJnbyBmYXN0ZXIiIGlu IHRoZSBldmVudCB0aGF0IG9ubHkgInNlbGYtY29uZ2VzdGlvbiIgaXMNCj4+ID4+bGltaXRpbmcN Cj4+ID4+IHRoZWlyIHRocm91Z2hwdXQuDQo+PiA+Pg0KPj4gPj4gWC4yIFNlbGYtQ29uZ2VzdGlv biB2ZXJzdXMgSW50ZXItVXNlciBDb25nZXN0aW9uDQo+PiA+Pg0KPj4gPj4gSWYgdGhlIHVzZXIg c2VuZHMgYXQgbW9yZSB0aGFuIHRoZSBzaGFwZXIgcGVhayByYXRlIGFuZCB0aGVyZSBpcyBubw0K Pj4gPj4gY29uZ2VzdGlvbiBhdCBhIHNoYXJlZCByZXNvdXJjZSwgdGhlbiBvdGhlciB1c2VycyBh cmUgbm90IGltcGFjdGVkLA0KPj5hbmQNCj4+ID4+aW4NCj4+ID4+IGEgc2Vuc2UgdGhpcyB1c2Vy IGNyZWF0ZXMgInNlbGYtY29uZ2VzdGlvbi4iIFRoZXJlIGlzIGFsc28gdGhlIGNhc2UNCj4+d2hl bg0KPj4gPj4gY29uZ2VzdGlvbiBvY2N1cnMgYXQgYSBzaGFyZWQgcmVzb3VyY2UsIHdoaWNoIGNh dXNlcw0KPj4gPj4gImludGVyLXVzZXItY29uZ2VzdGlvbiwiIHdoZXJlIGNvbmdlc3Rpb24gdm9s dW1lIGZyb20gb25lIHVzZXINCj4+aW1wYWN0cw0KPj4gPj4gb3RoZXIgdXNlcnMuIE5vdGUgdGhh dCAiU2VsZi1Db25nZXN0aW9uIiBjYW4gb2NjdXIgd2hlbiAiSW50ZXItVXNlcg0KPj4gPj4gQ29u Z2VzdGlvbiIgb2NjdXJzLiBIb3dldmVyLCBhIGhlYXZpZXIgdXNlciBtYXkgbm90IGNyZWF0ZQ0K Pj4gPj4gInNlbGYtY29uZ2VzdGlvbiIgKGkuZS4sIGxvc3Mgb3IgRUNOIG1hcmtpbmcpIGlmIHRo YXQgdXNlciBzZW5kcyBhdA0KPj4gPj4gc2xpZ2h0bHkgbGVzcyB0aGFuIGEgc2hhcGVyIHBlYWsg cmF0ZSAoZS5nLiwgdXNpbmcgTEVEQkFUKS4NCj4+ID4+DQo+PiA+PiBUaGVyZSBhcmUgKGF0IGxl YXN0KSB0aHJlZSBhcHByb2FjaGVzIGZvciBhZGRyZXNzaW5nIHRoaXMgaXNzdWUuDQo+PiA+PkFw cHJvYWNoZXMNCj4+ID4+IDEsIDIuYSByZXF1aXJlIG5vIGNoYW5nZSB0byB0aGUgY29uZXggYWJz dHJhY3QgbWVjaGFuaXNtDQo+PiA+PiBbd2ctYWJzdHJhY3QtbWVjaGFuaXNtXS4gQXBwcm9hY2gg Mi5iIHdvdWxkIHJlcXVpcmUgc2lnbmFsaW5nIG9mDQo+PiA+PmFkZGl0aW9uYWwNCj4+ID4+IGlu Zm9ybWF0aW9uIHRvIHRoZSByZWNlaXZlciAoY291bGQgYmUgZG9uZSBzZXBhcmF0ZWx5IGZyb20g Y29uZXgpLA0KPj5hbmQNCj4+ID4+IGFwcHJvYWNoIDMgbWF5IGJlIGFibGUgdG8gdXNlIHRoZSBj b25leCBhYnN0cmFjdCBtZWNoYW5pc20sIGFsYmVpdA0KPj4gPj4gcG90ZW50aWFsbHkgaW4gYSBk aWZmZXJlbnQgY29uZmlndXJhdGlvbi4NCj4+ID4+DQo+PiA+PiAxLiBUcmVhdCAic2VsZi1jb25n ZXN0aW9uIiB0aGUgc2FtZSBhcyAiaW50ZXItdXNlciBjb25nZXN0aW9uIiBzaW5jZQ0KPj4gPj50 aGV5DQo+PiA+PiBib3RoIGNyZWF0ZSBjb25nZXN0aW9uIGFzIHBlcmNlaXZlZCBieSB0aGUgZmxv dyB1c2VyLg0KPj4gPj4NCj4+ID4+IDIuIFNpZ25hbCBtb3JlIGluZm9ybWF0aW9uIHRvIHRoZSBy ZWNlaXZlciBhYm91dCB0aGUgY2F1c2Ugb2YgbG9zcw0KPj5zaW5jZQ0KPj4gPj4gdGhlIHJlbWVk eSBkaWZmZXJzOg0KPj4gPj4gICBhLiBGb3IgYSBzaGFyZWQgcXVldWUsIHVzZSBjdXJyZW50IGRy YWZ0IG9mIGFic3RyYWN0IG1lY2hhbmlzbQ0KPj5zaWduYWxzDQo+PiA+PiB0byByZWR1Y2UgbG9h ZCBhbmQgY2hvb3NlIHBhY2tldHMgZm9yIGRpZmZlcmVudCB0cmVhdG1lbnRzLg0KPj4gPj4gICBi LiBGb3IgYSBxdWV1ZSBkZWRpY2F0ZWQgdG8gYSByZWNlaXZlciAoZS5nLiwgc2hhcGVyKSBzaWdu YWwNCj4+ID4+aW5mb3JtYXRpb24NCj4+ID4+IHRoYXQgdGhlIHNoYXBlciBwZWFrIHJhdGUgaXMg dGhlIGJvdHRsZW5lY2sgdG8gdGhlIHJlY2VpdmVyLCBzbyB0aGF0DQo+PiA+PiBzb21laG93IChz cGVjaWZpYyBtZWNoYW5pc20gbWF5IG5vdCBmaXQgd2l0aGluIHRoZSBjdXJyZW50IGNvbmV4IHdn DQo+PiA+PiBjaGFydGVyKSB0aGUgdXNlciBjb3VsZCBtYWtlIGEgcmVxdWVzdCB0byAiZ28gZmFz dGVyLiINCj4+ID4+DQo+PiA+PiAzLiBQcm9jZXNzIGFuZCBnZW5lcmF0ZSBjb25leCBpbmZvcm1h dGlvbiBhdCB0aGUgbmV0d29yayBlbGVtZW50DQo+PndoaWNoDQo+PiA+PiBpbXBsZW1lbnRzIHRo ZSBzaGFwZXIsIHdoaWNoIGhhcyBrbm93bGVkZ2Ugb2YgdGhlIGNvbmZpZ3VyZWQgcGVhaw0KPj5y YXRlcw0KPj4gPj5mb3INCj4+ID4+IHRoZSB1c2VycyBhcyB3ZWxsIGFzIGxvY2FsIHNoYXJlZCBy ZXNvdXJjZSBjb25nZXN0aW9uLiBUaGlzIG5ldHdvcmsNCj4+ID4+ZWxlbWVudA0KPj4gPj4gY2Fu IGFsc28gdXNlIGluZm9ybWF0aW9uIGFib3V0IHVwc3RyZWFtIHNoYXJlZCByZXNvdXJjZSBjb25n ZXN0aW9uIGFzDQo+PiA+PiBkZWxpdmVyZWQgYnV5IHRoZSBjb25leCBwcm90b2NvbC4NCj4+ID4+ DQo+PiA+PiBOb3RlIHRoYXQgZHVyaW5nIGJ1c3kgcGVyaW9kcyAic2VsZiBjb25nZXN0aW9uIiBt YXkgbm90IGJlIHRoZQ0KPj5saW1pdGluZw0KPj4gPj4gZmFjdG9yLCBidXQgZHVyaW5nIG5vbi1i dXN5IHBlcmlvZHMgaXQgd2lsbCBiZSB0aGUgYmlnZ2VzdCBzb3VyY2Ugb2YNCj4+ID4+IGFwcGFy ZW50IGNvbmdlc3Rpb24uDQo+PiA+Pg0KPj4gPj4gWC4zIFBvdGVudGlhbCBTdXBwb3J0IFVzaW5n IEFic3RyYWN0IE1lY2hhbmlzbQ0KPj4gPj4NCj4+ID4+IFtFZGl0b3JpYWwgTm90ZSBmcm9tIERh dmU6IFRoZSBmb2xsb3dpbmcgd2FzIGRlcml2ZWQgbGlzdCBjb21tZW50cyBhcw0KPj4gPj53ZWxs DQo+PiA+PiBhcyBhIHByaXZhdGUgaW5wdXQgZnJvbSBUb2J5IE1vbmNhc3Rlci5dDQo+PiA+Pg0K Pj4gPj4gVGhlIGZvbGxvd2luZyBzY2VuYXJpbyBhc3N1bWVzIHRoYXQgYWxsIHVzZXIgZmxvd3Mg aW1wbGVtZW50IGNvbmV4Lg0KPj5UaGUNCj4+ID4+IGNhc2Ugd2hlcmUgbm90IGFsbCBmbG93cyBp bXBsZW1lbnQgY29uZXggc3RpbGwgbmVlZHMgdG8gYmUgYWRkcmVzc2VkLg0KPj4gPj4oU29tZQ0K Pj4gPj4gZm9ybSBvZiBsb2NhbGl6ZWQgImNvbmV4LWxpa2UiIG1hcmtpbmcgbWF5IGhhbmRsZSB0 aGlzIGNhc2UsIHNpbmNlDQo+PiA+PmhlYXZpZXINCj4+ID4+IHVzZXJzIG1heSBoYXZlIGEgc2ln bmlmaWNhbnQgaW5jZW50aXZlIHRvIG5vdCBpbXBsZW1lbnQgY29uZXgpLiBBbHNvDQo+PnRvDQo+ PiA+PmJlDQo+PiA+PiBhZGRyZXNzZWQgaXMgdGhlIHNjZW5hcmlvIHdoZXJlIGhlYXZ5IHVzZXJz IGRvIG5vdCBjcmVhdGUgY29uZ2VzdGlvbg0KPj4gPj4oZS5nLiwNCj4+ID4+IHVzaW5nIExFREJB VCksIGJ1dCB0aGVyZSBpcyBzdGlsbCBhIHNpZ25pZmljYW50IGRpZmZlcmVuY2UgaW4gYXZlcmFn ZQ0KPj4gPj5yYXRlLA0KPj4gPj4gb3IgYnVyc3RpbmVzcyAocGVhay9hdmVyYWdlKS4NCj4+ID4+ DQo+PiA+PiBVc2luZyB0aGUgYWJzdHJhY3QgbWVjaGFuaXNtIGEgaGVhdmllciB1c2VyICBuZXZl ciBnZXRzIGEgY2hhbmNlIHRvDQo+PiA+PmJ1aWxkDQo+PiA+PiB1cCBhbnkgY29uZ2VzdGlvbiBj cmVkaXQsIHdoaWNoIHdpbGwgbm90IGltcGFjdCB0aGVpciBzZXJ2aWNlIGR1cmluZw0KPj4gPj4g bm9uLWJ1c3kgcGVyaW9kcy4gSG93ZXZlciwgYXQgcGVhayB0aW1lcyBpdCBtZWFucyB0aGVpciBz ZXJ2aWNlIGlzDQo+PiA+PmRlZ3JhZGVkDQo+PiA+PiBsb25nIGJlZm9yZSBhIGxpZ2h0IHVzZXIg c2VlcyBhbnkgaW1wYWN0LiBJbiB0dXJuIHRoaXMgbWVhbnMgdGhlDQo+PiA+PmNvbmdlc3Rpb24N Cj4+ID4+IHNlZW4gYnkgdGhlIGxpZ2h0IHVzZXIgaXMgbGVzcywgbWVldGluZyBhbiBpbXBvcnRh bnQgb2JqZWN0aXZlLg0KPj4gPj4NCj4+ID4+IEFkZGl0aW9uYWwgbG9jYWwgY29tcHV0YXRpb25z IGFyZSBkb25lIGFzIGZvbGxvd3MuIE92ZXIgYSAgdGltZQ0KPj5wZXJpb2QNCj4+ID4+IHJlbGF0 ZWQgdG8gdGhlIHN0YXRpc3RpY2FsIG11bHRpcGxleGluZyBpbnRlcnZhbCAoZS5nLiwgbWFueSBz ZWNvbmRzDQo+PnRvDQo+PiA+PiBtaW51dGVzIHRvIGhvdXJzKSB0b3RhbCB1cCB0aGUgbnVtYmVy IG9mIGJ5dGVzIHRoYXQgaGF2ZSBiZWVuDQo+PmNvbmdlc3Rpb24NCj4+ID4+IG1hcmtlZCBhbmQg dGhlIHRvdGFsIG51bWJlciBvZiBieXRlcyBzZW50IHBlciB1c2VyLiBDb21wdXRlIHRoZQ0KPj5y YXRpbyBvZg0KPj4gPj4gY29uZ2VzdGVkIGJ5dGVzIHRvIHRvdGFsIGJ5dGVzLg0KPj4gPj4NCj4+ ID4+IFRoZSB0b3RhbCBpcyBhIG1lYXN1cmUgb2YgdGhlIGF2ZXJhZ2UgcmF0ZSBwZXIgdXNlciAo YXZlcmFnZWQgb3Zlcg0KPj50aGUNCj4+ID4+dGltZQ0KPj4gPj4gcGVyaW9kIG9mIHRoZSB0b3Rh bCkuDQo+PiA+Pg0KPj4gPj4gRm9yIGV4YW1wbGUsIHF1YW50aXppbmcgdXNlcnMgaW50byBjbGFz c2VzIHVzaW5nIG9uZSB0aHJlc2hvbGQgb24NCj4+dG90YWwNCj4+ID4+YW5kDQo+PiA+PiBhbmQg YW5vdGhlciB0aHJlc2hvbGQgb24gcmF0aW8gcmVzdWx0cyBpbiBhIGdyaWQgdGhhdCBpZGVudGlm aWVzIGZvdXINCj4+ID4+IGRpc3RpbmN0IGNsYXNzZXMgb2YgdXNlciBhcyBmb2xsb3dzOg0KPj4g Pj4NCj4+ID4+ICstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSsN Cj4+ID4+DQo+PiA+PiB8ICAgVG90YWwgdm9sdW1lPnwgICAgICAgICAgICAgfCAgICAgICAgICAg ICB8DQo+PiA+PiB8diBSYXRpbyAgICAgICAgIHwgICAgTGFyZ2UgICAgfCAgICBTbWFsbCAgICB8 DQo+PiA+Pg0KPj4gPj4gKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tKw0KPj4gPj4NCj4+ID4+IHwgICBIaWdoICAgICAgICAgfCBIZWF2eSBVc2VyICB8IEJ1cnN0 eSBVc2VyIHwNCj4+ID4+DQo+PiA+PiArLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0rDQo+PiA+Pg0KPj4gPj4gfCAgIExvdyAgICAgICAgICB8IExFREJBVCBVc2Vy IHwgTGlnaHQgVXNlciAgfA0KPj4gPj4NCj4+ID4+ICstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLSsNCj4+ID4+DQo+PiA+PiBYLjQgQWRkaXRpb25hbCBTdXBwb3J0 IFVzaW5nIG90aGVyIE1lYXN1cmVzIGFuZCBNZWNoYW5pc21zDQo+PiA+Pg0KPj4gPj4gQW4gYWRk aXRpb25hbCBjb25nZXN0aW9uIG1lYXN1cmUgb2YgYnVyc3RpbmVzcyAoZS5nLiwgcmF0aW8gb2Yg cGVhaw0KPj4gPj5yYXRlIHRvDQo+PiA+PiBhdmVyYWdlIHJhdGUgb3ZlciBhIGxvbmdlciBpbnRl cnZhbCB0aGFuIHRoZSB0aWVyZWQgYmFuZHdpZHRoIHNoYXBlcikNCj4+ID4+d291bGQNCj4+ID4+ IGFsbG93IG5vZGVzIHVwc3RyZWFtIGZyb20gdGhlIG5vZGUgaW1wbGVtZW50aW5nIHRoZSBzaGFw ZXIgdG8NCj4+aW1wbGVtZW50DQo+PiA+PiB0cmFmZmljIG1hbmFnZW1lbnQuIFRoaXMgbWVhc3Vy ZSBjb3VsZCBiZSBkZXJpdmVkIGZyb20gc2lnbmFscyBpbiB0aGUNCj4+ID4+IGFic3RyYWN0IG1l Y2hhbmlzbSBidXQgd291bGQgcmVxdWlyZSAoYSBtYWpvcml0eSkgb2YgdGhlIGhlYXZpZXINCj4+ c2VuZGVycw0KPj4gPj4gYW5kIHJlY2VpdmVycyB0byBpbXBsZW1lbnQgY29uZXggYW5kIGFsc28g d291bGQgb25seSB3b3JrIGlmIGxvc3Mgb3INCj4+RUNODQo+PiA+PiBtYXJraW5nIG9jY3Vycy4g SGVhdmllciB1c2VycyBtYXkgaGF2ZSBhIHNpZ25pZmljYW50IGluY2VudGl2ZSB0byBub3QNCj4+ ID4+IGltcGxlbWVudCBjb25leCwgYW5kIHNvbWUgYWRkaXRpb25hbCBtZWNoYW5pc20gdG8gYWRk cmVzcyB0aGlzIGlzc3VlDQo+PiA+Pm1heSBiZQ0KPj4gPj4gcmVxdWlyZWQuIEFsc28sIHNpZ25h bGluZyBhIG1lYXN1cmUgb2YgdGhlIGJ1cnN0aW5lc3MgKG9yIHNvbWV0aGluZw0KPj4gPj5yZWxh dGVkDQo+PiA+PiB0byBpdCkgd291bGQgYWRkcmVzcyB0aGUgc2NlbmFyaW8gd2hlcmUgbm8gbG9z cyBvciBFQ04gbWFya2luZw0KPj5vY2N1cnMuDQo+PiA+Pg0KPj4gPj4gQXMgYW4gYWx0ZXJuYXRp dmUsIGlmIGEgImxpZ2h0IHdlaWdodCIgVENQIHByb3h5IHdlcmUgaW1wbGVtZW50ZWQgYXQNCj4+ dGhlDQo+PiA+PiBuZXR3b3JrIGVsZW1lbnQgY29udGFpbmluZyB0aGUgc2hhcGVyIChlLmcuLCBh biBhY2Nlc3Mgcm91dGVyKSBhbmQgYW4NCj4+ID4+IHVwc3RyZWFtIG5ldHdvcmsgZWxlbWVudCAo ZS5nLiwgYSByb3V0ZXIgYXQgaW5ncmVzcyB0byB0aGUgc2VydmljZQ0KPj4gPj5wcm92aWRlcg0K Pj4gPj4gbmV0d29yayksIHRoZW4gcG90ZW50aWFsbHkgYSBjb25leCBjb250cm9sIGxvb3AgY291 bGQgYmUgY3JlYXRlZA0KPj5iZXR3ZWVuDQo+PiA+PiB0aGVzZSBuZXR3b3JrIGVsZW1lbnRzIHRv IHByb3ZpZGUgZmFpcmVyIHRyZWF0bWVudCBiZXR3ZWVuIGhlYXZpZXINCj4+YW5kDQo+PiA+PiBs aWdodGVyIHVzZXJzIGR1cmluZyBjb25nZXN0ZWQgaW50ZXJ2YWxzLiBJbiB0aGlzIGNhc2UsIGEg c3Vic2V0IG9mDQo+PiA+PmNvbmV4DQo+PiA+PiBmZWF0dXJlcyBjb3VsZCBwb3RlbnRpYWxseSBi ZSB1c2VkIHNpbmNlIHRoaXMgd291bGQgYmUgYSBjbG9zZWQNCj4+ZG9tYWluDQo+PiA+PiB3aGVy ZSB0aGUgc2lnbmFscyBjb3VsZCBiZSBpbXBsaWNpdGx5IHRydXN0ZWQuIFRoZSBidXJzdGluZXNz IG1lYXN1cmUNCj4+ID4+Y291bGQNCj4+ID4+IGJlIGNvbW11bmljYXRlZCB1c2luZyBUQ1AgZXh0 ZW5zaW9ucyBiZXR3ZWVuIHRoZXNlIHByb3hpZXMuDQo+PiA+Pg0KPj4gPj4gVGhlcmUgaXMgYWxz byB0aGUgYXNwZWN0IG9mICJzZWxmIGNvbmdlc3Rpb24iIHdoZW4gYSBub24td29yaw0KPj5jb25z ZXJ2aW5nDQo+PiA+PiBzY2hlZHVsZXIgKGUuZy4sIHNoYXBlcikgaXMgZW1wbG95ZWQgYXQgdGhl IGFjY2VzcyBub2RlLiBFdmVuIHdoZW4NCj4+ID4+ICJpbnRlci11c2VyIGNvbmdlc3Rpb24iIGlz IG5vdCBvY2N1cnJpbmcgKGUuZy4sIGR1cmluZyBhIG5vbi1idXN5DQo+PiA+PnBlcmlvZCksDQo+ PiA+PiAic2VsZiBjb25nZXN0aW9uIiBtYXkgb2NjdXIuIEhvd2V2ZXIsIGFzIGRpc2N1c3NlZCBp biB0aGUgc2VjdGlvbiBvbg0KPj4gPj4iU2VsZg0KPj4gPj4gQ29uZ2VzdGlvbiB2ZXJzdXMgSW50 ZXItVXNlciBDb25nZXN0aW9uLCIgdXNpbmcgY3VycmVudCBtZWNoYW5pc21zDQo+PiA+PihpLmUu LA0KPj4gPj4gaW1wbGljaXRseSBkZXRlcm1pbmVkIGxvc3Mgb3IgRUNOIG1hcmtpbmcpIHRoZSBy ZWNlaXZlciBjYW5ub3QgdGVsbA0KPj50aGUNCj4+ID4+IGRpZmZlcmVuY2UgYmV0d2VlbiAic2Vs Zi1jb25nZXN0aW9uIiBhbmQgImludGVyLXVzZXIgY29uZ2VzdGlvbi4iDQo+PiA+PkFkZGluZyBh DQo+PiA+PiBzaWduYWwgdG8gdGhlIGFic3RyYWN0IG1lY2hhbmlzbSBjb3VsZCBiZSBxdWl0ZSB1 c2VmdWwgc28gdGhhdCBhDQo+PiA+PnJlY2VpdmVyDQo+PiA+PiBjYW4gaW5mb3JtIHRoZSBzZW5k ZXIgcmVnYXJkaW5nIHRoZSBjYXVzZSBvZiBjb25nZXN0aW9uLCBhbmQgZW5hYmxlDQo+PnRoZQ0K Pj4gPj4gc2VuZGVyIChvciB0aGUgcmVjZWl2ZXIpIHRvIGNvbW11bmljYXRlIHdpdGggdGhlIG5l dHdvcmsgZWxlbWVudA0KPj4gPj4gY29udHJvbGxpbmcgdGhlIHNoYXBlciBwYXJhbWV0ZXJzIGVu YWJsaW5nIHRoZSBmbG93IHRvICJnbyBmYXN0ZXIuIg0KPj4gPj51c2luZw0KPj4gPj4gc29tZSBu b24tY29uZXggbWVjaGFuaXNtLg0KPj4gPj4NCj4+ID4+DQo+PiA+PiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4+ID4+DQo+PiA+PiBbRWRpdG9yaWFsIE5vdGU6IFBsZWFzZSBhZGQgdGhlIGZvbGxv d2luZ10NCj4+ID4+DQo+PiA+PiBBY2tub3dsZWRnZW1lbnRzDQo+PiA+Pg0KPj4gPj4gQWRkIHRo ZSBmb2xsb3dpbmc6ICBTdHVhcnQgVmVudGVycywgTWlrYWVsIEFicmFoYW1zc29uLCBNaXJqYQ0K Pj4gPj5LdWVobGV3aW5kLA0KPj4gPj4gSm/Do28gVGF2ZWlyYSBBcmHDumpvLCBDYWl0bGluIEJl c3RsZXIsIFN0ZXZlbiBCYXVlciwgxaANCj4+ID4+DQo+PiA+PiBbRWRpdG9yaWFsIE5vdGU6IE15 IHRoYW5rcyBmb3IgaW5wdXRzIGZyb20gYXV0aG9ycywgZm9sa3MgYWxyZWFkeQ0KPj4gPj5saXN0 ZWQgaW4NCj4+ID4+IEFja25vd2xlZGdlbWVudHM6IFRvYnkgTW9uY2FzdGVyLCBKb2huIExlc2xp ZSwgQWxpc3NhIENvb3BlciwgUmljaA0KPj4gPj5Xb3VuZHksDQo+PiA+PiDFoF0NCj4+ID4+DQo+ PiA+PiBSZWZlcmVuY2VzDQo+PiA+Pg0KPj4gPj4gW0RTTCBGb3J1bSBUUi0wNTldIFRlY2huaWNh bCBSZXBvcnQgRFNMIEZvcnVtIFRSLTA1OSwgIkRTTCBFdm9sdXRpb24NCj4+LQ0KPj4gPj4gQXJj aGl0ZWN0dXJlIFJlcXVpcmVtZW50cyBmb3IgdGhlIFN1cHBvcnQgb2YgUW9TLUVuYWJsZWQgSVAN Cj4+U2VydmljZXMsIg0KPj4gPj4gU2VwdGVtYmVyIDIwMDMsDQo+PiA+PiBodHRwOi8vd3d3LmJy b2FkYmFuZC1mb3J1bS5vcmcvdGVjaG5pY2FsL2Rvd25sb2FkL1RSLTA1OS5wZGYNCj4+ID4+DQo+ PiA+PiBbVmFyaWFuXSBIYWwgVmFyaWFuLCBHb29nbGUsICJDb25nZXN0aW9uIHByaWNpbmcgcHJp bmNpcGxlcywiIElFVEYgNzgNCj4+ID4+IFRlY2huaWNhbCBQbGVuYXJ5LCAyOSBKdWx5IDIwMTAN Cj4+ID4+DQo+PiA+PiBbQmF1ZXJdIFN0ZXZlbiBCYXVlciwgRGF2aWQgQ2xhcmssIFdpbGxpYW0g TGVociwgICJUaGUgRXZvbHV0aW9uIG9mDQo+PiA+PiBJbnRlcm5ldCBDb25nZXN0aW9uLCIgTWFz c2FjaHVzZXR0cyBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neSwgMjAwOQ0KPj4gPg0KPj4gPi0tDQo+ PiA+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPj4gPkRpcGwuLUluZy4gTWlyamEgS8O8aGxld2luZA0KPj4gPkluc3Rp dHV0ZSBvZiBDb21tdW5pY2F0aW9uIE5ldHdvcmtzIGFuZCBDb21wdXRlciBFbmdpbmVlcmluZyAo SUtSKQ0KPj4gPlVuaXZlcnNpdHkgb2YgU3R1dHRnYXJ0LCBHZXJtYW55DQo+PiA+UGZhZmZlbndh bGRyaW5nIDQ3LCBELTcwNTY5IFN0dXR0Z2FydA0KPj4gPg0KPj4gPnRlbDogKzQ5KDApNzExLzY4 NS02Nzk3Mw0KPj4gPmVtYWlsOiBtaXJqYS5rdWVobGV3aW5kQGlrci51bmktc3R1dHRnYXJ0LmRl DQo+PiA+d2ViOiB3d3cuaWtyLnVuaS1zdHV0dGdhcnQuZGUNCj4+ID4tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+ DQo+DQo+LS0NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+RGlwbC4tSW5nLiBNaXJqYSBLw7xobGV3aW5kDQo+SW5z dGl0dXRlIG9mIENvbW11bmljYXRpb24gTmV0d29ya3MgYW5kIENvbXB1dGVyIEVuZ2luZWVyaW5n IChJS1IpDQo+VW5pdmVyc2l0eSBvZiBTdHV0dGdhcnQsIEdlcm1hbnkNCj5QZmFmZmVud2FsZHJp bmcgNDcsIEQtNzA1NjkgU3R1dHRnYXJ0DQo+DQo+dGVsOiArNDkoMCk3MTEvNjg1LTY3OTczDQo+ ZW1haWw6IG1pcmphLmt1ZWhsZXdpbmRAaWtyLnVuaS1zdHV0dGdhcnQuZGUNCj53ZWI6IHd3dy5p a3IudW5pLXN0dXR0Z2FydC5kZQ0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K From stuart.venters@adtran.com Tue Mar 8 11:27:22 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D165B3A693A for ; Tue, 8 Mar 2011 11:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.563 X-Spam-Level: X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1nknNMEiRd8 for ; Tue, 8 Mar 2011 11:27:20 -0800 (PST) Received: from p02c12o144.mxlogic.net (p02c12o144.mxlogic.net [208.65.145.77]) by core3.amsl.com (Postfix) with ESMTP id 2E1723A6816 for ; Tue, 8 Mar 2011 11:27:19 -0800 (PST) Received: from unknown [76.164.174.81] (EHLO p02c12o144.mxlogic.net) by p02c12o144.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id 363867d4.75e68940.9468.00-523.22094.p02c12o144.mxlogic.net (envelope-from ); Tue, 08 Mar 2011 12:28:35 -0700 (MST) X-MXL-Hash: 4d7683637d1591e3-f714f59cb908ad13e7edd63967ae97058fb4199e Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c12o144.mxlogic.net(mxl_mta-6.9.0-1) over TLS secured channel with ESMTP id d53867d4.0.9429.00-335.21998.p02c12o144.mxlogic.net (envelope-from ); Tue, 08 Mar 2011 12:28:30 -0700 (MST) X-MXL-Hash: 4d76835e7ca759db-c7af3822c81b363b6172e01189fbbba890c451ca Received: from ex-mb2.corp.adtran.com ([fe80::7066:bf43:c7f9:c72b]) by ex-hc1.corp.adtran.com ([fe80::7056:fd25:cbcf:170%13]) with mapi id 14.01.0270.001; Tue, 8 Mar 2011 13:28:28 -0600 From: STUART VENTERS To: Mirja Kuehlewind Thread-Topic: [conex] Proposed Text for New Section in Use Case Draft - Statistical multiplexing over Longer Timescales Thread-Index: AQHL3YvJignlsjrUVUuZfy/q7JCoKpQjzPog Date: Tue, 8 Mar 2011 19:28:27 +0000 Message-ID: <1220E2C537595D439C5D026E837518669ED0@ex-mb2.corp.adtran.com> In-Reply-To: <201103081324.25218.mirja.kuehlewind@ikr.uni-stuttgart.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.113.98] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] X-AnalysisOut: [v=1.0 c=1 a=ruWq0YzyRmIA:10 a=QgvKihjl0BsA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=8nJEP1OIZ-IA:10 a=xqWC_Br6kY4A:10 a=0XgpNN2/4a34ym] X-AnalysisOut: [u16SVwsQ==:17 a=48vgC7mUAAAA:8 a=mYPrF8hoAAAA:8 a=1UFXjjYt] X-AnalysisOut: [AAAA:8 a=YkfkHuUEkNmHY85ripAA:9 a=wsBfq_BscW2YB-f02VAA:7 a] X-AnalysisOut: [=oKRqg0LvvKWYxEWk0gWsnhd_p4oA:4 a=wPNLvfGTeEIA:10 a=GLXgUF] X-AnalysisOut: [zA6FYA:10 a=lZB815dzVvQA:10 a=ljUrREeHiOvboU-h:21 a=hT8zED] X-AnalysisOut: [DoademnGRN:21] Cc: "conex@ietf.org" Subject: Re: [conex] Proposed Text for New Section in Use Case Draft - Statistical multiplexing over Longer Timescales X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 19:27:22 -0000 Mirja, "- First, there is no difference between having a shaper or having a limite= d access bandwidth. " A couple of possible differences are: Who sets the policies for the buffers behind the restriction. For example a customer's router might have priority queueing for specif= ic traffic heading to the cloud. A shaper may allow for bursts whereas with a physical link you just get w= hat you got. Regards, Stuart -----Original Message----- From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of M= irja Kuehlewind Sent: Tuesday, March 08, 2011 6:24 AM To: conex@ietf.org Subject: Re: [conex] Proposed Text for New Section in Use Case Draft - Stat= istical multiplexing over Longer Timescales Hi David, sorry, reading the text I really don't see the problems you are talking abo= ut: 1. self-congestion vs. inter-user congestion - First, there is no difference between having a shaper or having a limited= access bandwidth. - Second, the principle of TCP congestion control is to probe for available= bandwidth until congestion occurs. That's nothing bad because thats the on= ly feedback TCP has. And as long as you are alone on the link, the number o= f losses/marking will be very small. If you even want to avoid these conges= tion markings than you can go for something like LEDBAT which will keep the= queue small and no congestion will occur. If there is only self-congestion= its under the user's control how much congestion he/she will cause. Where'= s the problem? 2. heavy vs. light users Heavy user in general are not a problem, only heavy unresponsive user are. = And heavy unresponsive user will have a high congestion volume (whereas lig= ht or LEDBAT user will have a small congestion volume). Thus the congestion= volume given by the ConEx mechanism is the only metric needed to figure ou= t who are the bad guys! 3. congestion vs. congestion volume Somewhere your text is saying "The result is that all users see the same co= ngestion...". That's not true. The point is that a heavy unresponsive user = is seeing more losses/marking than a light user because he/she is sending w= ith a higher rate over a longer period of time. ConEx is not only giving a = notification that there has been a congestion event, ConEX is giving a cong= estion volume. And if you have dropper the ones with a high congestion volu= me will consume their allowances quickly and will be penalized by the dropp= er afterwards. Thus if you have ConEX you can have a dropper instead of the= shaper and this will actually allow you to penalize the bad guys (whereas = a shaper will penalize the heavy users, which is the wrong metric as e.g. LEDBAT user are nice guys). Mirja On Friday 04 March 2011 17:37:37 Mcdysan, David E wrote: > Hi, > > As documented in the IETF79 Beijing meeting minutes it was agreed that > the concepts from the section titled "Inequity of Heavy versus Light User= s" > from draft-mcdysan-conex-other-usecases should be included in the WG > Concepts and Use Cases draft. > > After much discussion (that ranged well beyond this topic, and spawned > several other threads that are not addressed by this proposed text), > Toby proposed adding a new section to the use case draft and I > volunteered to draft content based upon the original draft as well as > the relevant list discussion from the thread titled "Discussion of new > Use Cases pt 1," along with relevant text from the spawned threads. I > tried to list all of the people whose inputs I used to draft this text > and am requesting the use-case draft authors to include your names in > the Acknowledgement section (if it was not already there). > > The title of the proposed new section X has been changed to represent > the principal aspects of the use case, namely statistical multiplexing > over longer timescales. > > Thanks, > > Dave > ----------------------------------------------------------------- > > X. Statistical multiplexing over Longer Timescales > > In this use case the assumption is that "flat rate" or "bandwidth tier" > pricing is in place. A simplifying assumption is made that there is no > very long term (e.g., monthly) usage tier pricing in place. > > X.1 Problems Encountered in Existing Networks > > The principal problem addressed by this use case is that 20% of the > users generate 80% of the traffic volume and create unfairness with > certain resource sharing [Varian], often without paying any extra for > doing so when "flat rate" or "bandwidth tier" pricing is in effect. > The timescale over which this difference in traffic volume exists can > range from seconds, to many minutes to hours. The peak rate at which a > user can send may be set by the physical transmission system, a > non-work conserving scheduler, and/or a policer. > > The access network is usually not provisioned and traffic engineered > for the peak rate for all users but is instead provisioned assuming > statistical multiplexing where a longer term (many seconds to minutes > to hours) average capacity is assumed for all users during the busy > period. The many minutes timescale is commonly used by network > operators to determine when a portion of a network is near congestion > [section 3.3, Bauer]. During non-busy periods, the service provider > network is underutilized and hence there is no congestion of shared resou= rces. > > During busy periods where congestion (i.e., loss or ECN marking) of a > shared resource (e.g., a queue or scheduler) can occur, heavier users > may send at speeds up to the peak rate while lighter users may send at > a rate much less than the peak rate. The result is that all users see > the same congestion (i.e., loss or ECN marking probability) although > the lighter users are sending at much less than the peak rate. > Furthermore, when the shared resource is congested, heavy users create > much more congestion volume than light users. In this sense, the > response of current networks is "unfair," which is also called "economic = congestion" [section 3.4, Bauer]. > > The above situation occurs in flat rate pricing where all user flows > share the same resource (e.g., queue, scheduler). > > In many networks a non work conserving scheduler (e.g., a shaper) > implements a per-user peak rate over an interval O(100 ms). See > Appendix B of [DSL Forum TR-059] for a DSL specific example of > non-work conserving schedulers. Similar techniques are used in access > network equipment across a range of access technologies. Thus, the > "bandwidth tier" incentive is that a user pays more if he/she wants more = peak rate bandwidth. > > Such non-work conserving schedulers create apparent congestion (i.e., > loss or ECN marking) within their queue(s) which impact only a single > user that need to be considered in the set of conex use cases. Further > discussion on this topic is covered in the section "Self-Congestion > versus Inter-User Congestion." > > X.2 Conex Objectives for a Solution to this Problem > > The general objective for conex is to provide better information for a > provider to address the "unfairness" or "economic congestion" problem > described in the previous section. > > A specific objective is to achieve a "fairness" measure of bandwidth > delivered in proportion to the user peak rate when congestion of a > shared resource occurs. > > A specific objective is to distinguish heavier users from lighter > users over a the statistical multiplexing time interval that can range > from seconds, to minutes, to hours so that network provider traffic > management functions can provide "fairer" allocation of bandwidth. > > A desirable objective is to distinguish between "self-congestion" and > "inter-user congestion" so that users could use a mechanism external > to conex to "go faster" in the event that only "self-congestion" is > limiting their throughput. > > X.2 Self-Congestion versus Inter-User Congestion > > If the user sends at more than the shaper peak rate and there is no > congestion at a shared resource, then other users are not impacted, > and in a sense this user creates "self-congestion." There is also the > case when congestion occurs at a shared resource, which causes > "inter-user-congestion," where congestion volume from one user impacts > other users. Note that "Self-Congestion" can occur when "Inter-User > Congestion" occurs. However, a heavier user may not create > "self-congestion" (i.e., loss or ECN marking) if that user sends at > slightly less than a shaper peak rate (e.g., using LEDBAT). > > There are (at least) three approaches for addressing this issue. > Approaches 1, 2.a require no change to the conex abstract mechanism > [wg-abstract-mechanism]. Approach 2.b would require signaling of > additional information to the receiver (could be done separately from > conex), and approach 3 may be able to use the conex abstract > mechanism, albeit potentially in a different configuration. > > 1. Treat "self-congestion" the same as "inter-user congestion" since > they both create congestion as perceived by the flow user. > > 2. Signal more information to the receiver about the cause of loss > since the remedy differs: > a. For a shared queue, use current draft of abstract mechanism > signals to reduce load and choose packets for different treatments. > b. For a queue dedicated to a receiver (e.g., shaper) signal > information that the shaper peak rate is the bottleneck to the > receiver, so that somehow (specific mechanism may not fit within the > current conex wg > charter) the user could make a request to "go faster." > > 3. Process and generate conex information at the network element which > implements the shaper, which has knowledge of the configured peak > rates for the users as well as local shared resource congestion. This > network element can also use information about upstream shared > resource congestion as delivered buy the conex protocol. > > Note that during busy periods "self congestion" may not be the > limiting factor, but during non-busy periods it will be the biggest > source of apparent congestion. > > X.3 Potential Support Using Abstract Mechanism > > [Editorial Note from Dave: The following was derived list comments as > well as a private input from Toby Moncaster.] > > The following scenario assumes that all user flows implement conex. > The case where not all flows implement conex still needs to be > addressed. (Some form of localized "conex-like" marking may handle > this case, since heavier users may have a significant incentive to not > implement conex). Also to be addressed is the scenario where heavy > users do not create congestion (e.g., using LEDBAT), but there is > still a significant difference in average rate, or burstiness (peak/avera= ge). > > Using the abstract mechanism a heavier user never gets a chance to > build up any congestion credit, which will not impact their service > during non-busy periods. However, at peak times it means their service > is degraded long before a light user sees any impact. In turn this > means the congestion seen by the light user is less, meeting an important= objective. > > Additional local computations are done as follows. Over a time period > related to the statistical multiplexing interval (e.g., many seconds > to minutes to hours) total up the number of bytes that have been > congestion marked and the total number of bytes sent per user. Compute > the ratio of congested bytes to total bytes. > > The total is a measure of the average rate per user (averaged over the > time period of the total). > > For example, quantizing users into classes using one threshold on > total and and another threshold on ratio results in a grid that > identifies four distinct classes of user as follows: > > +----------------+-------------+-------------+ > > | Total volume>| | | > |v Ratio | Large | Small | > > +----------------+-------------+-------------+ > > | High | Heavy User | Bursty User | > > +----------------+-------------+-------------+ > > | Low | LEDBAT User | Light User | > > +----------------+-------------+-------------+ > > X.4 Additional Support Using other Measures and Mechanisms > > An additional congestion measure of burstiness (e.g., ratio of peak > rate to average rate over a longer interval than the tiered bandwidth > shaper) would allow nodes upstream from the node implementing the > shaper to implement traffic management. This measure could be derived > from signals in the abstract mechanism but would require (a majority) > of the heavier senders and receivers to implement conex and also would > only work if loss or ECN marking occurs. Heavier users may have a > significant incentive to not implement conex, and some additional > mechanism to address this issue may be required. Also, signaling a > measure of the burstiness (or something related to it) would address the = scenario where no loss or ECN marking occurs. > > As an alternative, if a "light weight" TCP proxy were implemented at > the network element containing the shaper (e.g., an access router) and > an upstream network element (e.g., a router at ingress to the service > provider network), then potentially a conex control loop could be > created between these network elements to provide fairer treatment > between heavier and lighter users during congested intervals. In this > case, a subset of conex features could potentially be used since this > would be a closed domain where the signals could be implicitly > trusted. The burstiness measure could be communicated using TCP extension= s between these proxies. > > There is also the aspect of "self congestion" when a non-work > conserving scheduler (e.g., shaper) is employed at the access node. > Even when "inter-user congestion" is not occurring (e.g., during a > non-busy period), "self congestion" may occur. However, as discussed > in the section on "Self Congestion versus Inter-User Congestion," > using current mechanisms (i.e., implicitly determined loss or ECN > marking) the receiver cannot tell the difference between > "self-congestion" and "inter-user congestion." Adding a signal to the > abstract mechanism could be quite useful so that a receiver can inform > the sender regarding the cause of congestion, and enable the sender > (or the receiver) to communicate with the network element controlling > the shaper parameters enabling the flow to "go faster." using some non-co= nex mechanism. > > > --------------------- > > [Editorial Note: Please add the following] > > Acknowledgements > > Add the following: Stuart Venters, Mikael Abrahamsson, Mirja > Kuehlewind, Jo=E3o Taveira Ara=FAjo, Caitlin Bestler, Steven Bauer, ... > > [Editorial Note: My thanks for inputs from authors, folks already > listed in > Acknowledgements: Toby Moncaster, John Leslie, Alissa Cooper, Rich > Woundy, ...] > > References > > [DSL Forum TR-059] Technical Report DSL Forum TR-059, "DSL Evolution - > Architecture Requirements for the Support of QoS-Enabled IP Services," > September 2003, > http://www.broadband-forum.org/technical/download/TR-059.pdf > > [Varian] Hal Varian, Google, "Congestion pricing principles," IETF 78 > Technical Plenary, 29 July 2010 > > [Bauer] Steven Bauer, David Clark, William Lehr, "The Evolution of > Internet Congestion," Massachusetts Institute of Technology, 2009 -- ------------------------------------------------------------------- Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) Universi= ty of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de ------------------------------------------------------------------- _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex From bob.briscoe@bt.com Wed Mar 9 03:29:12 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A8713A6936 for ; Wed, 9 Mar 2011 03:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DK4EuYYFmLuP for ; Wed, 9 Mar 2011 03:29:08 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 3014A3A6948 for ; Wed, 9 Mar 2011 03:29:07 -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); Wed, 9 Mar 2011 11:30:23 +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); Wed, 9 Mar 2011 11:30:22 +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 1299670222226; Wed, 9 Mar 2011 11:30:22 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.131.97]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p29BUKtp025393; Wed, 9 Mar 2011 11:30:21 GMT Message-Id: <201103091130.p29BUKtp025393@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 09 Mar 2011 11:30:25 +0000 To: Caitlin Bestler From: Bob Briscoe In-Reply-To: References: <2F246B0F-0AD2-463B-9C3D-E17F3709FC76@nokia.com> <003b01cbceaa$f85540d0$e8ffc270$@com> <34EEDAE3-A7CF-413C-9182-A13608473622@asomi.com> <20110217180411.GK86652@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: 09 Mar 2011 11:30:22.0799 (UTC) FILETIME=[60CB85F0:01CBDE4D] Cc: conex@ietf.org Subject: [conex] More precision than 1 bit ECN (was: Re: WG energy) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 11:29:12 -0000 Caitlin, Still catching up on parts of past threads... At 04:41 23/02/2011, Caitlin Bestler wrote: >On Feb 17, 2011, at 10:04 AM, John Leslie wrote: > > > Caitlin Bestler wrote: >The other area where convergence would be useful is coming up with >an abstract way to report "congestion >detected" with more precision than just an ECN bit, so that L4 can >utilize this information wihtout having to >learn the specifics of L2 congestion control protocols. This as relevant to tsvwg & iccrg as to ConEx, but I'll keep it to ConEx for now... Matt Mathis taught me something important in respect of how many bits you need per frame/packet for congestion control. The critical metric is the amount of signalling information per *window*, not per packet/frame. You can maintain the same amount of signalling information per window with just 1 bit per packet as long as the congestion control keeps the packet rate proportional to 1/p, where p is the marking probability. Intuition: with a window of 100 frames, if the marking probability is 1% you will get one mark per round trip. If when the marking probability reduces /100 to 0.01% you speed up x100 to 10,000 frames per window, you will still get one mark per RTT. So you will still have the same rate of control information per time. See slide 8 of this Anaheim ICCRG presentation jointly from Matt & I: DCTCP, Relentless TCP and Scalable TCP all aim for 1/p (this is why Scalable TCP was called scalable). TCP NewReno's window is proportional to 1/sqrt(p), but more modern algorithms like these are moving closer to 1/p. Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From dave.mcdysan@verizon.com Wed Mar 9 08:57:07 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97FA13A6881 for ; Wed, 9 Mar 2011 08:57:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJ0ppcqZxUzr for ; Wed, 9 Mar 2011 08:57:05 -0800 (PST) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id 58BBC3A6A6D for ; Wed, 9 Mar 2011 08:56:57 -0800 (PST) Received: from fldsmtpi02.verizon.com (fldsmtpi02.verizon.com [166.68.71.144]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p29GvlAv010294 for ; Wed, 9 Mar 2011 11:58:04 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,291,1297036800"; d="scan'208,217";a="8330219" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi02.verizon.com with ESMTP; 09 Mar 2011 16:57:46 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.240]) by FHDP1LUMXC7HB04.us.one.verizon.com ([2002:a644:3bbf::a644:3bbf]) with mapi; Wed, 9 Mar 2011 11:57:46 -0500 To: "conex@ietf.org" Date: Wed, 9 Mar 2011 11:57:43 -0500 Thread-Topic: References on Heavy Internet Users Thread-Index: Acveex0TK4zAlPPsSdOg7fWQbS+JRA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C99D16AA10A6Ddavemcdysanoneverizoncom_" MIME-Version: 1.0 Subject: [conex] References on Heavy Internet Users X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 16:57:07 -0000 --_000_C99D16AA10A6Ddavemcdysanoneverizoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The following are references on heavy internet user that may help better d= efine (part of) the problem statement for the new section on "Statistical M= ultiplexing over Longer Time Scales" http://www.alcatel-lucent.com/solutions/itm/index.html Click on Intelligent Traffic Management Application Note and look at sectio= n 4.3. This paper also describes a specific solution, and I am only referri= ng to it since it has an example of the cited statistics. 10% of the users are heavy and consume 60% of the bandwidth in Canada http:= //www.winnipegfreepress.com/canada/breakingnews/giant-telecoms-stick-to-gun= s-on-charging-heavy-internet-users-more-115776954.html Some definitions on "Bandwidth Cap" (aka shaping), statistical multiplexing= , usage caps, dynamic setting of bandwidth caps and more on Canadian reacti= ons: http://en.wikipedia.org/wiki/Bandwidth_cap I used Google and searched on "heavy internet user" and "problem" or "fair= ness" and you will find many announcements by service providers and reactio= ns by users. Also, you will find interesting analyses on the demographic, p= sychological and social implications of heavy internet usage, which is prob= lem that I am NOT proposing that conex strive to solve. :-) In a similar but related thread, usage caps have been employed by many ISPs= to target heavy users, but these have a separate set of issues and challen= ges. Thanks, Dave --_000_C99D16AA10A6Ddavemcdysanoneverizoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The following are refere= nces on heavy internet user  that may help better define (part of) the= problem statement for the new section on "Statistical Multiplexing over Lo= nger Time Scales"


Click on In= telligent Traffic Management Application Note and look at sectio= n 4.3. This paper also describes a specific solution, and I am only referri= ng to it since it has an example of the cited statistics.
Some definitions on "Bandwidth Cap" (aka shaping), stati= stical multiplexing, usage caps, dynamic setting of bandwidth caps and more= on Canadian reactions:


I used Google and searched on "heavy internet use= r" and "problem" or  "fairness" and you will find many announcements b= y service providers and reactions by users. Also, you will find interesting= analyses on the demographic, psychological and social implications of heav= y internet usage, which is problem that I am NOT proposing that conex striv= e to solve. :-)

In a similar but related thread, u= sage caps have been employed by many ISPs to target heavy users, but these = have a separate set of issues and challenges. 

Thanks,

Dave
--_000_C99D16AA10A6Ddavemcdysanoneverizoncom_-- From bob.briscoe@bt.com Wed Mar 9 16:00:21 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDE023A6B07 for ; Wed, 9 Mar 2011 16:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.366 X-Spam-Level: X-Spam-Status: No, score=-3.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtxwTc51Ch-7 for ; Wed, 9 Mar 2011 16:00:21 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 8060C3A67D9 for ; Wed, 9 Mar 2011 16:00:19 -0800 (PST) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Mar 2011 00:01:34 +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, 10 Mar 2011 00:01:34 +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 1299715292908; Thu, 10 Mar 2011 00:01:32 +0000 Received: from MUT.jungle.bt.co.uk ([10.142.64.9]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p2A01SAt027569; Thu, 10 Mar 2011 00:01:29 GMT Message-Id: <201103100001.p2A01SAt027569@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 10 Mar 2011 00:00:12 +0000 To: Marcelo BAGNULO BRAUN , Nandita Dukkipati 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: 10 Mar 2011 00:01:34.0619 (UTC) FILETIME=[51B176B0:01CBDEB6] Cc: ConEx IETF list Subject: [conex] draft-ietf-conex-abstract-mech-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 10 Mar 2011 00:00:21 -0000 Marcelo, Nandita, list FYI, draft-ietf...-00 is broadly the same text as draft-mathis...-00 Just a change of filename, date etc. We're working on updates to the text right now for -01 by Monday: Things on our list to add: * make Fig 1 ASCII art better, which is critical for understanding * rationale for credit signal (promised in Beijing after requested by Mirja on list & others) * normative text on the audit device (also promised in Beijing) * A few things that ConEx is not (will address some of Nandita's review comments about ConEx generally when the w-g first started, and also suggested by Caitlin Bestler off list) Any other suggestions? Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From nanditad@google.com Thu Mar 10 00:22:20 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C18D33A683B for ; Thu, 10 Mar 2011 00:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mSgKs6NmQnY for ; Thu, 10 Mar 2011 00:22:20 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id A14733A6875 for ; Thu, 10 Mar 2011 00:22:18 -0800 (PST) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p2A8NYEl009864 for ; Thu, 10 Mar 2011 00:23:34 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299745414; bh=bO+qfgSxhIfnET1dZcIdl8fUQ6o=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=I68ANz+osxUfqfKTjLXNMiXDw1kdHIC24pppOI35aEbDI4LMPaTCpfVuaF2MxOXDl c9tyoMFOAEakYDt6WlKNQ== Received: from yia25 (yia25.prod.google.com [10.243.65.25]) by hpaq7.eem.corp.google.com with ESMTP id p2A8NWG5006851 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 10 Mar 2011 00:23:33 -0800 Received: by yia25 with SMTP id 25so638189yia.12 for ; Thu, 10 Mar 2011 00:23:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FDRsM+GodCOU/ZCDivSoms4XmJOoiiIMGSGfVXD8hvs=; b=ut0GWE7x7x0f7ppTnwHjxEJka8xZ0LbhwG7NswX06xrCvhSax5OVPr1Fii4G+l5eHQ qMXHzBUxMoadVJ/9lEgQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gKJD/RXjpJL94ff4EiF9lGx6hztA83sFBHWUy/yNmhN1U37unn6Zb5FkSnGg6M3cpY o/DyVGSKRM+wYAzqoMWA== MIME-Version: 1.0 Received: by 10.150.14.15 with SMTP id 15mr701641ybn.70.1299745412094; Thu, 10 Mar 2011 00:23:32 -0800 (PST) Received: by 10.90.63.2 with HTTP; Thu, 10 Mar 2011 00:23:32 -0800 (PST) In-Reply-To: <201103100001.p2A01SAt027569@bagheera.jungle.bt.co.uk> References: <201103100001.p2A01SAt027569@bagheera.jungle.bt.co.uk> Date: Thu, 10 Mar 2011 00:23:32 -0800 Message-ID: From: Nandita Dukkipati To: Bob Briscoe Content-Type: multipart/alternative; boundary=000e0cd760d696197e049e1c8ffa X-System-Of-Record: true Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-abstract-mech-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 10 Mar 2011 08:22:20 -0000 --000e0cd760d696197e049e1c8ffa Content-Type: text/plain; charset=ISO-8859-1 Bob, Matt, Things on our list to add: > * make Fig 1 ASCII art better, which is critical for understanding > * rationale for credit signal (promised in Beijing after requested by Mirja > on list & others) > > * normative text on the audit device (also promised in Beijing) So, one of the points from Beijing notes was that the content of App. A (ConEx architectural elements) from draft-moncaster-conex-concepts-uses-02 will be included into the mechanisms draft. Is that what you mean in the above point? -Nandita --000e0cd760d696197e049e1c8ffa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bob, Matt,

* normative text on the audit device (also promised in Beijing)
=A0
So, one of the points from= Beijing notes was that the content of App. A (ConEx architectural elements= ) from draft-moncaster-conex-concepts-uses-02 will be included into the mec= hanisms draft. Is that what you mean in the above point?
=A0
-Nandita
--000e0cd760d696197e049e1c8ffa-- From bob.briscoe@bt.com Thu Mar 10 03:10:47 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EAE23A68DE for ; Thu, 10 Mar 2011 03:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.389 X-Spam-Level: X-Spam-Status: No, score=-3.389 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRaptJjwgT+h for ; Thu, 10 Mar 2011 03:10:45 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 518733A68E9 for ; Thu, 10 Mar 2011 03:10:44 -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); Thu, 10 Mar 2011 11:12:01 +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, 10 Mar 2011 11:12:01 +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 1299755519821; Thu, 10 Mar 2011 11:11:59 +0000 Received: from MUT.jungle.bt.co.uk ([10.142.67.238]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p2ABBw8f029651; Thu, 10 Mar 2011 11:11:58 GMT Message-Id: <201103101111.p2ABBw8f029651@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 10 Mar 2011 11:11:46 +0000 To: Nandita Dukkipati From: Bob Briscoe In-Reply-To: References: <201103100001.p2A01SAt027569@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_599837690==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 10 Mar 2011 11:12:01.0288 (UTC) FILETIME=[FAA80880:01CBDF13] Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-abstract-mech-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 10 Mar 2011 11:10:47 -0000 --=====================_599837690==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Nandita, 2 out of 3 aspects of that appx are largely already in conex-abstract-mech. The third brings out an awkward problem with the split between docs... 1/ abstract-mech has the separation of policing into monitoring and policing - but we ought to bring out this distinction in the section heading s/Other Policy Devices/Policy Monitoring Devices/ and switch round sections 4.4.2 & 4.4.1 with suitable adjustment of text. 2/ There's a 'ToDo' already in conex-abstract-mech to include a diagram like the one in the conex-concepts-uses slidesets (based on Fig 1 in conex-concepts-uses appxA) to show function placement This ought to have some textual discussion of function placement around it as well. 3/ However,... This leaves the question of where we have discussion of partial deployment scenarios. To me the obvious doc for that is concepts-uses, which is where use-cases are. abstract-mech is primarily about components. I had to rely on the notes from Beijing, because the audio didn't come through until later in the session (I had to rush home from Beijing before the session for a family matter). The notes record agreement to remove Appx A from concepts-uses, describing it as "mechanism". But I didn't think of the detailed implications of moving the whole of appx A of concepts-uses to abstract-mech. What I do know is that concepts-uses has to go through the IESG first, and if it doesn't address the issue of partial deployment itself, it won't get through. I don't think it will be acceptable to the IESG to refer off to another doc for partial deployment (Section 5.5. Partial vs. Full Deployment is too high level IMO). I propose that concepts-uses should still be the place for discussion of partial deployment scenarios. Yes, it should refer to abstract-mech for what the components are. But then it should talk about how they would work in a partial deployment scenario (which was in the original Appx A as well). It's unfortunate we've noticed this at such a late stage, but I'm glad you did notice it. Bob ============================================================================== PS. For convenience, I have pasted the headings of the relevant sections from each doc below: draft-moncaster-conex-concepts-uses-02 had: Appendix A. ConEx Architectural Elements . . . . . . . . . . . . 20 A.1. ConEx Monitoring . . . . . . . . . . . . . . . . . . . . . 20 A.1.1. Edge Monitoring . . . . . . . . . . . . . . . . . . . 21 A.1.2. Border Monitoring . . . . . . . . . . . . . . . . . . 22 A.2. ConEx Policing . . . . . . . . . . . . . . . . . . . . . . 22 A.2.1. Egress Policing . . . . . . . . . . . . . . . . . . . 23 A.2.2. Ingress Policing . . . . . . . . . . . . . . . . . . . 24 A.2.3. Border Policing . . . . . . . . . . . . . . . . . . . 25 draft-ietf-conex-abstract-mech-00 has: 4. Congestion Exposure Components . . . . . . . . . . . . . . . . 10 4.1. Modified Senders . . . . . . . . . . . . . . . . . . . . . 10 4.2. Receivers (Optionally Modified) . . . . . . . . . . . . . 10 4.3. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. Policy Devices . . . . . . . . . . . . . . . . . . . . . . 11 4.4.1. Congestion Policers . . . . . . . . . . . . . . . . . 12 4.4.2. Other Policy Devices . . . . . . . . . . . . . . . . . 12 Bob At 08:23 10/03/2011, Nandita Dukkipati wrote: >Bob, Matt, > >Things on our list to add: >* make Fig 1 ASCII art better, which is critical for understanding >* rationale for credit signal (promised in Beijing after requested >by Mirja on list & others) > > >* normative text on the audit device (also promised in Beijing) > > >So, one of the points from Beijing notes was that the content of >App. A (ConEx architectural elements) from >draft-moncaster-conex-concepts-uses-02 will be included into the >mechanisms draft. Is that what you mean in the above point? > >-Nandita >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design --=====================_599837690==.ALT Content-Type: text/html; charset="us-ascii" Nandita,

2 out of 3 aspects of that appx are largely already in conex-abstract-mech. The third brings out an awkward problem with the split between docs...

1/ abstract-mech has the separation of policing into monitoring and policing
  - but we ought to bring out this distinction in the section heading
    s/Other Policy Devices/Policy Monitoring Devices/
    and switch round sections 4.4.2 & 4.4.1 with suitable adjustment of text.

2/ There's a 'ToDo' already in conex-abstract-mech to include a diagram like the one in the conex-concepts-uses slidesets (based on Fig 1 in conex-concepts-uses appxA) to show function placement This ought to have some textual discussion of function placement around it as well.

3/ However,...
This leaves the question of where we have discussion of partial deployment scenarios. To me the obvious doc for that is concepts-uses, which is where use-cases are. abstract-mech is primarily about components.

I had to rely on the notes from Beijing, because the audio didn't come through until later in the session (I had to rush home from Beijing before the session for a family matter).

The notes record agreement to remove Appx A from concepts-uses, describing it as "mechanism". But I didn't think of the detailed implications of moving the whole of appx A of concepts-uses to abstract-mech.

What I do know is that concepts-uses has to go through the IESG first, and if it doesn't address the issue of partial deployment itself, it won't get through. I don't think it will be acceptable to the IESG to refer off to another doc for partial deployment (Section 5.5.  Partial vs. Full Deployment is too high level IMO).

I propose that concepts-uses should still be the place for discussion of partial deployment scenarios. Yes, it should refer to abstract-mech for what the components are. But then it should talk about how they would work in a partial deployment scenario (which was in the original Appx A as well).


It's unfortunate we've noticed this at such a late stage, but I'm glad you did notice it.


Bob


==============================================================================
PS. For convenience, I have pasted the headings of the relevant sections from each doc below:

draft-moncaster-conex-concepts-uses-02 had:

   Appendix A.  ConEx Architectural Elements  . . . . . . . . . . . . 20
     A.1.  ConEx Monitoring . . . . . . . . . . . . . . . . . . . . . 20
       A.1.1.  Edge Monitoring  . . . . . . . . . . . . . . . . . . . 21
       A.1.2.  Border Monitoring  . . . . . . . . . . . . . . . . . . 22
     A.2.  ConEx Policing . . . . . . . . . . . . . . . . . . . . . . 22
       A.2.1.  Egress Policing  . . . . . . . . . . . . . . . . . . . 23
       A.2.2.  Ingress Policing . . . . . . . . . . . . . . . . . . . 24
       A.2.3.  Border Policing  . . . . . . . . . . . . . . . . . . . 25

draft-ietf-conex-abstract-mech-00 has:

   4.  Congestion Exposure Components . . . . . . . . . . . . . . . . 10
     4.1.  Modified Senders . . . . . . . . . . . . . . . . . . . . . 10
     4.2.  Receivers (Optionally Modified)  . . . . . . . . . . . . . 10
     4.3.  Audit  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.4.  Policy Devices . . . . . . . . . . . . . . . . . . . . . . 11
       4.4.1.  Congestion Policers  . . . . . . . . . . . . . . . . . 12
       4.4.2.  Other Policy Devices . . . . . . . . . . . . . . . . . 12


Bob

At 08:23 10/03/2011, Nandita Dukkipati wrote:
Bob, Matt,

Things on our list to add:
* make Fig 1 ASCII art better, which is critical for understanding
* rationale for credit signal (promised in Beijing after requested by Mirja on list & others)

 
* normative text on the audit device (also promised in Beijing)

 
So, one of the points from Beijing notes was that the content of App. A (ConEx architectural elements) from draft-moncaster-conex-concepts-uses-02 will be included into the mechanisms draft. Is that what you mean in the above point?
 
-Nandita
_______________________________________________
conex mailing list
conex@ietf.org
https://www.ietf.org/mailman/listinfo/conex

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design --=====================_599837690==.ALT-- From dave.mcdysan@verizon.com Thu Mar 10 06:34:54 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE08B3A69D3 for ; Thu, 10 Mar 2011 06:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.49 X-Spam-Level: X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1oMyK-Ynlxq for ; Thu, 10 Mar 2011 06:34:53 -0800 (PST) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id 5069D3A69E1 for ; Thu, 10 Mar 2011 06:34:50 -0800 (PST) Received: from fldsmtpi02.verizon.com (fldsmtpi02.verizon.com [166.68.71.144]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p2AEa3nK000191 for ; Thu, 10 Mar 2011 09:36:08 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,295,1297036800"; d="scan'208";a="8952361" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi02.verizon.com with ESMTP; 10 Mar 2011 14:36:03 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.240]) by FHDP1LUMXC7HB02.us.one.verizon.com ([2002:a644:3bbd::a644:3bbd]) with mapi; Thu, 10 Mar 2011 09:36:02 -0500 To: Mirja Kuehlewind , "conex@ietf.org" Date: Thu, 10 Mar 2011 09:36:00 -0500 Thread-Topic: [conex] Proposed Text for New Section in Use Case Draft - Statistical multiplexing over Longer Timescales Thread-Index: AcvfMHppZrsLAZRfRF+fplujlbE9qA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [conex] Proposed Text for New Section in Use Case Draft - Statistical multiplexing over Longer Timescales X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 10 Mar 2011 14:34:54 -0000 Hi Mirja, I was thinking about your comment below after looking for references on the "heavy user" problem and think there are at least two smaller problems. 1) A few "heavy" users generate most of the traffic and service providers want to better assign the cost (of provisioning an upgrade) for the time when congestion is anticipated to occur. Existing mechanisms, flat rate, bandwidth tier shapers, and usage tiers do not completely address the service provider objective and/or are not popular with users. 2) In some service provider networks shapers are implemented to limit the maximum bandwidth per user. Although overflow or marking in the shaper queue appears as congestion to the receiver, this "self-congestion" differs from congestion of a shared resource since a remedy could be to indicate to the user that changing the shaper rate (i.e., "go faster") would alleviate "self-congestion." I know that John had concerns regarding the length of the text and splitting it along the above lines would make understanding and discussion easier. I think that the text I submitted can be split into two along the above lines. Thanks, Dave >On 3/8/11 12:16 PM, "Mirja Kuehlewind" > wrote: >> >>I have the feeling that in the text you provided, there are several >>points >>mixed up. Maybe we can try to separate them again in smaller parts...? > From Internet-Drafts@ietf.org Thu Mar 10 14:45:02 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E0503A6920; Thu, 10 Mar 2011 14:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7k9KE8I792G; Thu, 10 Mar 2011 14:45:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA69D3A6407; Thu, 10 Mar 2011 14:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110310224501.6639.3405.idtracker@localhost> Date: Thu, 10 Mar 2011 14:45:01 -0800 Cc: conex@ietf.org Subject: [conex] I-D ACTION:draft-ietf-conex-abstract-mech-00.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 10 Mar 2011 22:45:02 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion Exposure Working Group of the IETF. Title : Congestion Exposure (ConEx) Concepts and Abstract Mechanism Author(s) : M. Mathis, et al Filename : draft-ietf-conex-abstract-mech-00.txt Pages : 15 Date : 2011-03-10 This document describes an abstract mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. Today, the network may signal congestion to the receiver by ECN markings or by dropping packets, and the receiver may pass this information back to the sender in transport-layer feedback. The mechanism to be developed by the ConEx WG will enable the sender to also relay this congestion information back into the network in- band at the IP layer, such that the total level of congestion is visible to all IP devices along the path, from where it could, for example, be provided as input to traffic management. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-conex-abstract-mech-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-conex-abstract-mech-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-10143021.I-D@ietf.org> --NextPart-- From mirja.kuehlewind@ikr.uni-stuttgart.de Fri Mar 11 05:29:40 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EBDE3A690F for ; Fri, 11 Mar 2011 05:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGMqKsV3xXSj for ; Fri, 11 Mar 2011 05:29:39 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id ECB223A6893 for ; Fri, 11 Mar 2011 05:29:38 -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 5C895633B8; Fri, 11 Mar 2011 14:30: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 4ABF759A8A; Fri, 11 Mar 2011 14:30:56 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: "Mcdysan, David E" Date: Fri, 11 Mar 2011 14:30:54 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20090731.1005176) References: 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: <201103111430.55082.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: "conex@ietf.org" Subject: Re: [conex] Proposed Text for New Section in Use Case Draft - Statistical multiplexing over Longer Timescales X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 11 Mar 2011 13:29:40 -0000 Hi Dave, thanks a lot. This makes the points much clearer.=20 I believe that point 1) is already addressed in 5.1. ConEx as a basis for=20 traffic management: "... In order to ensure all customers get some chance to access the network, the "heaviest" customers will be subjected to some form of traffic management at peak times (typically a rate cap for certain types of traffic) [Fair-use]. Often this traffic management is done with expensive flow aware devices such as DPI boxes or flow-aware routers. ConEx offers a better approach that will actually target the users that are causing the congestion..." Your point 2), for me, still looks like an mechanism on top of ConEx and th= us=20 it might be out of scope. Can you phrase based on this use case any new=20 requirements for the abstract mechanism design? Mirja On Thursday 10 March 2011 15:36:00 Mcdysan, David E wrote: > Hi Mirja, > > I was thinking about your comment below after looking for references on > the "heavy user" problem and think there are at least two smaller problem= s. > > 1) A few "heavy" users generate most of the traffic and service providers > want to better assign the cost (of provisioning an upgrade) for the time > when congestion is anticipated to occur. Existing mechanisms, flat rate, > bandwidth tier shapers, and usage tiers do not completely address the > service provider objective and/or are not popular with users. > > 2) In some service provider networks shapers are implemented to limit the > maximum bandwidth per user. Although overflow or marking in the shaper > queue appears as congestion to the receiver, this "self-congestion" > differs from congestion of a shared resource since a remedy could be to > indicate to the user that changing the shaper rate (i.e., "go faster") > would alleviate "self-congestion." > > I know that John had concerns regarding the length of the text and > splitting it along the above lines would make understanding and discussion > easier. I think that the text I submitted can be split into two along the > above lines. > > Thanks, > > Dave > > >On 3/8/11 12:16 PM, "Mirja Kuehlewind" > > > > wrote: > >>I have the feeling that in the text you provided, there are several > >>points > >>mixed up. Maybe we can try to separate them again in smaller parts...? =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 Dirk.Kutscher@neclab.eu Fri Mar 11 06:57:41 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 221353A6917 for ; Fri, 11 Mar 2011 06:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29ZstkygWHCF for ; Fri, 11 Mar 2011 06:57:39 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id F067C3A6863 for ; Fri, 11 Mar 2011 06:57:38 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 8F8392C000205; Fri, 11 Mar 2011 16:00:37 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsTvYIRTmdf7; Fri, 11 Mar 2011 16:00:37 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.neclab.eu (Postfix) with ESMTP id 744592C0001DE; Fri, 11 Mar 2011 16:00:27 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.136]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Fri, 11 Mar 2011 15:58:47 +0100 From: Dirk Kutscher To: Mikael Abrahamsson Thread-Topic: [conex] Mobile Communication Congestion Exposure Scenario Thread-Index: AcvdjCeCqk9Wtvl3QaOPfugwKgKhywACNmuAAJjk6lA= Date: Fri, 11 Mar 2011 14:58:46 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F524905AF2951@DAPHNIS.office.hd> References: <82AB329A76E2484D934BBCA77E9F524905AEFA73@DAPHNIS.office.hd> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.105] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] Mobile Communication Congestion Exposure Scenario X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 11 Mar 2011 14:57:41 -0000 Mikael, Thanks for the feedback. Some replies inside. > In 3.1 it says that DPI is desireable because of increased traffic > volume. >=20 > DPI in itself doesn't help with traffic volume but can identify > different > traffic types that can then be acted on. I think the text should > reflect > this. DPI is identification, not action. Yes, I agree. We are planning to add more on the overall policing framework= . =20 > 3.2 >=20 > The scenario described in the first paragraph has already happened, at > least where I am. Yes, same here. ;-) We found it useful to re-state this explicitly -- based on experience in di= scussing capacity sharing ideas in other communities. =20 > Regarding the last paragraph, I'd say it'd work best if there was some > kind of intelligent scheduling within the single bearer (which is the > most > common deployment for "mobile broadband"), instead of the currently > used > FIFO. This needs to be done at congestion points along the path, for > instance egress at the base station. Right -- I would see this as an implementation-specific optimization -- dif= ferent vendors would be able to have their specific clever scheduling. =20 > 4.2 >=20 > There is talk about policers here. Do you really mean policing or do > you > mean delying traffic by use of buffering + tail drop when a certain > length > is exceeded? I've seen both done in EPC depending on vendor. This whole section 4 is really trying to explore how the congestion exposur= e concept and entities such as congestion-contribution-aware policers could= be applied to the EPS. There are of course many different options, and we = have some further ideas on this. For this draft, we wanted to provide a gen= tle introduction to the idea and point at things that would potentially req= uire changes as well. =20 > 5. >=20 > Doesn't the whole system already provide fairness by means of > scheduling > radio and other resources according to user profiles? The whole > argument > of "lots of TCP sessions using a lot of data than the single TCP > session > interactive content one" doesn't apply here since all users are in a > single bearer anyway? >=20 > Conclusion: >=20 > In my mind, a mobile network is NOT ideal to deploy CONEX in, because > it > already has a lot of the fairness mechanisms already in it. A users > total > traffic is in a single bearer and users are differentiated on bearers, > not > what's in the bearers exactly. If this works as advertised, resources > are > already fairly distributed between users of the same traffic profile. I guess that's the crucial point of the discussion: whether we can do bette= r than bearer-separation-based fairness. One important aspect to keep in mind is that congestion exposure is not nec= essarily about fairness. We are interested in economical resource usage, in= centivizing scavenger transport (perhaps within a single user bearer) to pr= ovide better performance (lower latency) to more important applications etc= . It is most likely possible to extend the existing resource management mecha= nisms to do that, but the interesting question is whether congestion exposu= re can actually be a simpler solution. Best regards, Dirk =20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From dave.mcdysan@verizon.com Fri Mar 11 08:47:13 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E8FE3A6B0B for ; Fri, 11 Mar 2011 08:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.494 X-Spam-Level: X-Spam-Status: No, score=-3.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJpFZoVCErNW for ; Fri, 11 Mar 2011 08:47:12 -0800 (PST) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id 6EE873A6B1A for ; Fri, 11 Mar 2011 08:47:04 -0800 (PST) Received: from fldsmtpi03.verizon.com (fldsmtpi03.verizon.com [166.68.71.145]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p2BGm8Ad014832 for ; Fri, 11 Mar 2011 11:48:13 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,304,1297036800"; d="scan'208";a="9772937" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi03.verizon.com with ESMTP; 11 Mar 2011 16:48:08 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.240]) by FHDP1LUMXC7HB01.us.one.verizon.com ([2002:a644:3bbc::a644:3bbc]) with mapi; Fri, 11 Mar 2011 11:48:08 -0500 To: Mirja Kuehlewind Date: Fri, 11 Mar 2011 11:48:04 -0500 Thread-Topic: [conex] Proposed Text for New Section in Use Case Draft - Statistical multiplexing over Longer Timescales Thread-Index: AcvgDBji8x11AFBISRW2jczj2Pn2QA== Message-ID: In-Reply-To: <201103111430.55082.mirja.kuehlewind@ikr.uni-stuttgart.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] Proposed Text for New Section in Use Case Draft - Statistical multiplexing over Longer Timescales X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 11 Mar 2011 16:47:13 -0000 Hi Mirja, Some responses in line below. Dave On 3/11/11 8:30 AM, "Mirja Kuehlewind" wrote: >Hi Dave, > >thanks a lot. This makes the points much clearer. > >I believe that point 1) is already addressed in 5.1. ConEx as a basis for >traffic management: > > "... In order to ensure all > customers get some chance to access the network, the "heaviest" > customers will be subjected to some form of traffic management at > peak times (typically a rate cap for certain types of traffic) > [Fair-use]. Often this traffic management is done with expensive > flow aware devices such as DPI boxes or flow-aware routers. > > ConEx offers a better approach that will actually target the users > that are causing the congestion..." I would say partially addressed, the actual "economic congestion" problem is not mentioned at all. Editorially, this could be a place to state the problem with an additional reference to [Varian]. Editorially, bandwidth tier pricing could be added to section 3.1, Existing approaches. I am now thinking that editorially a separate section is not a good idea, since the points can be merged into the existing outline, in at least the places mentioned above. I think adding that the use case needs to meet service provider economic congestion needs as well as be acceptable to users is an important point not in the current text. Traffic management (aka policing) may have the problem that it may not be popular with user. There has already been negative feedback on the list regarding policing (IMO, Traffic management is a better term). >Your point 2), for me, still looks like an mechanism on top of ConEx and >thus=20 >it might be out of scope. As I an others have posted, the conex use case document at least needs to mention the presence of shapers and whether they are in or out of scope. Specifically, the current text in section 4 seems to say they are out of scope=20 "congestion means that your traffic impacts other users, and conversely that their traffic impacts you." However, as a number of wg members have posted, shapers will cause effects that will appear as congestion. I would like to see the wg agree on whether this either in or out of scope -- you keep making the same point about scope. If you look at the list several others have said this case at least needs to be described in the draft, but have expressed concerns as to whether the complexity of adding to the mechanism will justify the benefit. Can you please say more as to why you believe it is out of scope. >Can you phrase based on this use case any new >requirements for the abstract mechanism design? If the wg decides inclusion of discussion of this use case is in scope, then I can do this. You seem to be the only person saying it is absolutely out of scope. > >Mirja > > >On Thursday 10 March 2011 15:36:00 Mcdysan, David E wrote: >> Hi Mirja, >> >> I was thinking about your comment below after looking for references on >> the "heavy user" problem and think there are at least two smaller >>problems. >> >> 1) A few "heavy" users generate most of the traffic and service >>providers >> want to better assign the cost (of provisioning an upgrade) for the time >> when congestion is anticipated to occur. Existing mechanisms, flat rate, >> bandwidth tier shapers, and usage tiers do not completely address the >> service provider objective and/or are not popular with users. >> >> 2) In some service provider networks shapers are implemented to limit >>the >> maximum bandwidth per user. Although overflow or marking in the shaper >> queue appears as congestion to the receiver, this "self-congestion" >> differs from congestion of a shared resource since a remedy could be to >> indicate to the user that changing the shaper rate (i.e., "go faster") >> would alleviate "self-congestion." >> >> I know that John had concerns regarding the length of the text and >> splitting it along the above lines would make understanding and >>discussion >> easier. I think that the text I submitted can be split into two along >>the >> above lines. >> >> Thanks, >> >> Dave >> >> >On 3/8/11 12:16 PM, "Mirja Kuehlewind" >> > >> > wrote: >> >>I have the feeling that in the text you provided, there are several >> >>points >> >>mixed up. Maybe we can try to separate them again in smaller parts...? > > > >--=20 >------------------------------------------------------------------- >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 >------------------------------------------------------------------- From dave.mcdysan@verizon.com Fri Mar 11 09:33:02 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E34D93A6A4F for ; Fri, 11 Mar 2011 09:33:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03gF6h1nKaLD for ; Fri, 11 Mar 2011 09:33:01 -0800 (PST) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id E04063A68B3 for ; Fri, 11 Mar 2011 09:33:01 -0800 (PST) Received: from fldsmtpi03.verizon.com (fldsmtpi03.verizon.com [166.68.71.145]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p2BHY44h026380 for ; Fri, 11 Mar 2011 12:34:19 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,304,1297036800"; d="scan'208,217";a="9808941" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi03.verizon.com with ESMTP; 11 Mar 2011 17:34:04 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.240]) by FHDP1LUMXC7HB02.us.one.verizon.com ([2002:a644:3bbd::a644:3bbd]) with mapi; Fri, 11 Mar 2011 12:34:04 -0500 To: Bob Briscoe , Nandita Dukkipati Date: Fri, 11 Mar 2011 12:34:01 -0500 Thread-Topic: [conex] draft-ietf-conex-abstract-mech-00 Thread-Index: AcvgEoP8zdb+GL3sQEC2yCP96CDAwQ== Message-ID: In-Reply-To: <201103101111.p2ABBw8f029651@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C99FC4DC10E6Ddavemcdysanoneverizoncom_" MIME-Version: 1.0 Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-abstract-mech-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 11 Mar 2011 17:33:03 -0000 --_000_C99FC4DC10E6Ddavemcdysanoneverizoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable HI Bob, Some responses to item 3 in line below prefixed by DM. Thanks, Dave From: Bob Briscoe > Date: Thu, 10 Mar 2011 06:11:46 -0500 To: Nandita Dukkipati > Cc: ConEx IETF list > Subject: Re: [conex] draft-ietf-conex-abstract-mech-00 Nandita, 2 out of 3 aspects of that appx are largely already in conex-abstract-mech.= The third brings out an awkward problem with the split between docs... Snipped =85 3/ However,... This leaves the question of where we have discussion of partial deployment = scenarios. To me the obvious doc for that is concepts-uses, which is where = use-cases are. abstract-mech is primarily about components. I had to rely on the notes from Beijing, because the audio didn't come thro= ugh until later in the session (I had to rush home from Beijing before the = session for a family matter). The notes record agreement to remove Appx A from concepts-uses, describing = it as "mechanism". But I didn't think of the detailed implications of movin= g the whole of appx A of concepts-uses to abstract-mech. What I do know is that concepts-uses has to go through the IESG first, and = if it doesn't address the issue of partial deployment itself, it won't get = through. I don't think it will be acceptable to the IESG to refer off to an= other doc for partial deployment (Section 5.5. Partial vs. Full Deployment= is too high level IMO). I propose that concepts-uses should still be the place for discussion of pa= rtial deployment scenarios. Yes, it should refer to abstract-mech for what = the components are. But then it should talk about how they would work in a = partial deployment scenario (which was in the original Appx A as well). DM =96 Although partial deployment is not explicitly listed in the conex ch= arter, I believe it is very important. In particular, I hope that some cone= x deployment would realize some benefit. A compromise that I would propose = instead of ncluding all detail from the appendix in the use case document i= s to include a higher level narrative in the use cases document, and then h= ave the detail in the mechanisms document. DM =96 I am interpreting partial deployment from the charter in terms of ex= periments in operational networks (I.e., not just lab experiments or trial = networks). It's unfortunate we've noticed this at such a late stage, but I'm glad you = did notice it. Bob --_000_C99FC4DC10E6Ddavemcdysanoneverizoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

HI Bob,

Some responses to item 3 in line below prefixed by DM. 
Thanks,

Dave

From: Bob Briscoe <bob.briscoe@bt.com>
Date: Thu, 10 Mar 2011 06:11:46 -0500
To: Nandita Dukkipati <nanditad@google.com>
Cc: ConEx IETF list <= conex@ietf.org>
Subject: = Re: [conex] draft-ietf-conex-abstract-mech-00

Nandita,

2 out of 3 aspects of that appx are largely already in conex-abstract-mech. The third brings out an awkward problem with the split between docs...

Snipped =85

3/ However,...
This leaves the question of where we have discussion of partial deployment scenarios. To me the obvious doc for that is concepts-uses, which is where use-cases are. abstract-mech is primarily about components.

I had to rely on the notes from Beijing, because the audio didn't come through until later in the session (I had to rush home from Beijing before the session for a family matter).

The notes record agreement to remove Appx A from concepts-uses, describing it as "mechanism". But I didn't think of the detailed implications of moving the whole of appx A of concepts-uses to abstract-mech.

What I do know is that concepts-uses has to go through the IESG first, and if it doesn't address the issue of partial deployment itself, it won't get through. I don't think it will be acceptable to the IESG to refer off to another doc for partial deployment (Section 5.5.  Partial vs. Full Deployment is too high level IMO).
=
I propose that concepts-uses should still be the place for discussion of partial deployment scenarios. Yes, it should refer to abstract-mech for what the components are. But then it should talk about how they would work in a partial deployment scenario (which was in the original Appx A as well).

DM =96 Although pa= rtial deployment is not explicitly listed in the conex charter, I believe i= t is very important. In particular, I hope that some conex deployment would= realize some benefit. A compromise that I would propose instead of ncludin= g all detail from the appendix in the use case document is to include a hig= her level narrative in the use cases document, and then have the detail in = the mechanisms document. 

DM =96 I am interpr= eting partial deployment from the charter in terms of experiments in operat= ional networks (I.e., not just lab experiments or trial networks). 


It's unfortunate we've noticed this at such a late stage, but I'm glad you did notice it.


Bob


 --_000_C99FC4DC10E6Ddavemcdysanoneverizoncom_-- From bob.briscoe@bt.com Fri Mar 11 16:25:42 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E4683A67B6 for ; Fri, 11 Mar 2011 16:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[AWL=-0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeE3BHYf3l7V for ; Fri, 11 Mar 2011 16:25:41 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id BC4C03A67B2 for ; Fri, 11 Mar 2011 16:25:40 -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); Sat, 12 Mar 2011 00:26:59 +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); Sat, 12 Mar 2011 00:26:59 +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 1299889617766; Sat, 12 Mar 2011 00:26:57 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.0.28]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p2C0QuIM003777; Sat, 12 Mar 2011 00:26:56 GMT Message-Id: <201103120026.p2C0QuIM003777@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 12 Mar 2011 00:25:45 +0000 To: "Mcdysan, David E" From: Bob Briscoe In-Reply-To: References: <201103101111.p2ABBw8f029651@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_733936434==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 12 Mar 2011 00:26:59.0436 (UTC) FILETIME=[336192C0:01CBE04C] Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-abstract-mech-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2011 00:25:42 -0000 --=====================_733936434==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable David, inline prefixed BB.. At 17:34 11/03/2011, Mcdysan, David E wrote: >HI Bob, > >Some responses to item 3 in line below prefixed by DM. > >Thanks, > >Dave > >From: Bob Briscoe <bob.briscoe@bt.com> >Date: Thu, 10 Mar 2011 06:11:46 -0500 >To: Nandita Dukkipati <nanditad@google.com> >Cc: ConEx IETF list <conex@ietf.org> >Subject: Re: [conex] draft-ietf-conex-abstract-mech-00 > >Nandita, > >2 out of 3 aspects of that appx are largely=20 >already in conex-abstract-mech. The third brings=20 >out an awkward problem with the split between docs... > >Snipped =85 > >3/ However,... >This leaves the question of where we have=20 >discussion of partial deployment scenarios. To=20 >me the obvious doc for that is concepts-uses,=20 >which is where use-cases are. abstract-mech is primarily about components. [snip] >What I do know is that concepts-uses has to go=20 >through the IESG first, and if it doesn't=20 >address the issue of partial deployment itself,=20 >it won't get through. I don't think it will be=20 >acceptable to the IESG to refer off to another=20 >doc for partial deployment (Section=20 >5.5. Partial vs. Full Deployment is too high level IMO). > >I propose that concepts-uses should still be the=20 >place for discussion of partial deployment=20 >scenarios. Yes, it should refer to abstract-mech=20 >for what the components are. But then it should=20 >talk about how they would work in a partial=20 >deployment scenario (which was in the original Appx A as well). > >DM =96 Although partial deployment is not=20 >explicitly listed in the conex charter, I=20 >believe it is very important. In particular, I=20 >hope that some conex deployment would realize=20 >some benefit. A compromise that I would propose=20 >instead of ncluding all detail from the appendix=20 >in the use case document is to include a higher=20 >level narrative in the use cases document, and=20 >then have the detail in the mechanisms document. BB: Trouble is, this is not what abstract-mech is=20 about at all. Partial deployment requires talking=20 about node placement. Correct me if I'm wrong,=20 but that's really out of scope for abstract-mech. >DM =96 I am interpreting partial deployment from=20 >the charter in terms of experiments in=20 >operational networks (I.e., not just lab experiments or trial networks). BB: Definitiely. Bob >It's unfortunate we've noticed this at such a=20 >late stage, but I'm glad you did notice it. > > >Bob > ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 --=====================_733936434==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David,

inline prefixed BB..

At 17:34 11/03/2011, Mcdysan, David E wrote:
HI Bob,

Some responses to item 3 in line below prefixed by DM.

Thanks,

Dave

From: Bob Briscoe <bob.briscoe@bt.com>
Date: Thu, 10 Mar 2011 06:11:46 -0500
To: Nandita Dukkipati <nanditad@google.com>
Cc: ConEx IETF list <conex@ietf.org>
Subject: Re: [conex] draft-ietf-conex-abstract-mech-00

Nandita,

2 out of 3 aspects of that appx are largely already in conex-abstract-mech. The third brings out an awkward problem with the split between docs...

Snipped =85

3/ However,...
This leaves the question of where we have discussion of partial deployment scenarios. To me the obvious doc for that is concepts-uses, which is where use-cases are. abstract-mech is primarily about components.
[snip]

What I do know is that concepts-uses has to go through the IESG first, and if it doesn't address the issue of partial deployment itself, it won't get through. I don't think it will be acceptable to the IESG to refer off to another doc for partial deployment (Section 5.5.  Partial vs. Full Deployment is too high level IMO).

I propose that concepts-uses should still be the place for discussion of partial deployment scenarios. Yes, it should refer to abstract-mech for what the components are. But then it should talk about how they would work in a partial deployment scenario (which was in the original Appx A as well).

DM =96 Although partial deployment is not explicitly listed in the conex charter, I believe it is very important. In particular, I hope that some conex deployment would realize some benefit. A compromise that I would propose instead of ncluding all detail from the appendix in the use case document is to include a higher level narrative in the use cases document, and then have the detail in the mechanisms document.

BB: Trouble is, this is not what abstract-mech is about at all. Partial deployment requires talking about node placement. Correct me if I'm wrong, but that's really out of scope for abstract-mech.


DM =96 I am interpreting part= ial deployment from the charter in terms of experiments in operational networks (I.e., not just lab experiments or trial networks).

BB: Definitiely.


Bob



It's unfortunate we've notice= d this at such a late stage, but I'm glad you did notice it.


Bob

________________________________________________________________
Bob Briscoe,           &n= bsp;            =         BT Innovate & Design --=====================_733936434==.ALT-- From bob.briscoe@bt.com Sun Mar 13 12:36:33 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CD123A6B32 for ; Sun, 13 Mar 2011 12:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.364 X-Spam-Level: X-Spam-Status: No, score=-3.364 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXOFauDG+6gl for ; Sun, 13 Mar 2011 12:36:32 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id CBC543A6A65 for ; Sun, 13 Mar 2011 12:36:31 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Mar 2011 19:37:52 +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, 13 Mar 2011 19:37:53 +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 1300045071741; Sun, 13 Mar 2011 19:37:51 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.64.158]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p2DJbli2015340; Sun, 13 Mar 2011 19:37:50 GMT Message-Id: <201103131937.p2DJbli2015340@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 13 Mar 2011 19:36:33 +0000 To: Nandita Dukkipati 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: 13 Mar 2011 19:37:53.0117 (UTC) FILETIME=[24FED8D0:01CBE1B6] Cc: ConEx IETF list Subject: [conex] Notes of Nandita's original (Jul'10) review of ConEx X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 19:36:33 -0000 Nandita and ConEx list, Here's a transcription and explanation of the scrawlings from my notebook, recording insights I got from discussing v useful review comments Nandita gave early in ConEx's life (27 July 2010 in Maastricht). We should have shared these sooner, but better late than never. ==1/ Possible entry points to introduce ConEx== * Congestion-volume as a metric * Downstream congestion - enabling traffic control at the ingress of an internetwork - as a customer-state-collection architecture (when compared with RCP/XCP/XCHOKe/AFD architecture) Explanation: RCP/XCP/XCHOKe/AFD and WFQ all assume an architecture where each forwarding box (or at least selected boxes) manages fairness between flows (or perhaps customers). However, fairness needs a metric that accumulates: - over time (and doesn't accumulate when a customer is idle), - over all the boxes in an internetwork that might be used by a customer at different times or in parallel. Because fairness control needs this per customer state, it is more practical to apply control at a 'customer edge' node, rather than at every forwarding node. Otherwise every node has to distribute its state about each customer to every other node. By exposing downstream congestion, ConEx continually carries that state in packets to the an ingress customer edge (policy) node. This could be brought to the egress instead (by ECN), but ConEx brings it to the ingress where engineering control can be applied before traffic can harm anything. Operators use volume in a similar "state collection architecture" to that of ConEx. Except, volume doesn't change along a flow, whereas congestion-volume does, so volume is already easy to measure at the ingress 'customer-edge' without needing a new protocol. ==2/ Points that Nandita didn't want overlooked== * The internetwork aspect of ConEx Shouldn't just be mentioned as an incidental, given network neutrality and information asymmetry issues. Information between autonomous networks is central to the benefits of ConEx and should be brought out. ==3/ A useful(?) analogy== * Weight inflation - motivates congestion-volume If n users are sharing a bottleneck, they send the same volume whether each uses 1 TCP, or each uses 10 TCPs (ie weight=10). But the overall congestion is roughly 100 times greater in the latter case. Like monetary inflation, everyone increasing their weights just reduces the value of weight. Weighting ends up achieving nothing, but causing more and more harm. With only volume, not congestion-volume, as a metric, there will be no incentive or ability to push back against this inflationary pressure. ==4/ An overlooked requirement=== * ConEx should be independent of the specific congestion signal mechanism (e.g. should work with QCN as well as with ECN) To derive downstream congestion, we know it works when regular ECN is subtracted from ConEx. But it should also be possible to measure downstream congestion if the underlying link layer is signalling congestion backwards hop-by-hop, as in QCN. HTH Bob PS. I am getting reports from some people that they cannot reply to my emails or forward them. If anyone has problems replying to this email, let me know by composing a new email to bob.briscoe@bt.com - I'm trying to diagnose the problem. ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Sun Mar 13 18:41:40 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00A3A3A6AB9 for ; Sun, 13 Mar 2011 18:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.707 X-Spam-Level: X-Spam-Status: No, score=-2.707 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyxfVAOdk3TP for ; Sun, 13 Mar 2011 18:41:38 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 1BCA53A6AB7 for ; Sun, 13 Mar 2011 18:41:37 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 01:42:59 +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 Mar 2011 01:42:59 +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 130006697891; Mon, 14 Mar 2011 01:42:58 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.64.13]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p2E1gtsp016131; Mon, 14 Mar 2011 01:42:56 GMT Message-Id: <201103140142.p2E1gtsp016131@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 13 Mar 2011 23:51:39 +0000 To: Nandita Dukkipati , Marcelo BAGNULO BRAUN From: Bob Briscoe In-Reply-To: <7.1.0.9.2.20110311220539.058ede38@bt.com> References: <201103101111.p2ABBw8f029651@bagheera.jungle.bt.co.uk> <7.1.0.9.2.20110311220539.058ede38@bt.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_911297967==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 14 Mar 2011 01:42:59.0605 (UTC) FILETIME=[2647A450:01CBE1E9] Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-abstract-mech-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 01:41:40 -0000 --=====================_911297967==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Marcelo, Nandita, Thinking more about where partial deployment text should go... There are four different aspects to partial deployment: 1. ConEx and/or non-ConEx packets (abstract-mech: encoding) 2. ConEx and/or non-ConEx receivers (abstract-mech: ConEx Components) 3. Interwork with loss and/or ECN queues (abstract-mech: encoding & reqs) 4. Some networks use ConEx signals, others don't (concepts-uses). abstract-mech isn't a natural home for #4 because=20 it's not designed to talk about why a network=20 would want to use ConEx. It doesn't even mention=20 networks as autonomous from each other. This is=20 all the territory of concepts-uses. BTW, David, the charter does ask us to consider partial deployment. Quoting: "However, the CONEX WG will initially=20 focus on one use case, where the end hosts and=20 the network that contains the destination end=20 host are CONEX-enabled but other networks need not be." Bob At 00:25 12/03/2011, Bob Briscoe wrote: >David, > >inline prefixed BB.. > >At 17:34 11/03/2011, Mcdysan, David E wrote: >>HI Bob, >> >>Some responses to item 3 in line below prefixed by DM. >> >>Thanks, >> >>Dave >> >>From: Bob Briscoe <bob.briscoe@bt.com> >>Date: Thu, 10 Mar 2011 06:11:46 -0500 >>To: Nandita Dukkipati <nanditad@google.com> >>Cc: ConEx IETF list <conex@ietf.org> >>Subject: Re: [conex] draft-ietf-conex-abstract-mech-00 >> >>Nandita, >> >>2 out of 3 aspects of that appx are largely=20 >>already in conex-abstract-mech. The third=20 >>brings out an awkward problem with the split between docs... >> >>Snipped =85 >> >>3/ However,... >>This leaves the question of where we have=20 >>discussion of partial deployment scenarios. To=20 >>me the obvious doc for that is concepts-uses,=20 >>which is where use-cases are. abstract-mech is primarily about components. >[snip] > >>What I do know is that concepts-uses has to go=20 >>through the IESG first, and if it doesn't=20 >>address the issue of partial deployment itself,=20 >>it won't get through. I don't think it will be=20 >>acceptable to the IESG to refer off to another=20 >>doc for partial deployment (Section=20 >>5.5. Partial vs. Full Deployment is too high level IMO). >> >>I propose that concepts-uses should still be=20 >>the place for discussion of partial deployment=20 >>scenarios. Yes, it should refer to=20 >>abstract-mech for what the components are. But=20 >>then it should talk about how they would work=20 >>in a partial deployment scenario (which was in the original Appx A as= well). >> >>DM =96 Although partial deployment is not=20 >>explicitly listed in the conex charter, I=20 >>believe it is very important. In particular, I=20 >>hope that some conex deployment would realize=20 >>some benefit. A compromise that I would propose=20 >>instead of ncluding all detail from the=20 >>appendix in the use case document is to include=20 >>a higher level narrative in the use cases=20 >>document, and then have the detail in the mechanisms document. > >BB: Trouble is, this is not what abstract-mech=20 >is about at all. Partial deployment requires=20 >talking about node placement. Correct me if I'm=20 >wrong, but that's really out of scope for abstract-mech. > > >>DM =96 I am interpreting partial deployment from=20 >>the charter in terms of experiments in=20 >>operational networks (I.e., not just lab experiments or trial networks). > >BB: Definitiely. > > >Bob > > > >>It's unfortunate we've noticed this at such a=20 >>late stage, but I'm glad you did notice it. >> >> >>Bob >________________________________________________________________ >Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 --=====================_911297967==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Marcelo, Nandita,

Thinking more about where partial deployment text should go...

There are four different aspects to partial deployment:
1. ConEx and/or non-ConEx packets       (abstract-mech: encoding)
2. ConEx and/or non-ConEx receivers     (abstract-mech: ConEx Components)
3. Interwork with loss and/or ECN queues (abstract-mech: encoding & reqs)
4. Some networks use ConEx signals, others don't        (concepts-uses).

abstract-mech isn't a natural home for #4 because it's not designed to talk about why a network would want to use ConEx. It doesn't even mention networks as autonomous from each other. This is all the territory of concepts-uses.


BTW, David, the charter does ask us to consider partial deployment. Quoting:
         "However, the CONEX WG will initially focus on one use case, where the end hosts and the network that contains the destination end host are CONEX-enabled but other networks need not be."


Bob

At 00:25 12/03/2011, Bob Briscoe wrote:

David,

inline prefixed BB..

At 17:34 11/03/2011, Mcdysan, David E wrote:
HI Bob,

Some responses to item 3 in line below prefixed by DM.

Thanks,

Dave

From: Bob Briscoe <bob.briscoe@bt.com>
Date: Thu, 10 Mar 2011 06:11:46 -0500
To: Nandita Dukkipati <nanditad@google.com>
Cc: ConEx IETF list <conex@ietf.org>
Subject: Re: [conex] draft-ietf-conex-abstract-mech-00

Nandita,

2 out of 3 aspects of that appx are largely already in conex-abstract-mech. The third brings out an awkward problem with the split between docs...

Snipped =85

3/ However,...
This leaves the question of where we have discussion of partial deployment scenarios. To me the obvious doc for that is concepts-uses, which is where use-cases are. abstract-mech is primarily about components.
[snip]

What I do know is that concepts-uses has to go through the IESG first, and if it doesn't address the issue of partial deployment itself, it won't get through. I don't think it will be acceptable to the IESG to refer off to another doc for partial deployment (Section 5.5.  Partial vs. Full Deployment is too high level IMO).

I propose that concepts-uses should still be the place for discussion of partial deployment scenarios. Yes, it should refer to abstract-mech for what the components are. But then it should talk about how they would work in a partial deployment scenario (which was in the original Appx A as well).

DM =96 Although partial deployment is not explicitly listed in the conex charter, I believe it is very important. In particular, I hope that some conex deployment would realize some benefit. A compromise that I would propose instead of ncluding all detail from the appendix in the use case document is to include a higher level narrative in the use cases document, and then have the detail in the mechanisms document.

BB: Trouble is, this is not what abstract-mech is about at all. Partial deployment requires talking about node placement. Correct me if I'm wrong, but that's really out of scope for abstract-mech.


DM =96 I am interpreting part= ial deployment from the charter in terms of experiments in operational networks (I.e., not just lab experiments or trial networks).

BB: Definitiely.


Bob



It's unfortunate we've notice= d this at such a late stage, but I'm glad you did notice it.


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

________________________________________________________________
Bob Briscoe,           &n= bsp;            =         BT Innovate & Design --=====================_911297967==.ALT-- From dave.mcdysan@verizon.com Mon Mar 14 04:45:52 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14C83A6B41 for ; Mon, 14 Mar 2011 04:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jn2SkN9LeuIs for ; Mon, 14 Mar 2011 04:45:51 -0700 (PDT) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id 76C2E3A68E4 for ; Mon, 14 Mar 2011 04:45:50 -0700 (PDT) Received: from fldsmtpi03.verizon.com (fldsmtpi03.verizon.com [166.68.71.145]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p2EBlBlv006833 for ; Mon, 14 Mar 2011 07:47:11 -0400 (EDT) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,315,1297036800"; d="scan'208,217";a="10844155" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi03.verizon.com with ESMTP; 14 Mar 2011 11:47:11 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.240]) by FHDP1LUMXC7HB02.us.one.verizon.com ([2002:a644:3bbd::a644:3bbd]) with mapi; Mon, 14 Mar 2011 07:47:11 -0400 To: Bob Briscoe , Nandita Dukkipati , Marcelo BAGNULO BRAUN Date: Mon, 14 Mar 2011 07:47:09 -0400 Thread-Topic: [conex] draft-ietf-conex-abstract-mech-00 Thread-Index: AcviPY26jOxLfOpXR5Ooiy+JZ28BHA== Message-ID: In-Reply-To: <201103140142.p2E1gtsp016131@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C9A377AF10F4Adavemcdysanoneverizoncom_" MIME-Version: 1.0 Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-abstract-mech-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 11:45:53 -0000 --_000_C9A377AF10F4Adavemcdysanoneverizoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Bob, Do 1 and 2 in your list below include (sending) hosts (on the same network = as the receiver) who do not use conex signals? I believe this is an important aspect of partial deployment that may not fi= t well in the abstract mechanism draft. Thanks, Dave From: Bob Briscoe > Date: Sun, 13 Mar 2011 19:51:39 -0400 To: Nandita Dukkipati >, Ma= rcelo BAGNULO BRAUN > Cc: David McDysan >, ConEx IETF list > Subject: Re: [conex] draft-ietf-conex-abstract-mech-00 Marcelo, Nandita, Thinking more about where partial deployment text should go... There are four different aspects to partial deployment: 1. ConEx and/or non-ConEx packets (abstract-mech: encoding) 2. ConEx and/or non-ConEx receivers (abstract-mech: ConEx Components) 3. Interwork with loss and/or ECN queues (abstract-mech: encoding & reqs) 4. Some networks use ConEx signals, others don't (concepts-uses). abstract-mech isn't a natural home for #4 because it's not designed to talk= about why a network would want to use ConEx. It doesn't even mention netwo= rks as autonomous from each other. This is all the territory of concepts-us= es. BTW, David, the charter does ask us to consider partial deployment. Quoting= : "However, the CONEX WG will initially focus on one use case, where = the end hosts and the network that contains the destination end host are CO= NEX-enabled but other networks need not be." Bob At 00:25 12/03/2011, Bob Briscoe wrote: David, inline prefixed BB.. At 17:34 11/03/2011, Mcdysan, David E wrote: HI Bob, Some responses to item 3 in line below prefixed by DM. Thanks, Dave From: Bob Briscoe > Date: Thu, 10 Mar 2011 06:11:46 -0500 To: Nandita Dukkipati > Cc: ConEx IETF list > Subject: Re: [conex] draft-ietf-conex-abstract-mech-00 Nandita, 2 out of 3 aspects of that appx are largely already in conex-abstract-mech.= The third brings out an awkward problem with the split between docs... Snipped =85 3/ However,... This leaves the question of where we have discussion of partial deployment = scenarios. To me the obvious doc for that is concepts-uses, which is where = use-cases are. abstract-mech is primarily about components. [snip] What I do know is that concepts-uses has to go through the IESG first, and = if it doesn't address the issue of partial deployment itself, it won't get = through. I don't think it will be acceptable to the IESG to refer off to an= other doc for partial deployment (Section 5.5. Partial vs. Full Deployment= is too high level IMO). I propose that concepts-uses should still be the place for discussion of pa= rtial deployment scenarios. Yes, it should refer to abstract-mech for what = the components are. But then it should talk about how they would work in a = partial deployment scenario (which was in the original Appx A as well). DM =96 Although partial deployment is not explicitly listed in the conex ch= arter, I believe it is very important. In particular, I hope that some cone= x deployment would realize some benefit. A compromise that I would propose = instead of ncluding all detail from the appendix in the use case document i= s to include a higher level narrative in the use cases document, and then h= ave the detail in the mechanisms document. BB: Trouble is, this is not what abstract-mech is about at all. Partial dep= loyment requires talking about node placement. Correct me if I'm wrong, but= that's really out of scope for abstract-mech. DM =96 I am interpreting partial deployment from the charter in terms of ex= periments in operational networks (I.e., not just lab experiments or trial = networks). BB: Definitiely. Bob It's unfortunate we've noticed this at such a late stage, but I'm glad you = did notice it. Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design --_000_C9A377AF10F4Adavemcdysanoneverizoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Bob,

Do 1 and 2 in your list below include (sending) hosts (on the same networ= k as the receiver) who do not use conex signals? 

=
I believe this is an important aspect of partial deployment that may n= ot fit well in the abstract mechanism draft.

Thank= s,

Dave

From: Bob Briscoe <bob.briscoe@bt.com>
Dat= e: Sun, 13 Mar 2011 19:51:39 -0400
To: Nandita Dukkipati <nanditad@google.com>, Marcelo BAGNULO BRAUN <marcelo@it.uc3m.es>
Cc: David McDysan <dave.mcdysan@one.verizon.com>, ConEx IETF list <conex@ietf.org>
Subject: Re: [conex] draft-ietf-conex-abstract-mech-00<= br>

Marcelo, Nandita,

Thinking more about where partial deployment text should go...

There are four different aspects to partial deployment:
1. ConEx and/or non-ConEx packets       (abstract-mech: encoding)
2. ConEx and/or non-ConEx receivers     (abstract-mech: ConEx Components)
3. Interwork with loss and/or ECN queues (abstract-mech: encoding & reqs)
4. Some networks use ConEx signals, others don't        (concepts-uses).

abstract-mech isn't a natural home for #4 because it's not designed to talk about why a network would want to use ConEx. It doesn't even mention networks as autonomous from each other. This is all the territory of concepts-uses.


BTW, David, the charter does ask us to consider partial deployment. Quoting:
        = "However, the CONEX WG will initially focus on one use case, where the end hosts and the network that contains the destination end host are CONEX-enabled but other networks need not be."


Bob

At 00:25 12/03/2011, Bob Briscoe wrote:
David,

inline prefixed BB..

At 17:34 11/03/2011, Mcdysan, David E wrote:
HI Bob,

Some responses to item 3 in line below prefixed by DM.

Thanks,

Dave

From: Bob Briscoe <bob.briscoe@bt.com>
Date: Thu, 10 Mar 2011 06:11:46 -0500
To: Nandita Dukkipati <nanditad@google.com>
Cc: ConEx IETF list <conex@ietf.org>
Subject: Re: [conex] draft-ietf-conex-abstract-mech-00

Nandita,

2 out of 3 aspects of that appx are largely already in conex-abstract-mech. The third brings out an awkward problem with the split between docs...

Snipped =85

3/ However,...
This leaves the question of where we have discussion of partial deployment scenarios. To me the obvious doc for that is concepts-uses, which is where use-cases are. abstract-mech is primarily about components.
[snip]

What I do know is that concepts-uses has to go through the IESG first, and if it doesn't address the issue of partial deployment itself, it won't get through. I don't think it will be acceptable to the IESG to refer off to another doc for partial deployment (Section 5.5.  Partial vs. Full Deployment is too high level IMO).

I propose that concepts-uses should still be the place for discussion of partial deployment scenarios. Yes, it should refer to abstract-mech for what the components are. But then it should talk about how they would work in a partial deployment scenario (which was in the original Appx A as well).

DM =96 Although partial deployment is not explicitly listed in the conex charter, I believe it is very important. In particular, I hope that some conex deployment would realize some benefit. A compromise that I would propose instead of ncluding all detail from the appendix in the use case document is to include a higher level narrative in the use cases document, and then have the detail in the mechanisms document.

BB: Trouble is, this is not what abstract-mech is about at all. Partial deployment requires talking about node placement. Correct me if I'm wrong, but that's really out of scope for abstract-mech.


DM =96 I am interpreting partia= l deployment from the charter in terms of experiments in operational networks (I.e., not just lab experiments or trial networks).

BB: Definitiely.


Bob



It's = unfortunate we've noticed this at such a late stage, but I'm glad you did notice it.


Bob
________________________________________________________________
Bob Briscoe,           &= nbsp;           &nbs= p;        BT Innovate & Design

________________________________________________________________
Bob Briscoe,           &= nbsp;           &nbs= p;        BT Innovate & Design

 --_000_C9A377AF10F4Adavemcdysanoneverizoncom_-- From ingemar.s.johansson@ericsson.com Mon Mar 14 06:14:02 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8A763A6D37 for ; Mon, 14 Mar 2011 06:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFOV3MwFEHKk for ; Mon, 14 Mar 2011 06:14:02 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id C0A503A6961 for ; Mon, 14 Mar 2011 06:14:01 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-56-4d7e14ec692d Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 00.33.09202.CE41E7D4; Mon, 14 Mar 2011 14:15:24 +0100 (CET) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.230]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 14 Mar 2011 14:15:24 +0100 From: Ingemar Johansson S To: Bob Briscoe Date: Mon, 14 Mar 2011 14:15:24 +0100 Thread-Topic: [conex] Notes of Nandita's original (Jul'10) review of ConEx Thread-Index: AcviPZSLIQqeSsq5RzSrh7NbU/HQuAAC66jA Message-ID: References: <201103131937.p2DJbli2015340@bagheera.jungle.bt.co.uk> In-Reply-To: <201103131937.p2DJbli2015340@bagheera.jungle.bt.co.uk> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: ConEx IETF list Subject: Re: [conex] Notes of Nandita's original (Jul'10) review of ConEx X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 13:14:02 -0000 Hi Bob and others I am interested in some more explanation to the weight-inflation argument. = Is there any document that describes this in more detail ? Regards Ingemar -----Original Message----- From: Bob Briscoe [mailto:bob.briscoe@bt.com]=20 Sent: den 13 mars 2011 20:37 To: Nandita Dukkipati Cc: ConEx IETF list Subject: [conex] Notes of Nandita's original (Jul'10) review of ConEx Snip-snip... =3D=3D3/ A useful(?) analogy=3D=3D * Weight inflation - motivates congestion-volume If n users are sharing a bottleneck, they send the same volume whether each= uses 1 TCP, or each uses 10 TCPs (ie weight=3D10). But the overall congest= ion is roughly 100 times greater in the latter case.=20 Like monetary inflation, everyone increasing their weights just reduces the= value of weight. Weighting ends up achieving nothing, but causing more and= more harm. With only volume, not congestion-volume, as a metric, there will be no ince= ntive or ability to push back against this inflationary pressure. From bob.briscoe@bt.com Mon Mar 14 08:50:20 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AF4A3A6DA7 for ; Mon, 14 Mar 2011 08:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[AWL=-0.488, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBqthuTJ7W1C for ; Mon, 14 Mar 2011 08:50:14 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 411863A6D2E for ; Mon, 14 Mar 2011 08:50:12 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 15:51:35 +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 Mar 2011 15:51:35 +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 1300117892986; Mon, 14 Mar 2011 15:51:32 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.179.147]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p2EFpUcu018850; Mon, 14 Mar 2011 15:51:30 GMT Message-Id: <201103141551.p2EFpUcu018850@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 14 Mar 2011 15:51:20 +0000 To: "Mcdysan, David E" From: Bob Briscoe In-Reply-To: References: <201103140142.p2E1gtsp016131@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_962211386==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 14 Mar 2011 15:51:35.0080 (UTC) FILETIME=[B2449280:01CBE25F] Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-abstract-mech-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 15:50:20 -0000 --=====================_962211386==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable David, At 11:47 14/03/2011, Mcdysan, David E wrote: >Hi Bob, > >Do 1 and 2 in your list below include (sending)=20 >hosts (on the same network as the receiver) who do not use conex signals? Yes. Well, strictly #2 is about receivers not senders.=20 But 1 is about senders being free to choose=20 whether to send ConEx packets or not. That is=20 fundamental to partial deployment. It means some=20 transports on a sender can be ConEx-enabled and others not. But you're right. Abstract-mech only talks about=20 ensuring the encoding allows ConEx or Not-ConEx=20 in packets. It doesn't talk about how a network=20 incentivises senders to send ConEx packets rather=20 than Not-ConEx packets, wherever possible. As Matt has said, abstract-mech doesn't have=20 humans and companies in it. It just has the=20 abstractions of source, network, destination,=20 transport, etc. So it can't talk about deployment incentives. Bob >I believe this is an important aspect of partial=20 >deployment that may not fit well in the abstract mechanism draft. > >Thanks, > >Dave > >From: Bob Briscoe <bob.briscoe@bt.com> >Date: Sun, 13 Mar 2011 19:51:39 -0400 >To: Nandita Dukkipati=20 ><nanditad@google.com>,=20 >Marcelo BAGNULO BRAUN <marcelo@it.uc3m.es> >Cc: David McDysan=20 ><dave.mcdysan@one.verizon.com>,=20 >ConEx IETF list <conex@ietf.org> >Subject: Re: [conex] draft-ietf-conex-abstract-mech-00 > >Marcelo, Nandita, > >Thinking more about where partial deployment text should go... > >There are four different aspects to partial deployment: >1. ConEx and/or non-ConEx packets (abstract-mech: encoding) >2. ConEx and/or non-ConEx receivers (abstract-mech: ConEx Components) >3. Interwork with loss and/or ECN queues (abstract-mech: encoding & reqs) >4. Some networks use ConEx signals, others don't (concepts-uses). > >abstract-mech isn't a natural home for #4=20 >because it's not designed to talk about why a=20 >network would want to use ConEx. It doesn't even=20 >mention networks as autonomous from each other.=20 >This is all the territory of concepts-uses. > > >BTW, David, the charter does ask us to consider partial deployment.= Quoting: > "However, the CONEX WG will initially=20 > focus on one use case, where the end hosts and=20 > the network that contains the destination end=20 > host are CONEX-enabled but other networks need not be." > > >Bob > >At 00:25 12/03/2011, Bob Briscoe wrote: >>David, >> >>inline prefixed BB.. >> >>At 17:34 11/03/2011, Mcdysan, David E wrote: >>>HI Bob, >>> >>>Some responses to item 3 in line below prefixed by DM. >>> >>>Thanks, >>> >>>Dave >>> >>>From: Bob Briscoe <bob.briscoe@bt.com> >>>Date: Thu, 10 Mar 2011 06:11:46 -0500 >>>To: Nandita Dukkipati <nanditad@google.com> >>>Cc: ConEx IETF list <conex@ietf.org> >>>Subject: Re: [conex] draft-ietf-conex-abstract-mech-00 >>> >>>Nandita, >>> >>>2 out of 3 aspects of that appx are largely=20 >>>already in conex-abstract-mech. The third=20 >>>brings out an awkward problem with the split between docs... >>> >>>Snipped =85 >>> >>>3/ However,... >>>This leaves the question of where we have=20 >>>discussion of partial deployment scenarios. To=20 >>>me the obvious doc for that is concepts-uses,=20 >>>which is where use-cases are. abstract-mech is primarily about= components. >>[snip] >> >>>What I do know is that concepts-uses has to go=20 >>>through the IESG first, and if it doesn't=20 >>>address the issue of partial deployment=20 >>>itself, it won't get through. I don't think it=20 >>>will be acceptable to the IESG to refer off to=20 >>>another doc for partial deployment (Section=20 >>>5.5. Partial vs. Full Deployment is too high level IMO). >>> >>>I propose that concepts-uses should still be=20 >>>the place for discussion of partial deployment=20 >>>scenarios. Yes, it should refer to=20 >>>abstract-mech for what the components are. But=20 >>>then it should talk about how they would work=20 >>>in a partial deployment scenario (which was in the original Appx A as= well). >>> >>>DM =96 Although partial deployment is not=20 >>>explicitly listed in the conex charter, I=20 >>>believe it is very important. In particular, I=20 >>>hope that some conex deployment would realize=20 >>>some benefit. A compromise that I would=20 >>>propose instead of ncluding all detail from=20 >>>the appendix in the use case document is to=20 >>>include a higher level narrative in the use=20 >>>cases document, and then have the detail in the mechanisms document. >> >>BB: Trouble is, this is not what abstract-mech=20 >>is about at all. Partial deployment requires=20 >>talking about node placement. Correct me if I'm=20 >>wrong, but that's really out of scope for abstract-mech. >> >> >>>DM =96 I am interpreting partial deployment from=20 >>>the charter in terms of experiments in=20 >>>operational networks (I.e., not just lab experiments or trial networks). >> >>BB: Definitiely. >> >> >>Bob >> >> >> >>>It's unfortunate we've noticed this at such a=20 >>>late stage, but I'm glad you did notice it. >>> >>> >>>Bob >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 --=====================_962211386==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David,

At 11:47 14/03/2011, Mcdysan, David E wrote:
Hi Bob,

Do 1 and 2 in your list below include (sending) hosts (on the same network as the receiver) who do not use conex signals?

Yes.

Well, strictly #2 is about receivers not senders. But 1 is about senders being free to choose whether to send ConEx packets or not. That is fundamental to partial deployment. It means some transports on a sender can be ConEx-enabled and others not.

But you're right. Abstract-mech only talks about ensuring the encoding allows ConEx or Not-ConEx in packets. It doesn't talk about how a network incentivises senders to send ConEx packets rather than Not-ConEx packets, wherever possible.

As Matt has said, abstract-mech doesn't have humans and companies in it. It just has the abstractions of source, network, destination, transport, etc. So it can't talk about deployment incentives.


Bob


I believe this is an importan= t aspect of partial deployment that may not fit well in the abstract mechanism draft.

Thanks,

Dave

From: Bob Briscoe <bob.briscoe@bt.com>
Date: Sun, 13 Mar 2011 19:51:39 -0400
To: Nandita Dukkipati <nanditad@google.com>, Marcelo BAGNULO BRAUN <marcelo@it.uc3m.es>
Cc: David McDysan < dave.mcdysan@one.verizon.com>, ConEx IETF list <conex@ietf.org>
Subject: Re: [conex] draft-ietf-conex-abstract-mech-00

Marcelo, Nandita,

Thinking more about where partial deployment text should go...

There are four different aspects to partial deployment:
1. ConEx and/or non-ConEx packets       (abstract-mech: encoding)
2. ConEx and/or non-ConEx receivers     (abstract-mech: ConEx Components)
3. Interwork with loss and/or ECN queues (abstract-mech: encoding & reqs)
4. Some networks use ConEx signals, others don't        (concepts-uses).

abstract-mech isn't a natural home for #4 because it's not designed to talk about why a network would want to use ConEx. It doesn't even mention networks as autonomous from each other. This is all the territory of concepts-uses.


BTW, David, the charter does ask us to consider partial deployment. Quoting:
         "However, the CONEX WG will initially focus on one use case, where the end hosts and the network that contains the destination end host are CONEX-enabled but other networks need not be."


Bob

At 00:25 12/03/2011, Bob Briscoe wrote:
David,

inline prefixed BB..

At 17:34 11/03/2011, Mcdysan, David E wrote:
HI Bob,

Some responses to item 3 in line below prefixed by DM.

Thanks,

Dave

From: Bob Briscoe <bob.briscoe@bt.com>
Date: Thu, 10 Mar 2011 06:11:46 -0500
To: Nandita Dukkipati <nanditad@google.com>
Cc: ConEx IETF list <conex@ietf.org>
Subject: Re: [conex] draft-ietf-conex-abstract-mech-00

Nandita,

2 out of 3 aspects of that appx are largely already in conex-abstract-mech. The third brings out an awkward problem with the split between docs...

Snipped =85

3/ However,...
This leaves the question of where we have discussion of partial deployment scenarios. To me the obvious doc for that is concepts-uses, which is where use-cases are. abstract-mech is primarily about components.
[snip]

What I do know is that concepts-uses has to go through the IESG first, and if it doesn't address the issue of partial deployment itself, it won't get through. I don't think it will be acceptable to the IESG to refer off to another doc for partial deployment (Section 5.5.  Partial vs. Full Deployment is too high level IMO).

I propose that concepts-uses should still be the place for discussion of partial deployment scenarios. Yes, it should refer to abstract-mech for what the components are. But then it should talk about how they would work in a partial deployment scenario (which was in the original Appx A as well).

DM =96 Although partial deployment is not explicitly listed in the conex charter, I believe it is very important. In particular, I hope that some conex deployment would realize some benefit. A compromise that I would propose instead of ncluding all detail from the appendix in the use case document is to include a higher level narrative in the use cases document, and then have the detail in the mechanisms document.

BB: Trouble is, this is not what abstract-mech is about at all. Partial deployment requires talking about node placement. Correct me if I'm wrong, but that's really out of scope for abstract-mech.


DM =96 I am interpreting part= ial deployment from the charter in terms of experiments in operational networks (I.e., not just lab experiments or trial networks).

BB: Definitiely.


Bob



It's unfortunate we've notice= d this at such a late stage, but I'm glad you did notice it.


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

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

________________________________________________________________
Bob Briscoe,           &n= bsp;            =         BT Innovate & Design --=====================_962211386==.ALT-- From karagian@cs.utwente.nl Mon Mar 14 09:56:40 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 346643A6DA0 for ; Mon, 14 Mar 2011 09:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.404 X-Spam-Level: X-Spam-Status: No, score=-0.404 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3IvbRZ-G-7r for ; Mon, 14 Mar 2011 09:56:39 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id DF1CA3A6DE3 for ; Mon, 14 Mar 2011 09:56:38 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id p2EGveuG000138; Mon, 14 Mar 2011 17:57:44 +0100 (MET) From: "Georgios Karagiannis" To: "'Bob Briscoe'" , References: <201103140142.p2E1gtsp016131@bagheera.jungle.bt.co.uk> Date: Mon, 14 Mar 2011 17:57:37 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcviPY26jOxLfOpXR5Ooiy+JZ28BHAAKIQ7w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 14 Mar 2011 17:57:53 +0100 (MET) Cc: 'ConEx IETF list' Subject: [conex] comments on draft-ietf-conex-abstract-mech-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 16:56:40 -0000 Hi Bob, Hi Matt I have read the draft-ietf-conex-abstract-mech-00 draft. The concept desribed in this draft is very interesting. However, I have a comment related to the measurement of the congestion rate at the receiver side. I think that there is a possible accuracy problem related to the measurement of the congestion rate at the receiver side. This problem occurs when multiple ConEx nodes that are located on the same communication path are congested and therefore, marked packets might be dropped. This problem, see below Figure is identified within the context of PCN and is denoted as the multiple bottlenecks problem in the PCN domain, see e.g., Section B.4 in [RFC5670]. In particular, consider that the nodes Q1, Q2 and Q3 are all congested. This means that Q1, Q2 and Q3 will start marking the packets with the Re-Echo-ECN ConEx code. Due to the fact that Q2 and Q3 are also congested, it could mean that Re-Echo-ECN packets that were marked by Q1 might be dropped. This might result in the fact that the measured Congestion-rate at the receiver R, related to a flow, might not be accurate enough. +---+ +----+ +----+ +----+ +---+ | S |--| Q1 |---| Q2 |---------| Q3 |--| R | +---+ +----+ +----+ +----+ +---+ ^ ^ ^ | | | Congested Congested Congested A possible solution to this measurement accuracy problem is that in congestion situations the receiver measures for each flow the Throughput instead of measuring the congestion rate. In congestion situations the measured Throughput at the receiver is sent periodically as feedback to the sender, see below Figure. Throughput can be defined as the instantaneous rate of traffic measured at one receiver that is (1) belonging to the same flow, (2) that is Not-Re-Echo-ECN marked and (3) is sent by the same sender. The sender always measures the Incoming rate associated with a flow. The Incoming rate is the instantaneous rate of traffic that is belonging to the same flow and is sent by a sender towards the same receiver. In order to calculate the Congestion rate, the sender subtracts the Troughput from the Incoming rate. Using this calculated Congestion rate, the sender calculates the Congestion exposure signal using the same method as described in draft-ietf-conex-abstract-mech-00. 123456789012345678901234567890123456789012345678901234567890123456789 +---------+ +---------+ | |<==Feedback Path==============================<| | | |<----------returned throughput ---------------<| | | | | | |Transport| |Transport| | Sender |>---------(new)-IP layer ConEx Signal--------->| Receiver| | | (Carried in Data Packet Headers) | | | | +-----------+ | | | |>=Data=Path=>|(Congested)|>=====Data=Path=====>| | | | | Network |>-Congestion-Signal->| | | | | Device | | | +---------+ +-----------+ +---------+ Overview ConEx architecture with throughput feedback In order to describe this possible accuracy problem on the measurement of the congestion rate and its solutions I have made an Internet draft that I would like to submit once the IETF submission possibility opens again! A preversion of this Internet draft can be found under: http://wwwhome.cs.utwente.nl/~karagian/conex/draft-karagiannis-conex-through put-exposure-00_not_published.txt Best regards, Georgios From bob.briscoe@bt.com Mon Mar 14 10:48:16 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D95353A6DAB for ; Mon, 14 Mar 2011 10:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.365 X-Spam-Level: X-Spam-Status: No, score=-3.365 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FQNmesqIxUc for ; Mon, 14 Mar 2011 10:48:15 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 5DA6B3A6D6F for ; Mon, 14 Mar 2011 10:48:14 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 17:49:37 +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, 14 Mar 2011 17:49:37 +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 130012498399; Mon, 14 Mar 2011 17:49:43 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.16.199]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p2EHnYHl019263; Mon, 14 Mar 2011 17:49:35 GMT Message-Id: <201103141749.p2EHnYHl019263@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 14 Mar 2011 17:49:20 +0000 To: Ingemar Johansson S From: Bob Briscoe In-Reply-To: References: <201103131937.p2DJbli2015340@bagheera.jungle.bt.co.uk> 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 Mar 2011 17:49:37.0889 (UTC) FILETIME=[2FF37510:01CBE270] Cc: ConEx IETF list Subject: Re: [conex] Notes of Nandita's original (Jul'10) review of ConEx X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 17:48:17 -0000 Ingemar, At 13:15 14/03/2011, Ingemar Johansson S wrote: >Hi Bob and others > >I am interested in some more explanation to the weight-inflation >argument. Is there any document that describes this in more detail ? I think there might have been a mention of it in Jon Crowcroft's paper on MulTCP. However, you get the same effect whether you use n TCPs or MulTCP with the parameter set to n. It's basically a simple argument. If everyone is pushing to get through a narrow gap, the speed they get through is always the same, whether they all push hard, or whether they all don't. The only outcome of all pushing harder is to cause more bruises. With TCP, the square root relation between window & congestion means that if you try to push 10x more TCPs through the same gap, congestion increases to reduce everyone's window to 1/10 of before. So by the TCP equation, congestion will have to be 100x greater (in theory). Does that help? Crowcroft, J. & Oechslin, P., "Differentiated End to End Internet Services using a Weighted Proportional Fair Sharing TCP," Computer Communication Review 28(3):53--69 In: April Vol.28 No.3 pp.53-69 ACM (July 1998) URL: ftp://cs.ucl.ac.uk/darpa/multcp.ps.gz or http://www.cs.ucl.ac.uk/staff/J.Crowcroft/hipparch/pricing.html Bob >Regards >Ingemar > >-----Original Message----- >From: Bob Briscoe [mailto:bob.briscoe@bt.com] >Sent: den 13 mars 2011 20:37 >To: Nandita Dukkipati >Cc: ConEx IETF list >Subject: [conex] Notes of Nandita's original (Jul'10) review of ConEx > >Snip-snip... > >==3/ A useful(?) analogy== > >* Weight inflation - motivates congestion-volume > >If n users are sharing a bottleneck, they send the same volume >whether each uses 1 TCP, or each uses 10 TCPs (ie weight=10). But >the overall congestion is roughly 100 times greater in the latter case. >Like monetary inflation, everyone increasing their weights just >reduces the value of weight. Weighting ends up achieving nothing, >but causing more and more harm. > >With only volume, not congestion-volume, as a metric, there will be >no incentive or ability to push back against this inflationary pressure. ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Mon Mar 14 10:57:12 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08FAE3A6E15 for ; Mon, 14 Mar 2011 10:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.386 X-Spam-Level: X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LWgICcgPbGQ for ; Mon, 14 Mar 2011 10:57:10 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 6F4CE3A6A3A for ; Mon, 14 Mar 2011 10:57:10 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 17:58: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); Mon, 14 Mar 2011 17:58: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 1300125518739; Mon, 14 Mar 2011 17:58:38 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.16.199]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p2EHwU6W019319; Mon, 14 Mar 2011 17:58:31 GMT Message-Id: <201103141758.p2EHwU6W019319@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 14 Mar 2011 17:58:22 +0000 To: Georgios Karagiannis From: Bob Briscoe In-Reply-To: References: <201103140142.p2E1gtsp016131@bagheera.jungle.bt.co.uk> 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 Mar 2011 17:58:33.0809 (UTC) FILETIME=[6F625C10:01CBE271] Cc: 'ConEx IETF list' Subject: Re: [conex] comments on draft-ietf-conex-abstract-mech-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 17:57:12 -0000 Georgios, I think you've misunderstood. Network nodes like Q1, Q2 & Q3 don't mark packets with the ConEx codes. I hope the doc makes it clear (I just read it over and it seemed clear) that only the source sets ConEx markings, which then remain immutable through the network. Bob At 16:57 14/03/2011, Georgios Karagiannis wrote: >Hi Bob, Hi Matt > >I have read the draft-ietf-conex-abstract-mech-00 draft. The concept >desribed in >this draft is very interesting. However, I have a comment related to the >measurement >of the congestion rate at the receiver side. I think that there is a >possible >accuracy problem related to the measurement of the congestion rate at the >receiver >side. This problem occurs when multiple ConEx nodes that are located on the >same >communication path are congested and therefore, marked packets might be >dropped. > >This problem, see below Figure is identified within the context of PCN and >is denoted as >the multiple bottlenecks problem in the PCN domain, see e.g., Section B.4 in >[RFC5670]. >In particular, consider that the nodes Q1, Q2 and Q3 are all congested. This >means that >Q1, Q2 and Q3 will start marking the packets with the Re-Echo-ECN ConEx >code. Due to >the fact that Q2 and Q3 are also congested, it could mean that Re-Echo-ECN >packets that were marked by Q1 might be dropped. This might result in the >fact that >the measured Congestion-rate at the receiver R, related to a flow, might not >be >accurate enough. > > +---+ +----+ +----+ +----+ +---+ > | S |--| Q1 |---| Q2 |---------| Q3 |--| R | > +---+ +----+ +----+ +----+ +---+ > ^ ^ ^ > | | | > Congested Congested Congested > > > >A possible solution to this measurement accuracy problem is that in >congestion situations >the receiver measures for each flow the Throughput instead of measuring the >congestion >rate. In congestion situations the measured Throughput at the receiver is >sent periodically >as feedback to the sender, see below Figure. Throughput can be defined as >the instantaneous >rate of traffic measured at one receiver that is (1) belonging to the same >flow, (2) that is >Not-Re-Echo-ECN marked and (3) is sent by the same sender. > >The sender always measures the Incoming rate associated with a flow. The >Incoming rate is >the instantaneous rate of traffic that is belonging to the same flow and is >sent by a sender towards >the same receiver. >In order to calculate the Congestion rate, the sender subtracts the >Troughput from the >Incoming rate. > >Using this calculated Congestion rate, the sender calculates the Congestion >exposure signal >using the same method as described in draft-ietf-conex-abstract-mech-00. > > 123456789012345678901234567890123456789012345678901234567890123456789 > +---------+ +---------+ > | |<==Feedback Path==============================<| | > | |<----------returned throughput ---------------<| | > | | | | > |Transport| |Transport| > | Sender |>---------(new)-IP layer ConEx Signal--------->| Receiver| > | | (Carried in Data Packet Headers) | | > | | +-----------+ | | > | |>=Data=Path=>|(Congested)|>=====Data=Path=====>| | > | | | Network |>-Congestion-Signal->| | > | | | Device | | | > +---------+ +-----------+ +---------+ > > Overview ConEx architecture with throughput feedback > > >In order to describe this possible accuracy problem on the measurement of >the congestion rate >and its solutions I have made an Internet draft that I would like to submit >once the IETF submission >possibility opens again! > >A preversion of this Internet draft can be found under: >http://wwwhome.cs.utwente.nl/~karagian/conex/draft-karagiannis-conex-through >put-exposure-00_not_published.txt > >Best regards, >Georgios ________________________________________________________________ Bob Briscoe, BT Innovate & Design From ingemar.s.johansson@ericsson.com Mon Mar 14 12:45:12 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13D9C3A6EBA for ; Mon, 14 Mar 2011 12:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxJqwsKfZnpO for ; Mon, 14 Mar 2011 12:45:09 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 01CC73A6E5C for ; Mon, 14 Mar 2011 12:45:06 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-bc-4d7e70959d62 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 30.EB.09202.5907E7D4; Mon, 14 Mar 2011 20:46:30 +0100 (CET) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.230]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 14 Mar 2011 20:46:29 +0100 From: Ingemar Johansson S To: Bob Briscoe Date: Mon, 14 Mar 2011 20:46:28 +0100 Thread-Topic: [conex] Notes of Nandita's original (Jul'10) review of ConEx Thread-Index: AcvicC/3GxDk/H+SRRGQcgPTWZ4vyQADqacd Message-ID: References: <201103131937.p2DJbli2015340@bagheera.jungle.bt.co.uk> , <201103141749.p2EHnYHl019263@bagheera.jungle.bt.co.uk> In-Reply-To: <201103141749.p2EHnYHl019263@bagheera.jungle.bt.co.uk> Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: ConEx IETF list Subject: Re: [conex] Notes of Nandita's original (Jul'10) review of ConEx X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 19:45:12 -0000 Hi Found the paper thanks !(the link is broken though).=20 I believe that it answers the first part, however I am looking for a bit mo= re explanation to=20 "With only volume, not congestion-volume, as a metric, there will be no incentive or ability to push back against this inflationary pressure" I believe I can buy the argument but it would be good to see a better expla= nation somewhere. Also, what about policing of bitrate ? Regards Ingemar =20 ________________________________________ Fr=E5n: Bob Briscoe [bob.briscoe@bt.com] Skickat: den 14 mars 2011 18:49 Till: Ingemar Johansson S Kopia: ConEx IETF list; Nandita Dukkipati =C4mne: RE: [conex] Notes of Nandita's original (Jul'10) review of ConEx Ingemar, At 13:15 14/03/2011, Ingemar Johansson S wrote: >Hi Bob and others > >I am interested in some more explanation to the weight-inflation >argument. Is there any document that describes this in more detail ? I think there might have been a mention of it in Jon Crowcroft's paper on MulTCP. However, you get the same effect whether you use n TCPs or MulTCP with the parameter set to n. It's basically a simple argument. If everyone is pushing to get through a narrow gap, the speed they get through is always the same, whether they all push hard, or whether they all don't. The only outcome of all pushing harder is to cause more bruises. With TCP, the square root relation between window & congestion means that if you try to push 10x more TCPs through the same gap, congestion increases to reduce everyone's window to 1/10 of before. So by the TCP equation, congestion will have to be 100x greater (in theory)= . Does that help? Crowcroft, J. & Oechslin, P., "Differentiated End to End Internet Services using a Weighted Proportional Fair Sharing TCP," Computer Communication Review 28(3):53--69 In: April Vol.28 No.3 pp.53-69 ACM (July 1998) URL: ftp://cs.ucl.ac.uk/darpa/multcp.ps.gz or http://www.cs.ucl.ac.uk/staff/J.Crowcroft/hipparch/pricing.html Bob >Regards >Ingemar > >-----Original Message----- >From: Bob Briscoe [mailto:bob.briscoe@bt.com] >Sent: den 13 mars 2011 20:37 >To: Nandita Dukkipati >Cc: ConEx IETF list >Subject: [conex] Notes of Nandita's original (Jul'10) review of ConEx > >Snip-snip... > >=3D=3D3/ A useful(?) analogy=3D=3D > >* Weight inflation - motivates congestion-volume > >If n users are sharing a bottleneck, they send the same volume >whether each uses 1 TCP, or each uses 10 TCPs (ie weight=3D10). But >the overall congestion is roughly 100 times greater in the latter case. >Like monetary inflation, everyone increasing their weights just >reduces the value of weight. Weighting ends up achieving nothing, >but causing more and more harm. > >With only volume, not congestion-volume, as a metric, there will be >no incentive or ability to push back against this inflationary pressure. ________________________________________________________________ Bob Briscoe, BT Innovate & Design From karagian@cs.utwente.nl Mon Mar 14 13:11:10 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DB803A6B79 for ; Mon, 14 Mar 2011 13:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.892 X-Spam-Level: X-Spam-Status: No, score=0.892 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWF-n+Ih0ae7 for ; Mon, 14 Mar 2011 13:11:09 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id B9DA43A6808 for ; Mon, 14 Mar 2011 13:11:08 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p2EKCECr005730; Mon, 14 Mar 2011 21:12:14 +0100 (MET) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Mon, 14 Mar 2011 20:12:15 +0000 To: "Bob Briscoe" Date: Mon, 14 Mar 2011 20:12:15 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <201103141758.p2EHwU6W019319@bagheera.jungle.bt.co.uk> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 14 Mar 2011 21:12:25 +0100 (MET) Cc: 'ConEx IETF list' Subject: Re: [conex] comments on draft-ietf-conex-abstract-mech-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 20:11:10 -0000 Hi Bob Thanks for the reply! You are right, I misunderstood the fact that all the CoNex codes can only be set by the sender. Can you please explain in the text that the Congestion-Signal shown in Figure 1 is not a ConEx signal, but an ECN marked packet. What I actually mean is that the multiple bottlenecks accuracy problem can occur on measuring the congestion rate using the Congestion-Signal (e.g., ECN signal), shown in Figure 1. Taking this into account then the nodes Q1, Q2, and Q3 shown in my example will represent three Congested Network devices. In order to be sure that I understood the concept correctly, can you please inform me which node is measuring the Congestion rate. Is it the sender by measuring the feedback signals sent by TCP Acks, or is it the Receiver? Can you please make this clear in the draft? In my explanation of the accuracy problem caused by multiple bottlenecks, I assumed that the Receiver is measuring the Congestion rate, which is then sent back to the sender using the feedback signal. Thus to be clear, if the Sender calculates the congestion rate using the TCP Acks received, then the accuracy problem caused by multiple bottlenecks might not occur, since the Sender will be able to count the number of ECN marked packets as well as the lost packets. However, if another type of transport protocol is used, e.g., UDP, then my comment on the acuracy problem on measuring the congestion rate at the Receiver will apply. Best regards, Georgios On 3/14/2011, "Bob Briscoe" wrote: >Georgios, > >I think you've misunderstood. Network nodes like Q1, Q2 & Q3 don't >mark packets with the ConEx codes. > >I hope the doc makes it clear (I just read it over and it seemed >clear) that only the source sets ConEx markings, which then remain >immutable through the network. > > >Bob > >At 16:57 14/03/2011, Georgios Karagiannis wrote: >>Hi Bob, Hi Matt >> >>I have read the draft-ietf-conex-abstract-mech-00 draft. The concept >>desribed in >>this draft is very interesting. However, I have a comment related to the >>measurement >>of the congestion rate at the receiver side. I think that there is a >>possible >>accuracy problem related to the measurement of the congestion rate at the >>receiver >>side. This problem occurs when multiple ConEx nodes that are located on the >>same >>communication path are congested and therefore, marked packets might be >>dropped. >> >>This problem, see below Figure is identified within the context of PCN and >>is denoted as >>the multiple bottlenecks problem in the PCN domain, see e.g., Section B.4 i= n >>[RFC5670]. >>In particular, consider that the nodes Q1, Q2 and Q3 are all congested. Thi= s >>means that >>Q1, Q2 and Q3 will start marking the packets with the Re-Echo-ECN ConEx >>code. Due to >>the fact that Q2 and Q3 are also congested, it could mean that Re-Echo-ECN >>packets that were marked by Q1 might be dropped. This might result in the >>fact that >>the measured Congestion-rate at the receiver R, related to a flow, might no= t >>be >>accurate enough. >> >> +---+ +----+ +----+ +----+ +---+ >> | S |--| Q1 |---| Q2 |---------| Q3 |--| R | >> +---+ +----+ +----+ +----+ +---+ >> ^ ^ ^ >> | | | >> Congested Congested Congested >> >> >> >>A possible solution to this measurement accuracy problem is that in >>congestion situations >>the receiver measures for each flow the Throughput instead of measuring the >>congestion >>rate. In congestion situations the measured Throughput at the receiver is >>sent periodically >>as feedback to the sender, see below Figure. Throughput can be defined as >>the instantaneous >>rate of traffic measured at one receiver that is (1) belonging to the same >>flow, (2) that is >>Not-Re-Echo-ECN marked and (3) is sent by the same sender. >> >>The sender always measures the Incoming rate associated with a flow. The >>Incoming rate is >>the instantaneous rate of traffic that is belonging to the same flow and is >>sent by a sender towards >>the same receiver. >>In order to calculate the Congestion rate, the sender subtracts the >>Troughput from the >>Incoming rate. >> >>Using this calculated Congestion rate, the sender calculates the Congestion >>exposure signal >>using the same method as described in draft-ietf-conex-abstract-mech-00. >> >> 123456789012345678901234567890123456789012345678901234567890123456789 >> +---------+ +---------+ >> | |<=3D=3DFeedback Path=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<| | >> | |<----------returned throughput ---------------<| | >> | | | | >> |Transport| |Transport| >> | Sender |>---------(new)-IP layer ConEx Signal--------->| Receiver| >> | | (Carried in Data Packet Headers) | | >> | | +-----------+ | | >> | |>=3DData=3DPath=3D>|(Congested)|>=3D=3D=3D=3D=3DData=3DPath= =3D=3D=3D=3D=3D>| | >> | | | Network |>-Congestion-Signal->| | >> | | | Device | | | >> +---------+ +-----------+ +---------+ >> >> Overview ConEx architecture with throughput feedback >> >> >>In order to describe this possible accuracy problem on the measurement of >>the congestion rate >>and its solutions I have made an Internet draft that I would like to submit >>once the IETF submission >>possibility opens again! >> >>A preversion of this Internet draft can be found under: >>http://wwwhome.cs.utwente.nl/~karagian/conex/draft-karagiannis-conex-throug= h >>put-exposure-00_not_published.txt >> >>Best regards, >>Georgios > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design From toby@moncaster.com Mon Mar 14 14:26:21 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB8063A6826 for ; Mon, 14 Mar 2011 14:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRciCqtECkEv for ; Mon, 14 Mar 2011 14:26:19 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id 944403A6BB9 for ; Mon, 14 Mar 2011 14:26:18 -0700 (PDT) Received: from TobysHP (host86-143-221-235.range86-143.btcentralplus.com [86.143.221.235]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MMaaI-1Pr0lf0j1i-008Sxi; Mon, 14 Mar 2011 22:27:41 +0100 From: "Toby Moncaster" To: Date: Mon, 14 Mar 2011 21:27:41 -0000 Message-ID: <005701cbe28e$a6e85af0$f4b910d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcvijqYsvcIBJyLUTrykAQE52Xa/qg== Content-Language: en-gb X-Provags-ID: V02:K0:UvI2aUGtnn7C4Sz2ehnI8w+vzGokdhScfVk6CBTMIoe 9q5SZWVmnxOZuld56Q1jihulFKJg4JnRbhre2U0o4PofYR4bJt NkCCwZDa0+6KFDgUIdJmGi4Zvwp3YHlQAl3sB70KsKNhDpNcAd mDsCvYL3W5/MoU6+dhnfp0IDajMeVHsi5phcOUxTkDakSLc/pd ScP4ct3BRDIsTrQEVSF9TnKPZfxcQ2V8wv3HypmAKk= Subject: [conex] draft-ietf-conex-concepts-uses-01 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 21:26:21 -0000 Hi All, I have just posted the latest version of the use cases document. Most of the editing/authoring energy this cycle has gone on the new section on measuring congestion over longer timescales. Consequently we haven't managed to do the alignment of terminology between this draft and the abstract mechanism. Diffs are at: The key section needing review is the new one on timescales. This is quite an extensive addition to the draft and adds some new concepts. It is likely that the section will become more streamlined once it has had a full round of comments/editing and the authors would welcome any feedback... We also received some feedback that the use case on differential QoS was potentially confusing. I hope to work on this before the next revision as I can see that this might be a hard idea to grasp (not least since it runs counter to the idea that QoS comes from the network). Toby From Internet-Drafts@ietf.org Mon Mar 14 14:30:10 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFEE43A6F1B; Mon, 14 Mar 2011 14:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OAeiIMo8R3D; Mon, 14 Mar 2011 14:30:05 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15F323A6F59; Mon, 14 Mar 2011 14:30:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314213003.22459.60711.idtracker@localhost> Date: Mon, 14 Mar 2011 14:30:03 -0700 Cc: conex@ietf.org Subject: [conex] I-D Action:draft-ietf-conex-concepts-uses-01.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 21:30:10 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion Exposure Working Group of the IETF. Title : ConEx Concepts and Use Cases Author(s) : T. Moncaster, et al. Filename : draft-ietf-conex-concepts-uses-01.txt Pages : 23 Date : 2011-03-14 Internet Service Providers (operators) are facing problems where localized congestion prevents full utilization of the path between sender and receiver at today's "broadband" speeds. Operators desire to control this congestion, which often appears to be caused by a small number of users consuming a large amount of bandwidth. Building out more capacity along all of the path to handle this congestion can be expensive and may not result in improvements for all users so network operators have sought other ways to manage congestion. The current mechanisms all suffer from difficulty measuring the congestion (as distinguished from the total traffic). The ConEx Working Group is designing a mechanism to make congestion along any path visible at the Internet Layer. This document describes example cases where this mechanism would be useful. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-conex-concepts-uses-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-conex-concepts-uses-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14141909.I-D@ietf.org> --NextPart-- From bob.briscoe@bt.com Mon Mar 14 14:30:21 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A6E93A6BC0 for ; Mon, 14 Mar 2011 14:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.395 X-Spam-Level: X-Spam-Status: No, score=-3.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXn-FbcfNos8 for ; Mon, 14 Mar 2011 14:30:20 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 74D833A6F99 for ; Mon, 14 Mar 2011 14:30:18 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 21:31:41 +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, 14 Mar 2011 21:31:41 +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 1300138306620; Mon, 14 Mar 2011 21:31:46 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.176.143]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p2ELVbrR020030; Mon, 14 Mar 2011 21:31:38 GMT Message-Id: <201103142131.p2ELVbrR020030@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 14 Mar 2011 21:31:28 +0000 To: Ingemar Johansson S From: Bob Briscoe In-Reply-To: References: <201103131937.p2DJbli2015340@bagheera.jungle.bt.co.uk> <201103141749.p2EHnYHl019263@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 14 Mar 2011 21:31:41.0171 (UTC) FILETIME=[353EF430:01CBE28F] Cc: ConEx IETF list Subject: Re: [conex] Notes of Nandita's original (Jul'10) review of ConEx X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 21:30:21 -0000 Ingemar, At 19:46 14/03/2011, Ingemar Johansson S wrote: >Hi > >Found the paper thanks !(the link is broken though). > >I believe that it answers the first part,=20 >however I am looking for a bit more explanation to >"With only volume, not congestion-volume, as a metric, there will be > no incentive or ability to push back against this inflationary pressure" Well, the scenario is artificial but designed to=20 illustrate a point. The users all have the same=20 volume to send. If they divide it over 10 TCPs=20 each, they still transfer the same volume, but=20 cause 100x more congestion in the process. So if they are volume capped it will make no=20 difference to them whether they transfer using 10=20 TCPs or 1. But if they are congestion-volume=20 capped, they will avoid using multiple TCPs=20 unless they really need to go fast (sufficiently=20 to be willing to use up their quota). >I believe I can buy the argument but it would be=20 >good to see a better explanation somewhere. >Also, what about policing of bitrate ? Again, the scenario is designed to illustrate=20 that they all get the same bit-rate whether they=20 all use 1 TCP or 10. So none of them get any more=20 bit-rate than the others in either case. Bob >Regards >Ingemar > > >________________________________________ >Fr=E5n: Bob Briscoe [bob.briscoe@bt.com] >Skickat: den 14 mars 2011 18:49 >Till: Ingemar Johansson S >Kopia: ConEx IETF list; Nandita Dukkipati >=C4mne: RE: [conex] Notes of Nandita's original (Jul'10) review of ConEx > >Ingemar, > >At 13:15 14/03/2011, Ingemar Johansson S wrote: > >Hi Bob and others > > > >I am interested in some more explanation to the weight-inflation > >argument. Is there any document that describes this in more detail ? > >I think there might have been a mention of it in Jon Crowcroft's >paper on MulTCP. However, you get the same effect whether you use n >TCPs or MulTCP with the parameter set to n. > >It's basically a simple argument. If everyone is pushing to get >through a narrow gap, the speed they get through is always the same, >whether they all push hard, or whether they all don't. The only >outcome of all pushing harder is to cause more bruises. > >With TCP, the square root relation between window & congestion means >that if you try to push 10x more TCPs through the same gap, >congestion increases to reduce everyone's window to 1/10 of before. >So by the TCP equation, congestion will have to be 100x greater (in= theory). > >Does that help? > > >Crowcroft, J. & Oechslin, P., "Differentiated End to End Internet >Services using a Weighted Proportional Fair Sharing TCP," Computer >Communication Review 28(3):53--69 In: April Vol.28 No.3 pp.53-69 ACM >(July 1998) URL: ftp://cs.ucl.ac.uk/darpa/multcp.ps.gz or >http://www.cs.ucl.ac.uk/staff/J.Crowcroft/hipparch/pricing.html > >Bob > > > >Regards > >Ingemar > > > >-----Original Message----- > >From: Bob Briscoe [mailto:bob.briscoe@bt.com] > >Sent: den 13 mars 2011 20:37 > >To: Nandita Dukkipati > >Cc: ConEx IETF list > >Subject: [conex] Notes of Nandita's original (Jul'10) review of ConEx > > > >Snip-snip... > > > >=3D=3D3/ A useful(?) analogy=3D=3D > > > >* Weight inflation - motivates congestion-volume > > > >If n users are sharing a bottleneck, they send the same volume > >whether each uses 1 TCP, or each uses 10 TCPs (ie weight=3D10). But > >the overall congestion is roughly 100 times greater in the latter case. > >Like monetary inflation, everyone increasing their weights just > >reduces the value of weight. Weighting ends up achieving nothing, > >but causing more and more harm. > > > >With only volume, not congestion-volume, as a metric, there will be > >no incentive or ability to push back against this inflationary pressure. > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 From bob.briscoe@bt.com Mon Mar 14 15:56:16 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBFC13A6BCB for ; Mon, 14 Mar 2011 15:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.404 X-Spam-Level: X-Spam-Status: No, score=-3.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHlKjJ8ggiOl for ; Mon, 14 Mar 2011 15:56:14 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id EE6643A6D34 for ; Mon, 14 Mar 2011 15:56:13 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 22:57:36 +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, 14 Mar 2011 22:57:36 +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 1300143461643; Mon, 14 Mar 2011 22:57:41 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.176.143]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p2EMvWn4020302; Mon, 14 Mar 2011 22:57:33 GMT Message-Id: <201103142257.p2EMvWn4020302@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 14 Mar 2011 22:55:27 +0000 To: Georgios Karagiannis From: Bob Briscoe In-Reply-To: References: <201103141758.p2EHwU6W019319@bagheera.jungle.bt.co.uk> 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 Mar 2011 22:57:36.0709 (UTC) FILETIME=[362F9F50:01CBE29B] Cc: 'ConEx IETF list' Subject: Re: [conex] comments on draft-ietf-conex-abstract-mech-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 22:56:16 -0000 Georgios, Whoa! You're trying to correct something that is actually already correct. You are mistakenly thinking it's wrong. When an ECN marked packet is dropped by another congested node downstream, certainly one of the two congestion events is missed, but that is what makes the congestion measurement *accurate*, not an inaccuracy that needs correcting. Explanation: * Congestion at one node is defined as the probability that it will not serve a packet (or will not serve a packet without ECN-marking it). * End-to-end congestion is defined as the probability that a packet will not get through the whole path (or not get through unmarked), which is the combinatorial probability of it not being served by each node on the path (or not being served without ECN marking). So if Q1, Q2, Q3 = 1%, 0% 2% respectively (whether loss or ECN on each node), then e2e congestion p is defined as: p = 1 - (1-Q1)(1-Q2)(1-Q3) = 1 - 0.99*1*0.98 = 2.98% Importantly, p != Q1 + Q2 + Q3 != 3% IOW, it's not correct to try to ensure that e2e congestion = 3%, because that's not the probability that a packet will not get through (or not get through unmarked). The right answer is meant to be 2.98% Similarly, it would be incorrect to try to measure both congestion events when one packet gets marked then lost, or marked then marked again. It's the small probability that these multiple congestion events will happen to one packet that makes the correct answer 2.98% rather than 3%. So it is correct that congestion is detected by the transport (the receiver and sender together) as either loss or ECN. If a CE marked packet is dropped, congestion will still be detected as a loss. -------------------------------------------------------------------------- ConEx merely builds on the pre-existing congestion detection capability of Internet transports. Whether they are accurate or not (they are actually accurate) the idea is merely for the transport to tell the network what it knows. Even if a transport wasn't accurate, I'm not interested in changing a transport protocol to make it slightly more accurate, before it reports congestion with ConEx. Bob At 20:12 14/03/2011, Georgios Karagiannis wrote: >Hi Bob > >Thanks for the reply! > >You are right, I misunderstood the fact that all the CoNex codes can only >be set by the sender. Can you please explain in the text that the >Congestion-Signal shown in Figure 1 is not a ConEx signal, but an ECN >marked packet. > >What I actually mean is that the multiple bottlenecks accuracy problem >can occur on measuring the congestion rate using the Congestion-Signal >(e.g., ECN signal), shown in Figure 1. Taking this into account then the >nodes Q1, Q2, and Q3 shown in my example will represent three Congested >Network devices. > >In order to be sure that I understood the concept correctly, can you >please inform me which node is measuring the Congestion rate. Is it the >sender by measuring the feedback signals sent by TCP Acks, or is it the >Receiver? > >Can you please make this clear in the draft? > >In my explanation of the accuracy problem caused by multiple bottlenecks, >I assumed that the Receiver is measuring the Congestion rate, which is >then sent back to the sender using the feedback signal. > >Thus to be clear, if the Sender calculates the congestion rate using the >TCP Acks received, then the accuracy problem caused by multiple >bottlenecks might not occur, since the Sender will be able to count the >number of ECN marked packets as well as the lost packets. > >However, if another type of transport protocol is used, e.g., UDP, then >my comment on the acuracy problem on measuring the congestion rate at >the Receiver will apply. > > >Best regards, >Georgios > >On 3/14/2011, "Bob Briscoe" wrote: > > >Georgios, > > > >I think you've misunderstood. Network nodes like Q1, Q2 & Q3 don't > >mark packets with the ConEx codes. > > > >I hope the doc makes it clear (I just read it over and it seemed > >clear) that only the source sets ConEx markings, which then remain > >immutable through the network. > > > > > >Bob > > > >At 16:57 14/03/2011, Georgios Karagiannis wrote: > >>Hi Bob, Hi Matt > >> > >>I have read the draft-ietf-conex-abstract-mech-00 draft. The concept > >>desribed in > >>this draft is very interesting. However, I have a comment related to the > >>measurement > >>of the congestion rate at the receiver side. I think that there is a > >>possible > >>accuracy problem related to the measurement of the congestion rate at the > >>receiver > >>side. This problem occurs when multiple ConEx nodes that are located on the > >>same > >>communication path are congested and therefore, marked packets might be > >>dropped. > >> > >>This problem, see below Figure is identified within the context of PCN and > >>is denoted as > >>the multiple bottlenecks problem in the PCN domain, see e.g., > Section B.4 in > >>[RFC5670]. > >>In particular, consider that the nodes Q1, Q2 and Q3 are all > congested. This > >>means that > >>Q1, Q2 and Q3 will start marking the packets with the Re-Echo-ECN ConEx > >>code. Due to > >>the fact that Q2 and Q3 are also congested, it could mean that Re-Echo-ECN > >>packets that were marked by Q1 might be dropped. This might result in the > >>fact that > >>the measured Congestion-rate at the receiver R, related to a > flow, might not > >>be > >>accurate enough. > >> > >> +---+ +----+ +----+ +----+ +---+ > >> | S |--| Q1 |---| Q2 |---------| Q3 |--| R | > >> +---+ +----+ +----+ +----+ +---+ > >> ^ ^ ^ > >> | | | > >> Congested Congested Congested > >> > >> > >> > >>A possible solution to this measurement accuracy problem is that in > >>congestion situations > >>the receiver measures for each flow the Throughput instead of measuring the > >>congestion > >>rate. In congestion situations the measured Throughput at the receiver is > >>sent periodically > >>as feedback to the sender, see below Figure. Throughput can be defined as > >>the instantaneous > >>rate of traffic measured at one receiver that is (1) belonging to the same > >>flow, (2) that is > >>Not-Re-Echo-ECN marked and (3) is sent by the same sender. > >> > >>The sender always measures the Incoming rate associated with a flow. The > >>Incoming rate is > >>the instantaneous rate of traffic that is belonging to the same flow and is > >>sent by a sender towards > >>the same receiver. > >>In order to calculate the Congestion rate, the sender subtracts the > >>Troughput from the > >>Incoming rate. > >> > >>Using this calculated Congestion rate, the sender calculates the Congestion > >>exposure signal > >>using the same method as described in draft-ietf-conex-abstract-mech-00. > >> > >> 123456789012345678901234567890123456789012345678901234567890123456789 > >> +---------+ +---------+ > >> | |<==Feedback Path==============================<| | > >> | |<----------returned throughput ---------------<| | > >> | | | | > >> |Transport| |Transport| > >> | Sender |>---------(new)-IP layer ConEx Signal--------->| Receiver| > >> | | (Carried in Data Packet Headers) | | > >> | | +-----------+ | | > >> | |>=Data=Path=>|(Congested)|>=====Data=Path=====>| | > >> | | | Network |>-Congestion-Signal->| | > >> | | | Device | | | > >> +---------+ +-----------+ +---------+ > >> > >> Overview ConEx architecture with throughput feedback > >> > >> > >>In order to describe this possible accuracy problem on the measurement of > >>the congestion rate > >>and its solutions I have made an Internet draft that I would like to submit > >>once the IETF submission > >>possibility opens again! > >> > >>A preversion of this Internet draft can be found under: > >>http://wwwhome.cs.utwente.nl/~karagian/conex/draft-karagiannis-con > ex-through > >>put-exposure-00_not_published.txt > >> > >>Best regards, > >>Georgios > > > >________________________________________________________________ > >Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design From Internet-Drafts@ietf.org Mon Mar 14 16:00:07 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CED843A6FD7; Mon, 14 Mar 2011 16:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTT9q0rkKS04; Mon, 14 Mar 2011 16:00:03 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A899D3A6FF0; Mon, 14 Mar 2011 16:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314230002.28547.97880.idtracker@localhost> Date: Mon, 14 Mar 2011 16:00:02 -0700 Cc: conex@ietf.org Subject: [conex] I-D ACTION:draft-ietf-conex-abstract-mech-01.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 23:00:07 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion Exposure Working Group of the IETF. Title : Congestion Exposure (ConEx) Concepts and Abstract Mechanism Author(s) : M. Mathis, et al Filename : draft-ietf-conex-abstract-mech-01.txt Pages : 18 Date : 2011-03-14 This document describes an abstract mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. Today, the network may signal congestion to the receiver by ECN markings or by dropping packets, and the receiver passes this information back to the sender in transport-layer feedback. The mechanism to be developed by the ConEx WG will enable the sender to also relay this congestion information back into the network in-band at the IP layer, such that the total level of congestion is visible to all IP devices along the path, from where it could, for example, provide input to traffic management. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-conex-abstract-mech-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-conex-abstract-mech-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14155439.I-D@ietf.org> --NextPart-- From nanditad@google.com Mon Mar 14 18:02:22 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E0FB3A696C for ; Mon, 14 Mar 2011 18:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMQ8KrUeIofh for ; Mon, 14 Mar 2011 18:02:21 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id DFD173A6D6D for ; Mon, 14 Mar 2011 18:02:20 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id p2F13bZr004732 for ; Mon, 14 Mar 2011 18:03:37 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1300151024; bh=iwPeSCIeO3qDwWlqOvy0GiXUokE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=h/g0VCQS9wLsPTwPL8+mFU1Tcg4YprBoAXii4Hyxm19xgKAm3sOENYROmMHVJFloa bCnTfnNkO4syNGyvc8wDw== Received: from yic13 (yic13.prod.google.com [10.243.65.141]) by hpaq6.eem.corp.google.com with ESMTP id p2F13PPP029347 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 14 Mar 2011 18:03:36 -0700 Received: by yic13 with SMTP id 13so40066yic.3 for ; Mon, 14 Mar 2011 18:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WrOaqYHVBK+QNHQuKnebvu/qhu9u+g0wd/yzhlS6Ltc=; b=p3qQ+nt55s1oiYANQPyj5CouksFbq/fLpnPwcustXsNzt0Zacx2NEQkMBeGKPcDZAd LAzCrrwkKu7faU4l0OKA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=m4LJdCt2hmPGNllldPvSVLjO7xf1geIt/u5gip8VY3G4XtKzlnoxySNLbWPx71/S7Y 9/lcooby9IplKzwZfdog== MIME-Version: 1.0 Received: by 10.90.136.14 with SMTP id j14mr3950672agd.154.1300151000025; Mon, 14 Mar 2011 18:03:20 -0700 (PDT) Received: by 10.91.211.15 with HTTP; Mon, 14 Mar 2011 18:03:19 -0700 (PDT) In-Reply-To: <201103140142.p2E1gtsp016131@bagheera.jungle.bt.co.uk> References: <201103101111.p2ABBw8f029651@bagheera.jungle.bt.co.uk> <7.1.0.9.2.20110311220539.058ede38@bt.com> <201103140142.p2E1gtsp016131@bagheera.jungle.bt.co.uk> Date: Mon, 14 Mar 2011 18:03:19 -0700 Message-ID: From: Nandita Dukkipati To: Bob Briscoe Content-Type: multipart/alternative; boundary=00163628354e82ca52049e7afe37 X-System-Of-Record: true Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-abstract-mech-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 01:02:22 -0000 --00163628354e82ca52049e7afe37 Content-Type: text/plain; charset=ISO-8859-1 > > Thinking more about where partial deployment text should go... > > There are four different aspects to partial deployment: > 1. ConEx and/or non-ConEx packets (abstract-mech: encoding) > 2. ConEx and/or non-ConEx receivers (abstract-mech: ConEx Components) > 3. Interwork with loss and/or ECN queues (abstract-mech: encoding & reqs) > 4. Some networks use ConEx signals, others don't (concepts-uses). > > abstract-mech isn't a natural home for #4 because it's not designed to talk > about why a network would want to use ConEx. It doesn't even mention > networks as autonomous from each other. This is all the territory of > concepts-uses. > Yes, agree that #4 does not belong to abstract-mech and the concepts-uses seems a better home for it. -Nandita --00163628354e82ca52049e7afe37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Thinking mo= re about where partial deployment text should go...

There are four different aspects to partial deployment:
1. ConEx and/or non-ConEx packets =A0=A0=A0=A0=A0=A0(abstract-mech: encoding)
2. ConEx and/or non-ConEx receivers =A0=A0=A0=A0(abstract-mech: ConEx Components)
3. Interwork with loss and/or ECN queues (abstract-mech: encoding & reqs)
4. Some networks use ConEx signals, others don't =A0=A0=A0=A0=A0=A0=A0(concepts-uses).

abstract-mech isn't a natural home for #4 because it's not designed= to talk about why a network would want to use ConEx. It doesn't even menti= on networks as autonomous from each other. This is all the territory of concepts-uses.

Yes, agree that #4= does not belong to abstract-mech and the concepts-uses seems a better home= for it.
=A0
-Nandita
--00163628354e82ca52049e7afe37-- From karagian@cs.utwente.nl Mon Mar 14 22:21:36 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997A63A6AEE for ; Mon, 14 Mar 2011 22:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.892 X-Spam-Level: X-Spam-Status: No, score=0.892 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avrkcmFateWM for ; Mon, 14 Mar 2011 22:21:34 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id 725763A6978 for ; Mon, 14 Mar 2011 22:21:34 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p2F5MdxF009900; Tue, 15 Mar 2011 06:22:40 +0100 (MET) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Tue, 15 Mar 2011 05:22:40 +0000 To: "Bob Briscoe" Date: Tue, 15 Mar 2011 05:22:39 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: <94DlGqg7.1300166559.3550600.karagian@ewi.utwente.nl> In-Reply-To: <201103142257.p2EMvWn4020302@bagheera.jungle.bt.co.uk> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 15 Mar 2011 06:22:51 +0100 (MET) Cc: 'ConEx IETF list' Subject: Re: [conex] comments on draft-ietf-conex-abstract-mech-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 05:21:36 -0000 Hi Bob Please see in line! On 3/14/2011, "Bob Briscoe" wrote: >Georgios, > >Whoa! You're trying to correct something that is actually already >correct. You are mistakenly thinking it's wrong. Georgios: Maybe it is correct, but the operation was not clear to me. Please note that I was talking about Congestion rate in my email. draft-ietf-conex-concepts-uses-01 defines Congestion rate as: Congestion-rate: For any granularity of traffic (packet, flow, aggregate, etc.), the instantaneous rate of traffic discarded or marked due to congestion. Conceptually, the instantaneous bit- rate of the traffic multiplied by the instantaneous congestion it is experiencing. As I already mentioned, my assumption was that the Receiver would measure the congestion rate and it will then report this to the Sender. From what I understood now is that the Receiver does not do that, but it just uses the reliability feature of TCP (combinated with ECN). Meaning that actually the Sender is measuring the Congestion rate (not the Receiver). Please note that I am not sure if it is clear in the current draft-ietf-conex-abstract-mech-01 text that the Sender is measuring the Congestion rate. As I already mentioned this situation can provide accurate measurements, since the Sender, using the TCP Ack can deduce whether a downstream packet was congested ECN marked or was dropped. Thus when a reliable transport protocol, like TCP, is used then the calculation of the Congestion rate at the Sender can be considered to be accurate enough. > >When an ECN marked packet is dropped by another congested node >downstream, certainly one of the two congestion events is missed, but >that is what makes the congestion measurement *accurate*, not an >inaccuracy that needs correcting. Georgios: Yes, assuming that the transport protocol is reliable and that the congstion rate is calculated at the Sender side. > >Explanation: >* Congestion at one node is defined as the probability that it will >not serve a packet (or will not serve a packet without ECN-marking it). >* End-to-end congestion is defined as the probability that a packet >will not get through the whole path (or not get through unmarked), >which is the combinatorial probability of it not being served by each >node on the path (or not being served without ECN marking). > >So if Q1, Q2, Q3 =3D 1%, 0% 2% respectively (whether loss or ECN on >each node), then e2e congestion p is defined as: > >p =3D 1 - (1-Q1)(1-Q2)(1-Q3) > =3D 1 - 0.99*1*0.98 > =3D 2.98% Georgios: Okay, assuming that these probabilities (on Q1, Q2, Q3) are independent of each other. > >Importantly, >p !=3D Q1 + Q2 + Q3 > !=3D 3% > >IOW, it's not correct to try to ensure that e2e congestion =3D 3%, >because that's not the probability that a packet will not get through >(or not get through unmarked). The right answer is meant to be 2.98% > Georgios: That was not my point! In my opinion, what it should be made clear in the draft is that CoNex should use a reliable transport protocol that caries feedback sgnals to the Sender. Based on these feedback signals, the Sender can accurately calculate the Congestion rate, since it can calculate the number of congested ECN marked packets on the downstream and as well as the number of packets that were dropped in the downstream direction. If the Congestion rate is calculated only at the Receiver (independent of the transport) protocol then this measurement can be inaccurate. >Similarly, it would be incorrect to try to measure both congestion >events when one packet gets marked then lost, or marked then marked >again. It's the small probability that these multiple congestion >events will happen to one packet that makes the correct answer 2.98% >rather than 3%. > >So it is correct that congestion is detected by the transport (the >receiver and sender together) as either loss or ECN. If a CE marked >packet is dropped, congestion will still be detected as a loss. Georgios: That was not my point, see above! > >-------------------------------------------------------------------------- > >ConEx merely builds on the pre-existing congestion detection >capability of Internet transports. Whether they are accurate or not >(they are actually accurate) the idea is merely for the transport to >tell the network what it knows. Georgios: Yes, assuming that the transport is reliable and is able to measure not only the congestion marked packets at the downstream direction, but also the dropped packets in the downstream direction. > >Even if a transport wasn't accurate, I'm not interested in changing a >transport protocol to make it slightly more accurate, before it >reports congestion with ConEx.=20 Georgios: Yes, but then the calculation of the Congestion rate and the use of the CoNex exposure signals in different use cases will be inaccurate. Best regards, Georgios > > >Bob > >At 20:12 14/03/2011, Georgios Karagiannis wrote: >>Hi Bob >> >>Thanks for the reply! >> >>You are right, I misunderstood the fact that all the CoNex codes can only >>be set by the sender. Can you please explain in the text that the >>Congestion-Signal shown in Figure 1 is not a ConEx signal, but an ECN >>marked packet. >> >>What I actually mean is that the multiple bottlenecks accuracy problem >>can occur on measuring the congestion rate using the Congestion-Signal >>(e.g., ECN signal), shown in Figure 1. Taking this into account then the >>nodes Q1, Q2, and Q3 shown in my example will represent three Congested >>Network devices. >> >>In order to be sure that I understood the concept correctly, can you >>please inform me which node is measuring the Congestion rate. Is it the >>sender by measuring the feedback signals sent by TCP Acks, or is it the >>Receiver? >> >>Can you please make this clear in the draft? >> >>In my explanation of the accuracy problem caused by multiple bottlenecks, >>I assumed that the Receiver is measuring the Congestion rate, which is >>then sent back to the sender using the feedback signal. >> >>Thus to be clear, if the Sender calculates the congestion rate using the >>TCP Acks received, then the accuracy problem caused by multiple >>bottlenecks might not occur, since the Sender will be able to count the >>number of ECN marked packets as well as the lost packets. >> >>However, if another type of transport protocol is used, e.g., UDP, then >>my comment on the acuracy problem on measuring the congestion rate at >>the Receiver will apply. >> >> >>Best regards, >>Georgios >> >>On 3/14/2011, "Bob Briscoe" wrote: >> >> >Georgios, >> > >> >I think you've misunderstood. Network nodes like Q1, Q2 & Q3 don't >> >mark packets with the ConEx codes. >> > >> >I hope the doc makes it clear (I just read it over and it seemed >> >clear) that only the source sets ConEx markings, which then remain >> >immutable through the network. >> > >> > >> >Bob >> > >> >At 16:57 14/03/2011, Georgios Karagiannis wrote: >> >>Hi Bob, Hi Matt >> >> >> >>I have read the draft-ietf-conex-abstract-mech-00 draft. The concept >> >>desribed in >> >>this draft is very interesting. However, I have a comment related to the >> >>measurement >> >>of the congestion rate at the receiver side. I think that there is a >> >>possible >> >>accuracy problem related to the measurement of the congestion rate at th= e >> >>receiver >> >>side. This problem occurs when multiple ConEx nodes that are located on = the >> >>same >> >>communication path are congested and therefore, marked packets might be >> >>dropped. >> >> >> >>This problem, see below Figure is identified within the context of PCN a= nd >> >>is denoted as >> >>the multiple bottlenecks problem in the PCN domain, see e.g., >> Section B.4 in >> >>[RFC5670]. >> >>In particular, consider that the nodes Q1, Q2 and Q3 are all >> congested. This >> >>means that >> >>Q1, Q2 and Q3 will start marking the packets with the Re-Echo-ECN ConEx >> >>code. Due to >> >>the fact that Q2 and Q3 are also congested, it could mean that Re-Echo-E= CN >> >>packets that were marked by Q1 might be dropped. This might result in th= e >> >>fact that >> >>the measured Congestion-rate at the receiver R, related to a >> flow, might not >> >>be >> >>accurate enough. >> >> >> >> +---+ +----+ +----+ +----+ +---+ >> >> | S |--| Q1 |---| Q2 |---------| Q3 |--| R | >> >> +---+ +----+ +----+ +----+ +---+ >> >> ^ ^ ^ >> >> | | | >> >> Congested Congested Congested >> >> >> >> >> >> >> >>A possible solution to this measurement accuracy problem is that in >> >>congestion situations >> >>the receiver measures for each flow the Throughput instead of measuring = the >> >>congestion >> >>rate. In congestion situations the measured Throughput at the receiver i= s >> >>sent periodically >> >>as feedback to the sender, see below Figure. Throughput can be defined a= s >> >>the instantaneous >> >>rate of traffic measured at one receiver that is (1) belonging to the sa= me >> >>flow, (2) that is >> >>Not-Re-Echo-ECN marked and (3) is sent by the same sender. >> >> >> >>The sender always measures the Incoming rate associated with a flow. The >> >>Incoming rate is >> >>the instantaneous rate of traffic that is belonging to the same flow and= is >> >>sent by a sender towards >> >>the same receiver. >> >>In order to calculate the Congestion rate, the sender subtracts the >> >>Troughput from the >> >>Incoming rate. >> >> >> >>Using this calculated Congestion rate, the sender calculates the Congest= ion >> >>exposure signal >> >>using the same method as described in draft-ietf-conex-abstract-mech-00. >> >> >> >> 12345678901234567890123456789012345678901234567890123456789012345678= 9 >> >> +---------+ +---------= + >> >> | |<=3D=3DFeedback Path=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<| | >> >> | |<----------returned throughput ---------------<| = | >> >> | | | = | >> >> |Transport| |Transport= | >> >> | Sender |>---------(new)-IP layer ConEx Signal--------->| Receiver= | >> >> | | (Carried in Data Packet Headers) | = | >> >> | | +-----------+ | = | >> >> | |>=3DData=3DPath=3D>|(Congested)|>=3D=3D=3D=3D=3DData=3DPa= th=3D=3D=3D=3D=3D>| | >> >> | | | Network |>-Congestion-Signal->| = | >> >> | | | Device | | = | >> >> +---------+ +-----------+ +---------= + >> >> >> >> Overview ConEx architecture with throughput feedback >> >> >> >> >> >>In order to describe this possible accuracy problem on the measurement o= f >> >>the congestion rate >> >>and its solutions I have made an Internet draft that I would like to sub= mit >> >>once the IETF submission >> >>possibility opens again! >> >> >> >>A preversion of this Internet draft can be found under: >> >>http://wwwhome.cs.utwente.nl/~karagian/conex/draft-karagiannis-con >> ex-through >> >>put-exposure-00_not_published.txt >> >> >> >>Best regards, >> >>Georgios >> > >> >________________________________________________________________ >> >Bob Briscoe, BT Innovate & Design > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design From mirja.kuehlewind@ikr.uni-stuttgart.de Tue Mar 15 03:27:29 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6EE63A6C63 for ; Tue, 15 Mar 2011 03:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+D2pO8Sgp-5 for ; Tue, 15 Mar 2011 03:27:29 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id D305B3A6C25 for ; Tue, 15 Mar 2011 03:27:28 -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 A8396633B6; Tue, 15 Mar 2011 11:28:48 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 983BC59A8A; Tue, 15 Mar 2011 11:28:48 +0100 (CET) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: "Mcdysan, David E" Date: Tue, 15 Mar 2011 11:28:47 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201103151128.48062.mkuehle@ikr.uni-stuttgart.de> Cc: "conex@ietf.org" Subject: Re: [conex] Proposed Text for New Section in Use Case Draft - Statistical multiplexing over Longer Timescales X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 10:27:29 -0000 Hi Dave, just a quick response to the in or out of scope discussion: > However, as a number of wg members have posted, shapers will cause effects > that will appear as congestion. > > I would like to see the wg agree on whether this either in or out of scope > -- you keep making the same point about scope. If you look at the list > several others have said this case at least needs to be described in the > draft, but have expressed concerns as to whether the complexity of adding > to the mechanism will justify the benefit. > > Can you please say more as to why you believe it is out of scope. I don't say shapers are out of scope. But I don't really see the special case about shapers. If they mark or drop a packet, I have to take it as a congestion signal because I anyway don't know what in the network and why it doing this... If you want an additional signaling for shaper congestion, I believe that is independent of ConEx. Its like having another kind of ECN signal. You can simply specify such an additional signaling protocol (every time in the future) and add a section how ConEx senders should react to it. I don't believe this will change the ConEx mechanism itself. But I'm open for a discussion here. But first of all we have to figure out if there is a special case about shapers. I still believe no. The other point is, I'm saying that a mechanism to say "go faster" is out of scope. I think a mechanism like this really makes sense (with shapers or based on the ConEx signal -> saying "please more ConEx allowance"). But again this signaling protocol between the sender and a first hop in the network, e.g. the B-RAS, is either independent of ConEx or on top of ConEx. Which would mean that we have to standardize ConEx first before we can design something on top. This point is clearly something which I believe would make sense to recharter for at some point in the future. That is why I proposed to keep this case alive in a separate draft. Mirja From mirja.kuehlewind@ikr.uni-stuttgart.de Tue Mar 15 03:30:14 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 193A23A6C25 for ; Tue, 15 Mar 2011 03:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YO86mzjoICba for ; Tue, 15 Mar 2011 03:30:12 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id 192803A6C63 for ; Tue, 15 Mar 2011 03:30:11 -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 2EEDE633B6; Tue, 15 Mar 2011 11:31: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 1F22F59A8A; Tue, 15 Mar 2011 11:31:36 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: conex@ietf.org Date: Tue, 15 Mar 2011 11:31:35 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201103141758.p2EHwU6W019319@bagheera.jungle.bt.co.uk> <201103142257.p2EMvWn4020302@bagheera.jungle.bt.co.uk> In-Reply-To: <201103142257.p2EMvWn4020302@bagheera.jungle.bt.co.uk> 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: <201103151131.35891.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: Re: [conex] comments on draft-ietf-conex-abstract-mech-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 10:30:14 -0000 Hi, just side remark: Do we cover the case what happens when a ConEx (Re-Echo)= =20 marked packet get dropped by a non-ConEx-aware node...? Mirja On Monday 14 March 2011 23:55:27 Bob Briscoe wrote: > Georgios, > > Whoa! You're trying to correct something that is actually already > correct. You are mistakenly thinking it's wrong. > > When an ECN marked packet is dropped by another congested node > downstream, certainly one of the two congestion events is missed, but > that is what makes the congestion measurement *accurate*, not an > inaccuracy that needs correcting. > > Explanation: > * Congestion at one node is defined as the probability that it will > not serve a packet (or will not serve a packet without ECN-marking it). > * End-to-end congestion is defined as the probability that a packet > will not get through the whole path (or not get through unmarked), > which is the combinatorial probability of it not being served by each > node on the path (or not being served without ECN marking). > > So if Q1, Q2, Q3 =3D 1%, 0% 2% respectively (whether loss or ECN on > each node), then e2e congestion p is defined as: > > p =3D 1 - (1-Q1)(1-Q2)(1-Q3) > =3D 1 - 0.99*1*0.98 > =3D 2.98% > > Importantly, > p !=3D Q1 + Q2 + Q3 > !=3D 3% > > IOW, it's not correct to try to ensure that e2e congestion =3D 3%, > because that's not the probability that a packet will not get through > (or not get through unmarked). The right answer is meant to be 2.98% > > Similarly, it would be incorrect to try to measure both congestion > events when one packet gets marked then lost, or marked then marked > again. It's the small probability that these multiple congestion > events will happen to one packet that makes the correct answer 2.98% > rather than 3%. > > So it is correct that congestion is detected by the transport (the > receiver and sender together) as either loss or ECN. If a CE marked > packet is dropped, congestion will still be detected as a loss. > > -------------------------------------------------------------------------- > > ConEx merely builds on the pre-existing congestion detection > capability of Internet transports. Whether they are accurate or not > (they are actually accurate) the idea is merely for the transport to > tell the network what it knows. > > Even if a transport wasn't accurate, I'm not interested in changing a > transport protocol to make it slightly more accurate, before it > reports congestion with ConEx. > > > Bob > > At 20:12 14/03/2011, Georgios Karagiannis wrote: > >Hi Bob > > > >Thanks for the reply! > > > >You are right, I misunderstood the fact that all the CoNex codes can only > >be set by the sender. Can you please explain in the text that the > >Congestion-Signal shown in Figure 1 is not a ConEx signal, but an ECN > >marked packet. > > > >What I actually mean is that the multiple bottlenecks accuracy problem > >can occur on measuring the congestion rate using the Congestion-Signal > >(e.g., ECN signal), shown in Figure 1. Taking this into account then the > >nodes Q1, Q2, and Q3 shown in my example will represent three Congested > >Network devices. > > > >In order to be sure that I understood the concept correctly, can you > >please inform me which node is measuring the Congestion rate. Is it the > >sender by measuring the feedback signals sent by TCP Acks, or is it the > >Receiver? > > > >Can you please make this clear in the draft? > > > >In my explanation of the accuracy problem caused by multiple bottlenecks, > >I assumed that the Receiver is measuring the Congestion rate, which is > >then sent back to the sender using the feedback signal. > > > >Thus to be clear, if the Sender calculates the congestion rate using the > >TCP Acks received, then the accuracy problem caused by multiple > >bottlenecks might not occur, since the Sender will be able to count the > >number of ECN marked packets as well as the lost packets. > > > >However, if another type of transport protocol is used, e.g., UDP, then > >my comment on the acuracy problem on measuring the congestion rate at > >the Receiver will apply. > > > > > >Best regards, > >Georgios > > > >On 3/14/2011, "Bob Briscoe" wrote: > > >Georgios, > > > > > >I think you've misunderstood. Network nodes like Q1, Q2 & Q3 don't > > >mark packets with the ConEx codes. > > > > > >I hope the doc makes it clear (I just read it over and it seemed > > >clear) that only the source sets ConEx markings, which then remain > > >immutable through the network. > > > > > > > > >Bob > > > > > >At 16:57 14/03/2011, Georgios Karagiannis wrote: > > >>Hi Bob, Hi Matt > > >> > > >>I have read the draft-ietf-conex-abstract-mech-00 draft. The concept > > >>desribed in > > >>this draft is very interesting. However, I have a comment related to > > >> the measurement > > >>of the congestion rate at the receiver side. I think that there is a > > >>possible > > >>accuracy problem related to the measurement of the congestion rate at > > >> the receiver > > >>side. This problem occurs when multiple ConEx nodes that are located = on > > >> the same > > >>communication path are congested and therefore, marked packets might = be > > >>dropped. > > >> > > >>This problem, see below Figure is identified within the context of PCN > > >> and is denoted as > > >>the multiple bottlenecks problem in the PCN domain, see e.g., > > > > Section B.4 in > > > > >>[RFC5670]. > > >>In particular, consider that the nodes Q1, Q2 and Q3 are all > > > > congested. This > > > > >>means that > > >>Q1, Q2 and Q3 will start marking the packets with the Re-Echo-ECN Con= Ex > > >>code. Due to > > >>the fact that Q2 and Q3 are also congested, it could mean that > > >> Re-Echo-ECN packets that were marked by Q1 might be dropped. This > > >> might result in the fact that > > >>the measured Congestion-rate at the receiver R, related to a > > > > flow, might not > > > > >>be > > >>accurate enough. > > >> > > >> +---+ +----+ +----+ +----+ +---+ > > >> > > >> | S |--| Q1 |---| Q2 |---------| Q3 |--| R | > > >> > > >> +---+ +----+ +----+ +----+ +---+ > > >> ^ ^ ^ > > >> > > >> Congested Congested Congested > > >> > > >> > > >> > > >>A possible solution to this measurement accuracy problem is that in > > >>congestion situations > > >>the receiver measures for each flow the Throughput instead of measuri= ng > > >> the congestion > > >>rate. In congestion situations the measured Throughput at the receiver > > >> is sent periodically > > >>as feedback to the sender, see below Figure. Throughput can be defined > > >> as the instantaneous > > >>rate of traffic measured at one receiver that is (1) belonging to the > > >> same flow, (2) that is > > >>Not-Re-Echo-ECN marked and (3) is sent by the same sender. > > >> > > >>The sender always measures the Incoming rate associated with a flow. > > >> The Incoming rate is > > >>the instantaneous rate of traffic that is belonging to the same flow > > >> and is sent by a sender towards > > >>the same receiver. > > >>In order to calculate the Congestion rate, the sender subtracts the > > >>Troughput from the > > >>Incoming rate. > > >> > > >>Using this calculated Congestion rate, the sender calculates the > > >> Congestion exposure signal > > >>using the same method as described in > > >> draft-ietf-conex-abstract-mech-00. > > >> > > >> =20 > > >> 123456789012345678901234567890123456789012345678901234567890123456789 > > >> +---------+ +---------+ > > >> > > >> | |<=3D=3DFeedback Path=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<| =20 > > >> | | | <----------returned throughput ---------------<| = =20 > > >> | | | > > >> | > > >> |Transport| =20 > > >> | |Transport| Sender |>---------(new)-IP layer ConEx > > >> | Signal--------->| Receiver| > > >> | > > >> | | (Carried in Data Packet Headers) | = =20 > > >> | | | +-----------+ | | > > >> | | > > >> | |>=3DData=3DPath=3D>|(Congested)|>=3D=3D=3D=3D=3DData= =3DPath=3D=3D=3D=3D=3D>| =20 > > >> | |> | > > >> | |> > > >> | | | Network |>-Congestion-Signal->| = =20 > > >> | | | | Device | | = =20 > > >> | | | | > > >> > > >> +---------+ +-----------+ =20 > > >> +---------+ > > >> > > >> Overview ConEx architecture with throughput feedback > > >> > > >> > > >>In order to describe this possible accuracy problem on the measurement > > >> of the congestion rate > > >>and its solutions I have made an Internet draft that I would like to > > >> submit once the IETF submission > > >>possibility opens again! > > >> > > >>A preversion of this Internet draft can be found under: > > >>http://wwwhome.cs.utwente.nl/~karagian/conex/draft-karagiannis-con > > > > ex-through > > > > >>put-exposure-00_not_published.txt > > >> > > >>Best regards, > > >>Georgios > > > > > >________________________________________________________________ > > >Bob Briscoe, BT Innovate & Design > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > > _______________________________________________ > 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 karagian@cs.utwente.nl Tue Mar 15 04:44:07 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2A2D3A6C95 for ; Tue, 15 Mar 2011 04:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.411 X-Spam-Level: X-Spam-Status: No, score=-0.411 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GxE9G85DZdt for ; Tue, 15 Mar 2011 04:44:07 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id C72B83A6C78 for ; Tue, 15 Mar 2011 04:44:06 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id p2FBjGpr013734; Tue, 15 Mar 2011 12:45:19 +0100 (MET) From: "Georgios Karagiannis" To: "'Mirja Kuehlewind'" , References: <201103141758.p2EHwU6W019319@bagheera.jungle.bt.co.uk> <201103142257.p2EMvWn4020302@bagheera.jungle.bt.co.uk> <201103151131.35891.mirja.kuehlewind@ikr.uni-stuttgart.de> Date: Tue, 15 Mar 2011 12:45:12 +0100 Message-ID: <27CA1D1F07524289B4613B12A1A32D8F@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acvi/mS+QWGNF8xYQd+JCM59xVcvHwABYM4w In-Reply-To: <201103151131.35891.mirja.kuehlewind@ikr.uni-stuttgart.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 15 Mar 2011 12:45:29 +0100 (MET) Subject: Re: [conex] comments on draft-ietf-conex-abstract-mech-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 11:44:07 -0000 Hi Mirja Before this question can be answered, I think that it is important that two questions are answered: Are the Audit devices the only CoNex devices that are actually comparing an actual congestion signal with a Congestion Exposure Signal sent from the sender? Are the used ConEx aware packets using TCP as transport protocol? Does the TCP connection used by these ConEx aware packets starting/ending at the Sender (Host) and at the Audit devices? Or is this starting/ending at the Sender (host) and Receiver (host)? Best regards, Georgios > -----Original Message----- > From: Mirja Kuehlewind [mailto:mirja.kuehlewind@ikr.uni-stuttgart.de] > Sent: dinsdag 15 maart 2011 11:32 > To: conex@ietf.org > Cc: Bob Briscoe; Georgios Karagiannis > Subject: Re: [conex] comments on draft-ietf-conex-abstract-mech-00 > > Hi, > > just side remark: Do we cover the case what happens when a > ConEx (Re-Echo) marked packet get dropped by a > non-ConEx-aware node...? > > Mirja > From dave.mcdysan@verizon.com Tue Mar 15 06:22:40 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68A663A6BCC for ; Tue, 15 Mar 2011 06:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.354 X-Spam-Level: X-Spam-Status: No, score=-3.354 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeklFD4BbWw8 for ; Tue, 15 Mar 2011 06:22:39 -0700 (PDT) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id D80953A694E for ; Tue, 15 Mar 2011 06:22:37 -0700 (PDT) Received: from fldsmtpi03.verizon.com (fldsmtpi03.verizon.com [166.68.71.145]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p2FDNm8l003428 for ; Tue, 15 Mar 2011 09:24:02 -0400 (EDT) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,322,1297036800"; d="scan'208";a="11640689" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi03.verizon.com with ESMTP; 15 Mar 2011 13:23:48 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.240]) by FHDP1LUMXC7HB01.us.one.verizon.com ([2002:a644:3bbc::a644:3bbc]) with mapi; Tue, 15 Mar 2011 09:23:47 -0400 To: =?iso-8859-1?Q?Mirja_K=FChlewind?= Date: Tue, 15 Mar 2011 09:23:46 -0400 Thread-Topic: [conex] Proposed Text for New Section in Use Case Draft - Statistical multiplexing over Longer Timescales Thread-Index: AcvjFDboFFn+Kp9nSOy4aWeakSm1xw== Message-ID: In-Reply-To: <201103151128.48062.mkuehle@ikr.uni-stuttgart.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] Proposed Text for New Section in Use Case Draft - Statistical multiplexing over Longer Timescales X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 13:22:40 -0000 Hi Mirja, The premise of your scope argument appears to be that a behavior is not defined in the current abstract mechanism draft. I thought we had discussion related to this definition of scope in Beijing as documented in the meeting minutes, which I sent out in response to Alissas' description on 3/4/11 of Approach 1 and 2. You appear to be pursuing approach 1. I excerpt the relevant portion of the meeting minutes again below: "ConEx Concepts and Abstract Mechanism draft-mathis-conex-abstract-mech-00 " Snipped "Dave McDysan (DM) - charter related question - first result is usage scenarios document - other docs will not see publication until that is done - have already had questions on list about additional use cases. if we adopt this as the mechanism document then we foreclose use-case discussion. there are use cases being elaborated that aren't supported by the mechanism, so we could be going round in circles here. =20 MB - are you envisioning additional use cases that could not be satisfied by this mechanism? =20 DM - yes =20 MB - is this a little different or a lot? =20 DM - could be a lot different. this is a good approach for short timescales, but could do something longer term, slow path. =20 MB - so you would like to agree use cases? =20 Leslie Daigle (LD) - i would like to support adopting mechanism document. just don't use it as a blunt instrument to bludgeon people proposing new use cases. =20 MB - would that work for DM? =20 DM - yes, if that decision can be documented. =20 MB - yes, it will be documented, I will remember. =20 RW - agree with LD, adopting this would break the logjam. appendix of moncaster use cases draft could move into this draft. then other use cases could build on that." I had interpreted silence from the chair, Marcelo Bagnulo (MB), as consensus when I posted my response to Alissa on 3/4. You seem to be revisiting the same issue. Specifically, for the use cases document, I interpret the above as use cases that would be built upon Conex are in scope. Furthermore, use cases that do not use currently defined abstract mechanisms are in scope as well.=20 Marcelo, and area directors, please discuss and this time please respond so that the working group can understand scope and have a common interpretation of what was agreed in IETF 79, Beijing. Then, for things that are in scope, the working group can have a technical discussion. Thanks, Dave On 3/15/11 6:28 AM, "Mirja K=FChlewind" wrote: >Hi Dave, > >just a quick response to the in or out of scope discussion: > >> However, as a number of wg members have posted, shapers will cause >>effects >> that will appear as congestion. >> >> I would like to see the wg agree on whether this either in or out of >>scope >> -- you keep making the same point about scope. If you look at the list >> several others have said this case at least needs to be described in the >> draft, but have expressed concerns as to whether the complexity of >>adding >> to the mechanism will justify the benefit. >> >> Can you please say more as to why you believe it is out of scope. >I don't say shapers are out of scope. But I don't really see the special >case=20 >about shapers. If they mark or drop a packet, I have to take it as a >congestion signal because I anyway don't know what in the network and why >it=20 >doing this... > >If you want an additional signaling for shaper congestion, I believe that >is=20 >independent of ConEx. Its like having another kind of ECN signal. You can >simply specify such an additional signaling protocol (every time in the >future) and add a section how ConEx senders should react to it. I don't >believe this will change the ConEx mechanism itself. But I'm open for a >discussion here. But first of all we have to figure out if there is a >special=20 >case about shapers. I still believe no. > >The other point is, I'm saying that a mechanism to say "go faster" is out >of=20 >scope. I think a mechanism like this really makes sense (with shapers or >based on the ConEx signal -> saying "please more ConEx allowance"). But >again=20 >this signaling protocol between the sender and a first hop in the >network,=20 >e.g. the B-RAS, is either independent of ConEx or on top of ConEx. Which >would mean that we have to standardize ConEx first before we can design >something on top. This point is clearly something which I believe would >make=20 >sense to recharter for at some point in the future. That is why I >proposed to=20 >keep this case alive in a separate draft. > >Mirja=20 > From karagian@cs.utwente.nl Tue Mar 15 23:55:57 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AC4C3A680D for ; Tue, 15 Mar 2011 23:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.892 X-Spam-Level: X-Spam-Status: No, score=0.892 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ze-IRm1QGdVG for ; Tue, 15 Mar 2011 23:55:55 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id 533DD3A680C for ; Tue, 15 Mar 2011 23:55:55 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p2G6v5fi005115; Wed, 16 Mar 2011 07:57:05 +0100 (MET) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Wed, 16 Mar 2011 06:57:06 +0000 To: "Bob Briscoe" Date: Wed, 16 Mar 2011 06:57:05 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <94DlGqg7.1300166559.3550600.karagian@ewi.utwente.nl> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 16 Mar 2011 07:57:16 +0100 (MET) Cc: 'ConEx IETF list' Subject: Re: [conex] comments on draft-ietf-conex-abstract-mech-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 06:55:57 -0000 Hi Bob I think that I was probably not clear enough in one of my statements below. Consider that the following statement that I have used in the email below, should be changed from: >If the Congestion rate is calculated only >at the Receiver (independent of the transport) protocol then this >measurement can be inaccurate. INTO: When a transport protocl is not able to count the lost packets at the Receiver side and when the Congestion rate is calculated at the Receiver then the Congestion rate measurement can be inaccurate. This change in my statement is needed since in TCP, the receiver by using the receiver window, see RFC5681, could calculate the number of lost packets. Thus in case of TCP, the Congestion rate could also be calculated at the Receiver side. So the multiple bottleneck problem associated with the measurement of the Congestion rate that I have emphasized in the previous emails apply to situations where the Congestion rate is measured at the Receiver and when the used transport protocol is not able to count the lost packets at the Receiver side. Best regards, Georgios >Hi Bob > >Please see in line! > > >On 3/14/2011, "Bob Briscoe" wrote: > >>Georgios, >> >>Whoa! You're trying to correct something that is actually already >>correct. You are mistakenly thinking it's wrong. > >Georgios: Maybe it is correct, but the operation was not clear to me. >Please note that I was talking about Congestion rate in my email. > >draft-ietf-conex-concepts-uses-01 defines Congestion rate as: > > >Congestion-rate: For any granularity of traffic (packet, flow, > aggregate, etc.), the instantaneous rate of traffic discarded or > marked due to congestion. Conceptually, the instantaneous bit- > rate of the traffic multiplied by the instantaneous congestion it > is experiencing. > > >As I already mentioned, my assumption was that the Receiver would measure >the congestion rate and it will then report this to the Sender. From >what I understood now is that the Receiver does not do that, but it just >uses the reliability feature of TCP (combinated with ECN). Meaning that >actually the Sender is measuring the Congestion rate (not the Receiver). >Please note that I am not sure if it is clear in the current >draft-ietf-conex-abstract-mech-01 text that the Sender is measuring the >Congestion rate. > > >As I already mentioned this situation can provide accurate measurements, >since the Sender, using the TCP Ack can deduce whether a downstream >packet was congested ECN marked or was dropped. Thus when a reliable >transport protocol, like TCP, is used then the calculation of the >Congestion rate at the Sender can be considered to be accurate enough. > > >> >>When an ECN marked packet is dropped by another congested node >>downstream, certainly one of the two congestion events is missed, but >>that is what makes the congestion measurement *accurate*, not an >>inaccuracy that needs correcting. > >Georgios: Yes, assuming that the transport protocol is reliable and that >the congstion rate is calculated at the Sender side. > >> >>Explanation: >>* Congestion at one node is defined as the probability that it will >>not serve a packet (or will not serve a packet without ECN-marking it). >>* End-to-end congestion is defined as the probability that a packet >>will not get through the whole path (or not get through unmarked), >>which is the combinatorial probability of it not being served by each >>node on the path (or not being served without ECN marking). >> >>So if Q1, Q2, Q3 =3D 1%, 0% 2% respectively (whether loss or ECN on >>each node), then e2e congestion p is defined as: >> >>p =3D 1 - (1-Q1)(1-Q2)(1-Q3) >> =3D 1 - 0.99*1*0.98 >> =3D 2.98% > >Georgios: Okay, assuming that these probabilities (on Q1, Q2, Q3) are >independent of each other. > >> >>Importantly, >>p !=3D Q1 + Q2 + Q3 >> !=3D 3% >> > >>IOW, it's not correct to try to ensure that e2e congestion =3D 3%, >>because that's not the probability that a packet will not get through >>(or not get through unmarked). The right answer is meant to be 2.98% >> > >Georgios: That was not my point! In my opinion, what it should be made >clear in the draft is that CoNex should use a reliable transport >protocol that caries feedback sgnals to the Sender. Based on these >feedback signals, the Sender can accurately calculate the Congestion >rate, since it can calculate the number of congested ECN marked packets >on the downstream and as well as the number of packets that were dropped >in the downstream direction. If the Congestion rate is calculated only >at the Receiver (independent of the transport) protocol then this >measurement can be inaccurate. > > > >>Similarly, it would be incorrect to try to measure both congestion >>events when one packet gets marked then lost, or marked then marked >>again. It's the small probability that these multiple congestion >>events will happen to one packet that makes the correct answer 2.98% >>rather than 3%. >> >>So it is correct that congestion is detected by the transport (the >>receiver and sender together) as either loss or ECN. If a CE marked >>packet is dropped, congestion will still be detected as a loss. > >Georgios: That was not my point, see above! > > >> >>-------------------------------------------------------------------------- >> >>ConEx merely builds on the pre-existing congestion detection >>capability of Internet transports. Whether they are accurate or not >>(they are actually accurate) the idea is merely for the transport to >>tell the network what it knows. > >Georgios: Yes, assuming that the transport is reliable and is able to >measure not only the congestion marked packets at the downstream >direction, but also the dropped packets in the downstream direction. > >> >>Even if a transport wasn't accurate, I'm not interested in changing a >>transport protocol to make it slightly more accurate, before it >>reports congestion with ConEx. > >Georgios: Yes, but then the calculation of the Congestion rate and the >use of the CoNex exposure signals in different use cases will be >inaccurate. > >Best regards, >Georgios > >> >> >>Bob >> >>At 20:12 14/03/2011, Georgios Karagiannis wrote: >>>Hi Bob >>> >>>Thanks for the reply! >>> >>>You are right, I misunderstood the fact that all the CoNex codes can only >>>be set by the sender. Can you please explain in the text that the >>>Congestion-Signal shown in Figure 1 is not a ConEx signal, but an ECN >>>marked packet. >>> >>>What I actually mean is that the multiple bottlenecks accuracy problem >>>can occur on measuring the congestion rate using the Congestion-Signal >>>(e.g., ECN signal), shown in Figure 1. Taking this into account then the >>>nodes Q1, Q2, and Q3 shown in my example will represent three Congested >>>Network devices. >>> >>>In order to be sure that I understood the concept correctly, can you >>>please inform me which node is measuring the Congestion rate. Is it the >>>sender by measuring the feedback signals sent by TCP Acks, or is it the >>>Receiver? >>> >>>Can you please make this clear in the draft? >>> >>>In my explanation of the accuracy problem caused by multiple bottlenecks, >>>I assumed that the Receiver is measuring the Congestion rate, which is >>>then sent back to the sender using the feedback signal. >>> >>>Thus to be clear, if the Sender calculates the congestion rate using the >>>TCP Acks received, then the accuracy problem caused by multiple >>>bottlenecks might not occur, since the Sender will be able to count the >>>number of ECN marked packets as well as the lost packets. >>> >>>However, if another type of transport protocol is used, e.g., UDP, then >>>my comment on the acuracy problem on measuring the congestion rate at >>>the Receiver will apply. >>> >>> >>>Best regards, >>>Georgios >>> >>>On 3/14/2011, "Bob Briscoe" wrote: >>> >>> >Georgios, >>> > >>> >I think you've misunderstood. Network nodes like Q1, Q2 & Q3 don't >>> >mark packets with the ConEx codes. >>> > >>> >I hope the doc makes it clear (I just read it over and it seemed >>> >clear) that only the source sets ConEx markings, which then remain >>> >immutable through the network. >>> > >>> > >>> >Bob >>> > >>> >At 16:57 14/03/2011, Georgios Karagiannis wrote: >>> >>Hi Bob, Hi Matt >>> >> >>> >>I have read the draft-ietf-conex-abstract-mech-00 draft. The concept >>> >>desribed in >>> >>this draft is very interesting. However, I have a comment related to th= e >>> >>measurement >>> >>of the congestion rate at the receiver side. I think that there is a >>> >>possible >>> >>accuracy problem related to the measurement of the congestion rate at t= he >>> >>receiver >>> >>side. This problem occurs when multiple ConEx nodes that are located on= the >>> >>same >>> >>communication path are congested and therefore, marked packets might be >>> >>dropped. >>> >> >>> >>This problem, see below Figure is identified within the context of PCN = and >>> >>is denoted as >>> >>the multiple bottlenecks problem in the PCN domain, see e.g., >>> Section B.4 in >>> >>[RFC5670]. >>> >>In particular, consider that the nodes Q1, Q2 and Q3 are all >>> congested. This >>> >>means that >>> >>Q1, Q2 and Q3 will start marking the packets with the Re-Echo-ECN ConEx >>> >>code. Due to >>> >>the fact that Q2 and Q3 are also congested, it could mean that Re-Echo-= ECN >>> >>packets that were marked by Q1 might be dropped. This might result in t= he >>> >>fact that >>> >>the measured Congestion-rate at the receiver R, related to a >>> flow, might not >>> >>be >>> >>accurate enough. >>> >> >>> >> +---+ +----+ +----+ +----+ +---+ >>> >> | S |--| Q1 |---| Q2 |---------| Q3 |--| R | >>> >> +---+ +----+ +----+ +----+ +---+ >>> >> ^ ^ ^ >>> >> | | | >>> >> Congested Congested Congested >>> >> >>> >> >>> >> >>> >>A possible solution to this measurement accuracy problem is that in >>> >>congestion situations >>> >>the receiver measures for each flow the Throughput instead of measuring= the >>> >>congestion >>> >>rate. In congestion situations the measured Throughput at the receiver = is >>> >>sent periodically >>> >>as feedback to the sender, see below Figure. Throughput can be defined = as >>> >>the instantaneous >>> >>rate of traffic measured at one receiver that is (1) belonging to the s= ame >>> >>flow, (2) that is >>> >>Not-Re-Echo-ECN marked and (3) is sent by the same sender. >>> >> >>> >>The sender always measures the Incoming rate associated with a flow. Th= e >>> >>Incoming rate is >>> >>the instantaneous rate of traffic that is belonging to the same flow an= d is >>> >>sent by a sender towards >>> >>the same receiver. >>> >>In order to calculate the Congestion rate, the sender subtracts the >>> >>Troughput from the >>> >>Incoming rate. >>> >> >>> >>Using this calculated Congestion rate, the sender calculates the Conges= tion >>> >>exposure signal >>> >>using the same method as described in draft-ietf-conex-abstract-mech-00= . >>> >> >>> >> 1234567890123456789012345678901234567890123456789012345678901234567= 89 >>> >> +---------+ +--------= -+ >>> >> | |<=3D=3DFeedback Path=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<| | >>> >> | |<----------returned throughput ---------------<| = | >>> >> | | | = | >>> >> |Transport| |Transpor= t| >>> >> | Sender |>---------(new)-IP layer ConEx Signal--------->| Receive= r| >>> >> | | (Carried in Data Packet Headers) | = | >>> >> | | +-----------+ | = | >>> >> | |>=3DData=3DPath=3D>|(Congested)|>=3D=3D=3D=3D=3DData=3DP= ath=3D=3D=3D=3D=3D>| | >>> >> | | | Network |>-Congestion-Signal->| = | >>> >> | | | Device | | = | >>> >> +---------+ +-----------+ +--------= -+ >>> >> >>> >> Overview ConEx architecture with throughput feedback >>> >> >>> >> >>> >>In order to describe this possible accuracy problem on the measurement = of >>> >>the congestion rate >>> >>and its solutions I have made an Internet draft that I would like to su= bmit >>> >>once the IETF submission >>> >>possibility opens again! >>> >> >>> >>A preversion of this Internet draft can be found under: >>> >>http://wwwhome.cs.utwente.nl/~karagian/conex/draft-karagiannis-con >>> ex-through >>> >>put-exposure-00_not_published.txt >>> >> >>> >>Best regards, >>> >>Georgios >>> > >>> >________________________________________________________________ >>> >Bob Briscoe, BT Innovate & Design >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex From nanditad@google.com Thu Mar 17 00:27:03 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85F153A6A14 for ; Thu, 17 Mar 2011 00:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mppcnn+A70Qu for ; Thu, 17 Mar 2011 00:27:01 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 923EB3A69F9 for ; Thu, 17 Mar 2011 00:27:01 -0700 (PDT) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id p2H7SRef029729 for ; Thu, 17 Mar 2011 00:28:27 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1300346908; bh=NC3YJyuoNatBD5ZlvAADSxJozGo=; h=MIME-Version:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=q9SPIm8r2q9Iye8vQBlJUnMqOZcfUrs8AkOsoOmx/5mESRwibH3/wU6/2bDnsGj9k v9yRfyREb+b8MW+0u7zpg== Received: from yia13 (yia13.prod.google.com [10.243.65.13]) by kpbe16.cbf.corp.google.com with ESMTP id p2H7SPZO019457 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 17 Mar 2011 00:28:26 -0700 Received: by yia13 with SMTP id 13so1137694yia.20 for ; Thu, 17 Mar 2011 00:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=3UmK4lnGjdIRBDfbF6J3AEv75mvIVw2tVbrf4CL/w7Y=; b=O7dsgv4y7VfcWcLkmSh3gXFjp4abhMfg0k+qaVWiDHmGPQJ74ZvcLfxFtVzgzkIMbL f2sZROV4nCXQo1POOi0Q== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=dVwP2J/EvnO42+r713ZPEmYgLdefSoCY9InXUgR0vq0apLUxv4gnB25Z/hwNR+Qnbb T6aXk6P8gVOSngPqLWoA== MIME-Version: 1.0 Received: by 10.90.14.39 with SMTP id 39mr1063051agn.127.1300346905359; Thu, 17 Mar 2011 00:28:25 -0700 (PDT) Received: by 10.91.219.10 with HTTP; Thu, 17 Mar 2011 00:28:25 -0700 (PDT) Date: Thu, 17 Mar 2011 00:28:25 -0700 Message-ID: From: Nandita Dukkipati To: Toby Moncaster , John Leslie , Bob Briscoe , "Woundy, Richard" , "Mcdysan, David E" Content-Type: multipart/alternative; boundary=0016361e850860f4c4049ea89bde X-System-Of-Record: true Cc: conex@ietf.org Subject: [conex] comments/suggestions on draft-ietf-conex-concepts-uses-01 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 07:27:03 -0000 --0016361e850860f4c4049ea89bde Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On reading the latest draft, I have three high level comments roughly in th= e following order of importance- *** Statistical Multiplexing over different timescales. This reads like a rambling story. I have read and re-read it, and I am stil= l left wondering - * What is _the_ main point? How about starting the section by stating your main point upfront as opposed leaving it to the reader to figure it out. * Why and how is this use case distinct from that of traffic management which already seems to have a broad scope? Is it really distinct? * [minor] Why not make this use case a part of Sec. 5? *** Partial versus full deployment. Clearly, it belongs to this draft. But why is it a part of use cases? Looks out of place to me. *** Sec 4. Exposing congestion. =93We argue that congestion needs.... More specifically, a network needs to= be able to measure how much congestion any particular traffic expects to cause between the monitoring point in the network and the destination ("rest-of-path congestion"). This would be a new capability.=94 Could you add more clarity and explanation on why local congestion information at any given node is not sufficient. Why does a node require congestion information from a monitoring point to the destination to be abl= e to manage its own congestion? A succinct explanation and/or an example will go a long way. --0016361e850860f4c4049ea89bde Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On reading the latest draft, I have three high level comments roughly in th= e following order of importance-

***= =A0
Statistical Multiplexing over different timescales.
This reads like a rambling story. I have read = and re-read it, and I am still left wondering -
= * What is _the_ main point? How about starting the section by stating your = main point upfront as opposed leaving it to the reader to figure it out.
* Why and how is this use case distinct from that of traffic manage= ment which already seems to have a broad scope? Is it really distinct?
 * [minor] Why not make this use case a part of Sec. 5?

**= *
Partia= l versus full deployment.
Clearl= y, it belongs to this draft. But why is it a part of use cases? Looks out o= f place to me.

***
Sec 4. Exposing congestion.
=93We argue that congestion need= s.... More specifically, a network needs to be able to measure how much con= gestion any particular traffic expects to cause between the monitoring poin= t in the network and the destination ("rest-of-path congestion").= This would be a new capability.=94
Could you add more clarity and explanation on why local congestion = information at any given node is not sufficient. Why does a node require co= ngestion information from a monitoring point to the destination to be able = to manage its own congestion? A succinct explanation and/or an example will= go a long way.

--0016361e850860f4c4049ea89bde-- From toby@moncaster.com Thu Mar 17 02:52:00 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D8A33A6A50 for ; Thu, 17 Mar 2011 02:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBi2nq7iPPQk for ; Thu, 17 Mar 2011 02:51:53 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by core3.amsl.com (Postfix) with ESMTP id 686113A6A6D for ; Thu, 17 Mar 2011 02:51:53 -0700 (PDT) Received: from TobysHP (host86-143-221-235.range86-143.btcentralplus.com [86.143.221.235]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MaE2a-1QJsdP2wQa-00Jq4P; Thu, 17 Mar 2011 10:53:08 +0100 From: "Toby Moncaster" To: "'Nandita Dukkipati'" , "'John Leslie'" , "'Bob Briscoe'" , "'Woundy, Richard'" , "'Mcdysan, David E'" References: In-Reply-To: Date: Thu, 17 Mar 2011 09:53:07 -0000 Message-ID: <001601cbe489$1e800530$5b800f90$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01CBE489.1E800530" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcvkdOkzmPy3uHJoTjGDd8jhpuevpQAEjeiA Content-Language: en-gb X-Provags-ID: V02:K0:TmSXInVZgbFCoVI8lhyHw2rDbg79wHKedRACtDQk6sX n1yNk7Xs9RzGRD/vkH9a4E2wFVGXcAA9p61BjQCgdwZJ/qYlr0 9MDBchravtnFMy9UWFflgSTnrCRPPhXJBM2vzadSNs6sB+pB58 9wwkbtLQPb89h0WT9dRliyDLLd+qD+5+6vV7BlGkOVsd/sSytu X9yzjZcZXV/h030ThLO67I1vv6FPaQ9z7iLEDBbKYU= Cc: conex@ietf.org Subject: Re: [conex] comments/suggestions on draft-ietf-conex-concepts-uses-01 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 09:52:00 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0017_01CBE489.1E800530 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Nandita, Thanks for the comments. Just for the record can you confirm whether these are comments as WG chair, or as an individual contributor? Addressing your three points in order: Statistical multiplexing. This is a new section and so there is clearly a lot of work needed to tidy it up and possibly to rationalise where it fits in the structure of the document. Hopefully Dave can answer what the main point is... As I understand things, Dave's view is that the main difference is the measure of activity ratio that he introduces. As he sees things, this is a different congestion measure to that used in the abstract mechanism and so stands apart from the other use cases... **** Partial vs Full Deployment. This does need a bit of work. And you are right that it has now ended up in a strange place within the document. I will move it to its own section in -02 **** Exposing congestion. We are not arguing that a node needs this information to perform local congestion management. But it does need this information if it is going to be held to account for dumping large quantities of congestion on a node further downstream. In other words it allows the NETWORK to make better congestion management decisions and avoids any tragedy of the commons. Economists like Bob talk about maximising social welfare. I just think of it as making the whole network run more efficiently (which benefits everyone). You could make a bad analogy: At 8 in the morning everyone living in a city looks out of their windows and sees that the road outside their house is clear (no congestion). So lots of them decide to get in their cars and head off to the mall. As soon as they reach the freeway there is utter gridlock - the congestion wasn't where they were, it was further along the path and they just made it much worse. In fact in such cases we do make use of something that gives us knowledge of the congestion further along the path, namely local traffic reports on the radio (or smartphone, satnav, etc). Toby From: Nandita Dukkipati [mailto:nanditad@google.com] Sent: 17 March 2011 07:28 To: Toby Moncaster; John Leslie; Bob Briscoe; Woundy, Richard; Mcdysan, David E Cc: conex@ietf.org Subject: comments/suggestions on draft-ietf-conex-concepts-uses-01 On reading the latest draft, I have three high level comments roughly in the following order of importance- *** Statistical Multiplexing over different timescales. This reads like a rambling story. I have read and re-read it, and I am still left wondering - * What is _the_ main point? How about starting the section by stating your main point upfront as opposed leaving it to the reader to figure it out. * Why and how is this use case distinct from that of traffic management which already seems to have a broad scope? Is it really distinct? * [minor] Why not make this use case a part of Sec. 5? *** Partial versus full deployment. Clearly, it belongs to this draft. But why is it a part of use cases? Looks out of place to me. *** Sec 4. Exposing congestion. "We argue that congestion needs.... More specifically, a network needs to be able to measure how much congestion any particular traffic expects to cause between the monitoring point in the network and the destination ("rest-of-path congestion"). This would be a new capability." Could you add more clarity and explanation on why local congestion information at any given node is not sufficient. Why does a node require congestion information from a monitoring point to the destination to be able to manage its own congestion? A succinct explanation and/or an example will go a long way. ------=_NextPart_000_0017_01CBE489.1E800530 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Nandita,

 

Thanks for the comments. Just for the record can you confirm whether = these are comments as WG chair, or as an individual = contributor?

 

Addressing your three points in order:

 

Statistical multiplexing. This is a new section and so there is = clearly a lot of work needed to tidy it up and possibly to rationalise = where it fits in the structure of the document. Hopefully Dave can = answer what the main point is... As I understand things, Dave’s = view is that the main difference is the measure of activity ratio that = he introduces. As he sees things, this is a different congestion measure = to that used in the abstract mechanism and so stands apart from the = other use cases...

 

****

Partial vs Full Deployment. This does need a bit of work. And you are = right that it has now ended up in a strange place within the document. I = will move it to its own section in -02

 

****

Exposing congestion. We are not arguing that a node needs this = information to perform local congestion management. But it does need = this information if it is going to be held to account for dumping large = quantities of congestion on a node further downstream. In other words it = allows the NETWORK to make better congestion management decisions and = avoids any tragedy of the commons. Economists like Bob talk about = maximising social welfare. I just think of it as making the whole = network run more efficiently (which benefits = everyone).

 

You could make a bad analogy: At 8 in the morning everyone living in = a city looks out of their windows and sees that the road outside their = house is clear (no congestion). So lots of them decide to get in their = cars and head off to the mall. As soon as they reach the freeway there = is utter gridlock – the congestion wasn’t where they were, = it was further along the path and they just made it much worse. In fact = in such cases we do make use of something that gives us knowledge of the = congestion further along the path, namely local traffic reports on the = radio (or smartphone, satnav, etc).

 

Toby

 

From:= Nandita = Dukkipati [mailto:nanditad@google.com]
Sent: 17 March 2011 = 07:28
To: Toby Moncaster; John Leslie; Bob Briscoe; Woundy, = Richard; Mcdysan, David E
Cc: = conex@ietf.org
Subject: comments/suggestions on = draft-ietf-conex-concepts-uses-01

 

On reading = the latest draft, I have three high level comments roughly in the = following order of importance-

 

*= ** 

S= tatistical Multiplexing over different timescales.
This reads = like a rambling story. I have read and re-read it, and I am still left = wondering -

*= What is _the_ main point? How about starting the section by stating = your main point upfront as opposed leaving it to the reader to figure it = out.

*= Why and how is this use case distinct from that of traffic management = which already seems to have a broad scope? Is it really = distinct?
*= [minor] Why not make this use case a part of Sec. = 5?

 

*= **
P= artial versus full deployment.
C= learly, it belongs to this draft. But why is it a part of use cases? = Looks out of place to me.

 

***

Sec = 4. Exposing congestion.

&= #8220;We argue that congestion needs.... More specifically, a network = needs to be able to measure how much congestion any particular traffic = expects to cause between the monitoring point in the network and the = destination ("rest-of-path congestion"). This would be a new = capability.”


C= ould you add more clarity and explanation on why local congestion = information at any given node is not sufficient. Why does a node require = congestion information from a monitoring point to the destination to be = able to manage its own congestion? A succinct explanation and/or an = example will go a long = way.

 

------=_NextPart_000_0017_01CBE489.1E800530-- From toby@moncaster.com Thu Mar 17 02:54:00 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03DC93A6A50 for ; Thu, 17 Mar 2011 02:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdVQrUOBNIKd for ; Thu, 17 Mar 2011 02:53:55 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id CF0113A6A6D for ; Thu, 17 Mar 2011 02:53:54 -0700 (PDT) Received: from TobysHP (host86-143-221-235.range86-143.btcentralplus.com [86.143.221.235]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0LzHaz-1PvIQw09eT-014RRJ; Thu, 17 Mar 2011 10:55:20 +0100 From: "Toby Moncaster" To: "'John Leslie'" References: In-Reply-To: Date: Thu, 17 Mar 2011 09:55:18 -0000 Message-ID: <001b01cbe489$6cf59f40$46e0ddc0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01CBE489.6CF59F40" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcvkdOkzmPy3uHJoTjGDd8jhpuevpQAFDbTQ Content-Language: en-gb X-Provags-ID: V02:K0:qEt9ztOJL6zyKm2NgV3EAa0CGRsHEk3Eb/qi9fs5kz0 pOiFB0vZ5FD3XKAkQ4hprwUxe6VF4P3jXLbsrixzYpd6pyDY9w +TBnsECEiUMkegXl8Gp/iez+otiJKOKKern4+E8ZWXb8yaDTXe ZQD53aTqc+1XTzytWzMcnYC1IofhIs9Y+Z9+3G8FI3ButNF+ex qclEdEVIzTMLR5Wpc7ifjLc3h6F2qT+xpWea/jycqY= Cc: conex@ietf.org Subject: Re: [conex] comments/suggestions on draft-ietf-conex-concepts-uses-01 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 09:54:00 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001C_01CBE489.6CF59F40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Off-list response... If this was a comment by her as chair it's a bit rich. It was the chairs that wanted us to add some of Dave's wanderings into the document in the first place wasn't it? I didn't like to say to her that I too couldn't quite see what Dave's point was. I certainly can't see why he needs so many words to (fail) to make it. From: Nandita Dukkipati [mailto:nanditad@google.com] Sent: 17 March 2011 07:28 To: Toby Moncaster; John Leslie; Bob Briscoe; Woundy, Richard; Mcdysan, David E Cc: conex@ietf.org Subject: comments/suggestions on draft-ietf-conex-concepts-uses-01 On reading the latest draft, I have three high level comments roughly in the following order of importance- *** Statistical Multiplexing over different timescales. This reads like a rambling story. I have read and re-read it, and I am still left wondering - * What is _the_ main point? How about starting the section by stating your main point upfront as opposed leaving it to the reader to figure it out. * Why and how is this use case distinct from that of traffic management which already seems to have a broad scope? Is it really distinct? * [minor] Why not make this use case a part of Sec. 5? *** Partial versus full deployment. Clearly, it belongs to this draft. But why is it a part of use cases? Looks out of place to me. *** Sec 4. Exposing congestion. "We argue that congestion needs.... More specifically, a network needs to be able to measure how much congestion any particular traffic expects to cause between the monitoring point in the network and the destination ("rest-of-path congestion"). This would be a new capability." Could you add more clarity and explanation on why local congestion information at any given node is not sufficient. Why does a node require congestion information from a monitoring point to the destination to be able to manage its own congestion? A succinct explanation and/or an example will go a long way. ------=_NextPart_000_001C_01CBE489.6CF59F40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Off-list response...

 

If this was a comment by her as chair it’s a bit rich. It was = the chairs that wanted us to add some of Dave’s wanderings into = the document in the first place wasn’t it? I didn’t like to = say to her that I too couldn’t quite see what Dave’s point = was. I certainly can’t see why he needs so many words to (fail) to = make it.

 

From:= Nandita = Dukkipati [mailto:nanditad@google.com]
Sent: 17 March 2011 = 07:28
To: Toby Moncaster; John Leslie; Bob Briscoe; Woundy, = Richard; Mcdysan, David E
Cc: = conex@ietf.org
Subject: comments/suggestions on = draft-ietf-conex-concepts-uses-01

 

On reading = the latest draft, I have three high level comments roughly in the = following order of importance-

 

*= ** 

S= tatistical Multiplexing over different timescales.
This reads = like a rambling story. I have read and re-read it, and I am still left = wondering -

*= What is _the_ main point? How about starting the section by stating = your main point upfront as opposed leaving it to the reader to figure it = out.

*= Why and how is this use case distinct from that of traffic management = which already seems to have a broad scope? Is it really = distinct?
*= [minor] Why not make this use case a part of Sec. = 5?

 

*= **
P= artial versus full deployment.
C= learly, it belongs to this draft. But why is it a part of use cases? = Looks out of place to me.

 

***

Sec = 4. Exposing congestion.

&= #8220;We argue that congestion needs.... More specifically, a network = needs to be able to measure how much congestion any particular traffic = expects to cause between the monitoring point in the network and the = destination ("rest-of-path congestion"). This would be a new = capability.”


C= ould you add more clarity and explanation on why local congestion = information at any given node is not sufficient. Why does a node require = congestion information from a monitoring point to the destination to be = able to manage its own congestion? A succinct explanation and/or an = example will go a long = way.

 

------=_NextPart_000_001C_01CBE489.6CF59F40-- From toby@moncaster.com Thu Mar 17 02:58:02 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B20DD3A6910 for ; Thu, 17 Mar 2011 02:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUjdVyV37CJL for ; Thu, 17 Mar 2011 02:57:57 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id A6F2C3A67CC for ; Thu, 17 Mar 2011 02:57:56 -0700 (PDT) Received: from TobysHP (host86-143-221-235.range86-143.btcentralplus.com [86.143.221.235]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0Mh6iv-1QLnR53QSv-00MLCy; Thu, 17 Mar 2011 10:59:23 +0100 From: "Toby Moncaster" To: Date: Thu, 17 Mar 2011 09:59:22 -0000 Message-ID: <002c01cbe489$fe114bf0$fa33e3d0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01CBE489.FE114BF0" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcvkdOkzmPy3uHJoTjGDd8jhpuevpQAFDbTQAAAZL8A= Content-Language: en-gb X-Provags-ID: V02:K0:7r/QiUI8nxhrSE8Swrq4lYZCj3eJbMreKLDEunCIiXc /IJFC4Ocz0SyGMxqLFwtQrCoFI6+7HnDnAWUZO6JFnumFxYdwA nO85vLQtbuQAWbPfmW+dLw9ld4LSdRTo5e+TZSnfXAU6R1FC69 nZjC9X51Q6VznqIgWOTAifLYsZf57ETK+v9W+3PlHlfpvQGB9W dbVSCHfhESa9o1fr4siuBP1cJvEFVNNXmhMCR7ad0w= Subject: [conex] FW: comments/suggestions on draft-ietf-conex-concepts-uses-01 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 09:58:02 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_002D_01CBE489.FE114BF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Apologies to everyone, especially Nandita and Dave. This was not meant to go to the conex list as I am sure you will all realise. I was just letting off some steam, principally caused by other things happening in my life... Again, apologies if I caused anyone any offence... Toby From: Toby Moncaster [mailto:toby@moncaster.com] Sent: 17 March 2011 09:55 To: 'John Leslie' Cc: 'conex@ietf.org' Subject: RE: comments/suggestions on draft-ietf-conex-concepts-uses-01 Off-list response... If this was a comment by her as chair it's a bit rich. It was the chairs that wanted us to add some of Dave's wanderings into the document in the first place wasn't it? I didn't like to say to her that I too couldn't quite see what Dave's point was. I certainly can't see why he needs so many words to (fail) to make it. From: Nandita Dukkipati [mailto:nanditad@google.com] Sent: 17 March 2011 07:28 To: Toby Moncaster; John Leslie; Bob Briscoe; Woundy, Richard; Mcdysan, David E Cc: conex@ietf.org Subject: comments/suggestions on draft-ietf-conex-concepts-uses-01 On reading the latest draft, I have three high level comments roughly in the following order of importance- *** Statistical Multiplexing over different timescales. This reads like a rambling story. I have read and re-read it, and I am still left wondering - * What is _the_ main point? How about starting the section by stating your main point upfront as opposed leaving it to the reader to figure it out. * Why and how is this use case distinct from that of traffic management which already seems to have a broad scope? Is it really distinct? * [minor] Why not make this use case a part of Sec. 5? *** Partial versus full deployment. Clearly, it belongs to this draft. But why is it a part of use cases? Looks out of place to me. *** Sec 4. Exposing congestion. "We argue that congestion needs.... More specifically, a network needs to be able to measure how much congestion any particular traffic expects to cause between the monitoring point in the network and the destination ("rest-of-path congestion"). This would be a new capability." Could you add more clarity and explanation on why local congestion information at any given node is not sufficient. Why does a node require congestion information from a monitoring point to the destination to be able to manage its own congestion? A succinct explanation and/or an example will go a long way. ------=_NextPart_000_002D_01CBE489.FE114BF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Apologies to everyone, especially Nandita and Dave. This was not = meant to go to the conex list as I am sure you will all = realise.

 

I was just letting off some steam, principally caused by other things = happening in my life...

 

Again, apologies if I caused anyone any = offence...

 

Toby

 

From:= Toby = Moncaster [mailto:toby@moncaster.com]
Sent: 17 March 2011 = 09:55
To: 'John Leslie'
Cc: = 'conex@ietf.org'
Subject: RE: comments/suggestions on = draft-ietf-conex-concepts-uses-01

 

Off-list response...

 

If this was a comment by her as chair it’s a bit rich. It was = the chairs that wanted us to add some of Dave’s wanderings into = the document in the first place wasn’t it? I didn’t like to = say to her that I too couldn’t quite see what Dave’s point = was. I certainly can’t see why he needs so many words to (fail) to = make it.

 

From:= Nandita = Dukkipati [mailto:nanditad@google.com]
Sent: 17 March 2011 = 07:28
To: Toby Moncaster; John Leslie; Bob Briscoe; Woundy, = Richard; Mcdysan, David E
Cc: = conex@ietf.org
Subject: comments/suggestions on = draft-ietf-conex-concepts-uses-01

 

On reading = the latest draft, I have three high level comments roughly in the = following order of importance-

 

*= ** 

S= tatistical Multiplexing over different timescales.
This reads = like a rambling story. I have read and re-read it, and I am still left = wondering -

*= What is _the_ main point? How about starting the section by stating = your main point upfront as opposed leaving it to the reader to figure it = out.

*= Why and how is this use case distinct from that of traffic management = which already seems to have a broad scope? Is it really = distinct?
*= [minor] Why not make this use case a part of Sec. = 5?

 

*= **
P= artial versus full deployment.
C= learly, it belongs to this draft. But why is it a part of use cases? = Looks out of place to me.

 

***

Sec = 4. Exposing congestion.

&= #8220;We argue that congestion needs.... More specifically, a network = needs to be able to measure how much congestion any particular traffic = expects to cause between the monitoring point in the network and the = destination ("rest-of-path congestion"). This would be a new = capability.”


C= ould you add more clarity and explanation on why local congestion = information at any given node is not sufficient. Why does a node require = congestion information from a monitoring point to the destination to be = able to manage its own congestion? A succinct explanation and/or an = example will go a long = way.

 

------=_NextPart_000_002D_01CBE489.FE114BF0-- From dave.mcdysan@verizon.com Thu Mar 17 05:24:43 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AE843A6969 for ; Thu, 17 Mar 2011 05:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.502 X-Spam-Level: X-Spam-Status: No, score=-3.502 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gG7jwYBPyEpm for ; Thu, 17 Mar 2011 05:24:41 -0700 (PDT) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id 57FE23A6915 for ; Thu, 17 Mar 2011 05:24:41 -0700 (PDT) Received: from fldsmtpi02.verizon.com (fldsmtpi02.verizon.com [166.68.71.144]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p2HCPs59010189 for ; Thu, 17 Mar 2011 08:26:06 -0400 (EDT) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.63,198,1299456000"; d="scan'208,217";a="13149842" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi02.verizon.com with ESMTP; 17 Mar 2011 12:25:54 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.240]) by FHDP1LUMXC7HB02.us.one.verizon.com ([2002:a644:3bbd::a644:3bbd]) with mapi; Thu, 17 Mar 2011 08:25:53 -0400 To: Nandita Dukkipati , Toby Moncaster , John Leslie , Bob Briscoe , "Woundy, Richard" Date: Thu, 17 Mar 2011 08:25:52 -0400 Thread-Topic: comments/suggestions on draft-ietf-conex-concepts-uses-01 Thread-Index: AcvknnVh4fMxjRLcT8GBhb9Gm8UsNA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C9A772F011713davemcdysanoneverizoncom_" MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] comments/suggestions on draft-ietf-conex-concepts-uses-01 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 12:24:43 -0000 --_000_C9A772F011713davemcdysanoneverizoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Nandita, A few responses to your questions on the new section in line below prefixed= by DM which were previously posted to the list that I believe (at least pa= rtially) address your comments. I propose that the working group work toward how to organize/merge/move the= new text better into the existing outline. Thanks, Dave From: Nandita Dukkipati > Date: Thu, 17 Mar 2011 03:28:25 -0400 To: Toby Moncaster >, John Le= slie >, Bob Briscoe >, "Woundy, Richard" >, David McDysan > Cc: "conex@ietf.org" > Subject: comments/suggestions on draft-ietf-conex-concepts-uses-01 On reading the latest draft, I have three high level comments roughly in th= e following order of importance- *** Statistical Multiplexing over different timescales. This reads like a rambling story. I have read and re-read it, and I am stil= l left wondering - * What is _the_ main point? How about starting the section by stating your = main point upfront as opposed leaving it to the reader to figure it out. DM - From my 3/10/11 on the list 1) A few "heavy" users generate most of the traffic and service providers want to better assign the cost (of provisioning an upgrade) for the time when congestion is anticipated to occur. Existing mechanisms, flat rate, bandwidth tier shapers, and usage tiers do not completely address the service provider objective and/or are not popular with users. 2) In some service provider networks shapers are implemented to limit the maximum bandwidth per user. Although overflow or marking in the shaper queue appears as congestion to the receiver, this "self-congestion" differs from congestion of a shared resource since a remedy could be to indicate to the user that changing the shaper rate (i.e., "go faster") would alleviate "self-congestion." * Why and how is this use case distinct from that of traffic management whi= ch already seems to have a broad scope? Is it really distinct? DM - From my 3/11/11 post to the list Editorially, this (section 5.1) could be a place to state the problem with = an additional reference to [Varian]. Editorially, bandwidth tier pricing could be added to section 3.1, Existing approaches. I am now thinking that editorially a separate section is not a good idea, since the points can be merged into the existing outline, in at least the places mentioned above. I think adding that the use case needs to meet service provider economic congestion needs as well as be acceptable to users is an important point not in the current text. Traffic management (aka policing) may have the problem that it may not be popular with user. There has already been negative feedback on the list regarding policing (IMO, Traffic management is a better term). * [minor] Why not make this use case a part of Sec. 5? DM =96 the minutes recorded adding the agreement to add this as a new secti= on. (A new subsection, and or merging thoughts with other use cases (e.g., = as suggested above) is what I believe the wg needs to discuss. *** Partial versus full deployment. Clearly, it belongs to this draft. But why is it a part of use cases? Looks= out of place to me. *** Sec 4. Exposing congestion. =93We argue that congestion needs.... More specifically, a network needs to= be able to measure how much congestion any particular traffic expects to c= ause between the monitoring point in the network and the destination ("rest= -of-path congestion"). This would be a new capability.=94 Could you add more clarity and explanation on why local congestion informat= ion at any given node is not sufficient. Why does a node require congestion= information from a monitoring point to the destination to be able to manag= e its own congestion? A succinct explanation and/or an example will go a lo= ng way. --_000_C9A772F011713davemcdysanoneverizoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Nandita,

A few responses to your questions on the new section in line below pr= efixed by DM which were previously posted to the list that I believe (at le= ast partially) address your comments.

I propose th= at the working group work toward how to organize/merge/move the new text be= tter into the existing outline. 

Thanks,

Dave

From: Nandita Dukkipati <nanditad@google.com>
Da= te: Thu, 17 Mar 2011 03:28:25 -0400
To: Toby Moncaster <t= oby@moncaster.com>, John Leslie <= john@jlc.net>, Bob Briscoe <bob.briscoe@bt.com>, "Woundy, Richard" <Richard_Woundy@cable.comcast.com&= gt;, David McDysan <dave= .mcdysan@one.verizon.com>
Cc: "conex@ietf.org" <= conex@ietf.org>
Subject: comments/suggestions on draft-ietf-conex= -concepts-uses-01

On reading the latest draft, I ha= ve three high level comments roughly in the following order of importance-<= div>
*** 
Statistical Multi= plexing over different timescales.
This reads like a rambling story. I have read and re-read it,= and I am still left wondering -
* What is _the_= main point? How about starting the section by stating your main point upfr= ont as opposed leaving it to the reader to figure it out.

DM - From my 3/10/11 on the list
1) A = few "heavy" users generate most of the traffic and service provid= ers
want to = better assign the cost (of provisioning an upgrade) for the time
when congestion is ant= icipated to occur. Existing mechanisms, flat rate,
bandwidth tier shapers, and usage ti= ers do not completely address the
service provider objective and/or are not popular wit= h users.
2) In some= service provider networks shapers are implemented to limit the
maximum bandwidth per u= ser. Although overflow or marking in the shaper
queue appears as congestion to the rece= iver,  this "self-congestion"
differs from congestion of a shared r= esource since a remedy could be to
indicate to the user that changing the shaper rate (= i.e., "go faster")
would alleviate "self-congestion."

* Why and how is thi= s use case distinct from that of traffic management which already seems to = have a broad scope? Is it really distinct?
<= br>
DM - From my 3/11/11 post to the list

Editorially, th= is (section 5.1) could be a place to state the problem with an additional
reference to = [Varian].
Editorial= ly, bandwidth tier pricing could be added to section 3.1,
Existing approaches.
<= div style=3D"font-family: Consolas; font-size: medium; ">
I am now thinking that ed= itorially a separate section is not a good idea,
since the points can be merged into th= e existing outline, in at least the
places mentioned above.

I think adding that the use case needs to meet= service provider economic
congestion needs as well as be acceptable to users is an imp= ortant point
not in the current text. Traffic management (aka policing) may have the
problem that i= t may not be popular with user. There has already been
negative feedback on the list re= garding policing (IMO, Traffic management
is a better term).

=

* [minor] Why = not make this use case a part of Sec. 5?
DM =96 the minutes recorded adding the agreement to add this as= a new section. (A new subsection, and or merging thoughts with other use c= ases (e.g., as suggested above) is what I believe the wg needs to discuss.<= /div>

= ***
Partial versus full deployment.
= Clearl= y, it belongs to this draft. But why is it a part of use cases? Looks out o= f place to me.

***
Sec 4. Exp= osing congestion.
= =93We argue that congestion need= s.... More specifically, a network needs to be able to measure how much con= gestion any particular traffic expects to cause between the monitoring poin= t in the network and the destination ("rest-of-path congestion").= This would be a new capability.=94

Could you add = more clarity and explanation on why local congestion information at any giv= en node is not sufficient. Why does a node require congestion information f= rom a monitoring point to the destination to be able to manage its own cong= estion? A succinct explanation and/or an example will go a long way.=
=

--_000_C9A772F011713davemcdysanoneverizoncom_-- From nanditad@google.com Sat Mar 19 00:14:08 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 840533A6A15 for ; Sat, 19 Mar 2011 00:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtluWP75oYyS for ; Sat, 19 Mar 2011 00:14:06 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 2584D3A6A0E for ; Sat, 19 Mar 2011 00:14:05 -0700 (PDT) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id p2J7FXKS031840 for ; Sat, 19 Mar 2011 00:15:34 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1300518935; bh=6XMl63gLrFXhoKMaFRAsNH2zgiw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=R5cgBHHsDRgP+1eQd6sNXbHatTq0dq0R/XKceDBMHtr/jTfE4JChFLDAZq6eS9ocE LfUcgeQAaSvP7RZ2aqpIA== Received: from vws7 (vws7.prod.google.com [10.241.21.135]) by kpbe11.cbf.corp.google.com with ESMTP id p2J7FVgx014254 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 19 Mar 2011 00:15:32 -0700 Received: by vws7 with SMTP id 7so5114182vws.35 for ; Sat, 19 Mar 2011 00:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XgmDsW3znkZwjHJWb/wZr9HRRw1xMN7GN2BL8FDBYuE=; b=ApTqA37spGLUe07UkZOmRRoCWVecH3Fs8xVbwUXLggl3ZW2/Y3VEFjYvPmWhaS3ePG rlR7lhJ2BcNM4APpdP+A== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=yMHnQm+PEP10qRX0LwMH5ElSo/n+HrTEr33qwH6rZYnjBf48XWpWiez20RY1SXaQ1e pQWl1stHGa9WcRGUnhtA== MIME-Version: 1.0 Received: by 10.52.90.67 with SMTP id bu3mr2712381vdb.248.1300518931440; Sat, 19 Mar 2011 00:15:31 -0700 (PDT) Received: by 10.220.52.136 with HTTP; Sat, 19 Mar 2011 00:15:31 -0700 (PDT) In-Reply-To: <001601cbe489$1e800530$5b800f90$@com> References: <001601cbe489$1e800530$5b800f90$@com> Date: Sat, 19 Mar 2011 00:15:31 -0700 Message-ID: From: Nandita Dukkipati To: Toby Moncaster Content-Type: multipart/alternative; boundary=20cf307f3860eea616049ed0a8d8 X-System-Of-Record: true Cc: conex@ietf.org, "Woundy, Richard" Subject: Re: [conex] comments/suggestions on draft-ietf-conex-concepts-uses-01 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2011 07:14:08 -0000 --20cf307f3860eea616049ed0a8d8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > > Thanks for the comments. Just for the record can you confirm whether thes= e > are comments as WG chair, or as an individual contributor? > I should have made that clear in the first place - I am making my comments as an individual contributor. > Addressing your three points in order: > > > > Statistical multiplexing. This is a new section and so there is clearly a > lot of work needed to tidy it up and possibly to rationalise where it fit= s > in the structure of the document. Hopefully Dave can answer what the main > point is... As I understand things, Dave=92s view is that the main differ= ence > is the measure of activity ratio that he introduces. As he sees things, t= his > is a different congestion measure to that used in the abstract mechanism = and > so stands apart from the other use cases... > Clearly, this section needs work to bring out the essence of the matter in = a succinct way. I don't quite get the main point of the section to offer any meaningful help. > **** > > Partial vs Full Deployment. This does need a bit of work. And you are rig= ht > that it has now ended up in a strange place within the document. I will m= ove > it to its own section in -02 > Sounds good to me. **** > > Exposing congestion. We are not arguing that a node needs this informatio= n > to perform local congestion management. But it does need this information= if > it is going to be held to account for dumping large quantities of congest= ion > on a node further downstream. In other words it allows the NETWORK to mak= e > better congestion management decisions and avoids any tragedy of the > commons. Economists like Bob talk about maximising social welfare. I just > think of it as making the whole network run more efficiently (which benef= its > everyone). > > > > You could make a bad analogy: At 8 in the morning everyone living in a ci= ty > looks out of their windows and sees that the road outside their house is > clear (no congestion). So lots of them decide to get in their cars and he= ad > off to the mall. As soon as they reach the freeway there is utter gridloc= k =96 > the congestion wasn=92t where they were, it was further along the path an= d > they just made it much worse. In fact in such cases we do make use of > something that gives us knowledge of the congestion further along the pat= h, > namely local traffic reports on the radio (or smartphone, satnav, etc). > That was actually a good explanation. It's worthwhile trying to frame what you explained in a formal way with an example taken from the networking context. > > > Toby > > > > *From:* Nandita Dukkipati [mailto:nanditad@google.com] > *Sent:* 17 March 2011 07:28 > *To:* Toby Moncaster; John Leslie; Bob Briscoe; Woundy, Richard; Mcdysan, > David E > *Cc:* conex@ietf.org > > *Subject:* comments/suggestions on draft-ietf-conex-concepts-uses-01 > > > > On reading the latest draft, I have three high level comments roughly in > the following order of importance- > > > > *** > > Statistical Multiplexing over different timescales. > This reads like a rambling story. I have read and re-read it, and I am > still left wondering - > > * What is _the_ main point? How about starting the section by stating you= r > main point upfront as opposed leaving it to the reader to figure it out. > > * Why and how is this use case distinct from that of traffic management > which already seems to have a broad scope? Is it really distinct? > * [minor] Why not make this use case a part of Sec. 5? > > > > *** > Partial versus full deployment. > Clearly, it belongs to this draft. But why is it a part of use cases? Loo= ks > out of place to me. > > > > *** > > Sec 4. Exposing congestion. > > =93We argue that congestion needs.... More specifically, a network needs = to > be able to measure how much congestion any particular traffic expects to > cause between the monitoring point in the network and the destination > ("rest-of-path congestion"). This would be a new capability.=94 > > > Could you add more clarity and explanation on why local congestion > information at any given node is not sufficient. Why does a node require > congestion information from a monitoring point to the destination to be a= ble > to manage its own congestion? A succinct explanation and/or an example wi= ll > go a long way. > > > --20cf307f3860eea616049ed0a8d8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

= Thanks for the comments. Just for the record can you confirm whether these = are comments as WG chair, or as an individual contributor?


I should have made that clear = in the first place - I am making my comments as an individual contributor.<= /div>
=A0

=A0Add= ressing your three points in order:

=A0

Statistical multiplexing. This is a new section and so there is clearly= a lot of work needed to tidy it up and possibly to rationalise where it fi= ts in the structure of the document. Hopefully Dave can answer what the mai= n point is... As I understand things, Dave=92s view is that the main differ= ence is the measure of activity ratio that he introduces. As he sees things= , this is a different congestion measure to that used in the abstract mecha= nism and so stands apart from the other use cases...


Clearly, this section needs wo= rk to bring out the essence of the matter in a succinct way. I don't qu= ite get the main point of the section to offer any meaningful help.
=A0

****

Parti= al vs Full Deployment. This does need a bit of work. And you are right that= it has now ended up in a strange place within the document. I will move it= to its own section in -02


Sounds good to me.=A0

****

Exposing congestion. We ar= e not arguing that a node needs this information to perform local congestio= n management. But it does need this information if it is going to be held t= o account for dumping large quantities of congestion on a node further down= stream. In other words it allows the NETWORK to make better congestion mana= gement decisions and avoids any tragedy of the commons. Economists like Bob= talk about maximising social welfare. I just think of it as making the who= le network run more efficiently (which benefits everyone).

=A0

You could make a bad analogy: At 8 in the morning everyone living in a = city looks out of their windows and sees that the road outside their house = is clear (no congestion). So lots of them decide to get in their cars and h= ead off to the mall. As soon as they reach the freeway there is utter gridl= ock =96 the congestion wasn=92t where they were, it was further along the p= ath and they just made it much worse. In fact in such cases we do make use = of something that gives us knowledge of the congestion further along the pa= th, namely local traffic reports on the radio (or smartphone, satnav, etc).=


That was actually a good expla= nation. It's worthwhile trying to frame what you explained in a formal = way with an example taken from the networking context.=A0
=A0=A0<= /div>

=A0

Toby

=A0

From: Nandita Dukkipati [mailto:nanditad@google.com]
Sent: 17 March 2011 07:28
To: Toby Moncaster; John Leslie;= Bob Briscoe; Woundy, Richard; Mcdysan, David E
Cc: conex@ietf.org


Subject: comments/suggestions on draft-ietf-conex-concepts-uses-= 01

=A0

On reading the latest draft, I have three high level comments roughly = in the following order of importance-

=A0

=

**= *=A0

Statistical Multiplexing over different timescales.=
This reads like a rambling st= ory. I have read and re-read it, and I am still left wondering -

* What is _the_ main point? How about starting the section= by stating your main point upfront as opposed leaving it to the reader to = figure it out.

* Why and how is this use case distinct from that of traffic mana= gement which already seems to have a broad scope? Is it really distinct?
* [minor] Why not= make this use case a part of Sec. 5?

=A0

***
Partial versus fu= ll deployment.
Clearly, it belongs to this draf= t. But why is it a part of use cases? Looks out of place to me.

=A0

***

Sec 4. Exposing congestion.

=93We argue that congestion needs.... More specifically, a netwo= rk needs to be able to measure how much congestion any particular traffic e= xpects to cause between the monitoring point in the network and the destina= tion ("rest-of-path congestion"). This would be a new capability.= =94


Could you add more clarity and explanation on why loca= l congestion information at any given node is not sufficient. Why does a no= de require congestion information from a monitoring point to the destinatio= n to be able to manage its own congestion? A succinct explanation and/or an= example will go a long way.

=A0


--20cf307f3860eea616049ed0a8d8-- From john@jlc.net Mon Mar 21 11:39:09 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AB203A6821 for ; Mon, 21 Mar 2011 11:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.535 X-Spam-Level: X-Spam-Status: No, score=-106.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TXJ5sEL5Ks2 for ; Mon, 21 Mar 2011 11:39:08 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 814A73A6818 for ; Mon, 21 Mar 2011 11:39:07 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 4076B33C2A; Mon, 21 Mar 2011 14:40:40 -0400 (EDT) Date: Mon, 21 Mar 2011 14:40:40 -0400 From: John Leslie To: conex@ietf.org Message-ID: <20110321184040.GB65272@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [conex] 6MAN WG Last Call: X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 18:39:09 -0000 I strongly recommend reading this draft, now in WGLC in 6MAN (the WG responsible for ipv6 protocol changes): http://tools.ietf.org/html/draft-ietf-6man-flow-update-04 I do not have any changes to propose -- I regard it as friendly to our needs. Nonetheless, it does represent (IMHO) the intents of the 6MAN WG about Flow Labels; and it explains the environment we are designing into. After reading it, we might want to discuss possible ConEx uses of this field... -- John Leslie ----- Forwarded message from Bob Hinden ----- Date: Mon, 21 Mar 2011 10:15:42 -0700 From: Bob Hinden Subject: 6MAN WG Last Call: To: 6man Mailing List Cc: Brian Haberman , Bob Hinden X-Mailer: Apple Mail (2.1082) All, This message starts a 6MAN Working Group Last Call on advancing: Title : Rationale for update to the IPv6 flow label specification Author(s) : S. Amante, et al. Filename : draft-ietf-6man-flow-update-04.txt Pages : 12 Date : 2011-03-13 http://tools.ietf.org/html/draft-ietf-6man-flow-update-04 as an Informational RFC. Substantive comments and statements of support for advancing this document should be directed to the mailing list. Editorial suggestions can be sent to the authors. This last call will end on 4 April 2011. Regards, Bob Hinden & Brian Haberman 6MAN Chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ----- End forwarded message ----- From nanditad@google.com Tue Mar 22 00:34:04 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 770B43A6950 for ; Tue, 22 Mar 2011 00:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPjqNssZ34oo for ; Tue, 22 Mar 2011 00:34:01 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 1390B3A6909 for ; Tue, 22 Mar 2011 00:34:00 -0700 (PDT) Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id p2M7ZWT2012272 for ; Tue, 22 Mar 2011 00:35:33 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1300779333; bh=HHTBhRP21RJzKvbmrDwprWAzWC0=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=XrhJ9/r7e/RxAlSH8RteZ1NlmIjvOLExpUPplXpCg1mhpJima25JJyVXvPjvRhGf8 NG52enuJfpFrzg3jYqiMQ== Received: from gwb15 (gwb15.prod.google.com [10.200.2.15]) by kpbe13.cbf.corp.google.com with ESMTP id p2M7ZVk3029296 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 22 Mar 2011 00:35:31 -0700 Received: by gwb15 with SMTP id 15so3170447gwb.12 for ; Tue, 22 Mar 2011 00:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=AWvwQftXdsN6skJLbDbHvAqjo2RhcE5pnI0PmEhPShU=; b=MEunjUcNIQTUVRW0w3c+lmkiQxiTeoLKUIx7U0KNvt5nJ8meZI+NfDD7ZC+sNgb2le MpxjHG6/dDVzzwxJTR3w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:date:message-id:subject:from:to:content-type; b=Fdd6U+KGmSKB4sobsoLwD6lWK8cPpikb2D82Al4nqrZPZzbUICsg0ZaRkinxZCVwFC a/d59q0FYA14ErqWVu+Q== MIME-Version: 1.0 Received: by 10.90.136.14 with SMTP id j14mr4729567agd.154.1300779330442; Tue, 22 Mar 2011 00:35:30 -0700 (PDT) Received: by 10.91.219.10 with HTTP; Tue, 22 Mar 2011 00:35:30 -0700 (PDT) Date: Tue, 22 Mar 2011 00:35:30 -0700 Message-ID: From: Nandita Dukkipati To: conex@ietf.org Content-Type: multipart/alternative; boundary=00163628354eec1835049f0d4989 X-System-Of-Record: true Subject: [conex] Draft agenda for Conex IETF-80 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 07:34:04 -0000 --00163628354eec1835049f0d4989 Content-Type: text/plain; charset=ISO-8859-1 Hi. Conex is scheduled to meet on Thursday afternoon (31 March) at Prague IETF. Please find the draft agenda at this link: http://www.ietf.org/proceedings/80/agenda/conex.txt Please let us know if you have any suggestions on the agenda. -Nandita --00163628354eec1835049f0d4989 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi.

Conex is scheduled to meet on Thursday afternoon (31= March) at Prague IETF.=A0Please find the draft agenda at this link:=A0http://www= .ietf.org/proceedings/80/agenda/conex.txt

Please let us know if you have any suggestions on the agenda.= =A0

-Nandita
--00163628354eec1835049f0d4989-- From john@jlc.net Tue Mar 22 05:56:45 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B91B28C117 for ; Tue, 22 Mar 2011 05:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.537 X-Spam-Level: X-Spam-Status: No, score=-106.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKNwUx3wPWPd for ; Tue, 22 Mar 2011 05:56:44 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id AAD2E28C113 for ; Tue, 22 Mar 2011 05:56:44 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id CB7B733C21; Tue, 22 Mar 2011 08:58:17 -0400 (EDT) Date: Tue, 22 Mar 2011 08:58:17 -0400 From: John Leslie To: conex@ietf.org Message-ID: <20110322125817.GD65272@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Subject: [conex] draft-krishnan-conex-ipv6-02 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 12:56:45 -0000 Nandita Dukkipati wrote: > > Conex is scheduled to meet on Thursday afternoon (31 March) at Prague > IETF. Please find the draft agenda at this link: > http://www.ietf.org/proceedings/80/agenda/conex.txt ]... ] Suresh Krishnan ] An update on IPv6 options ] http://www.ietf.org/id/draft-krishnan-conex-ipv6-02.txt ] 20 minutes. This is unquestionably worth agenda time; but I also think it's worth some discussion before Prague. Specifically, I think we need to be clearer about requirement 1: ] ] R-1: The marking mechanism needs to be visible to all conex-capable ] nodes on the path. Later in the draft, this is used to rule out Destination Options: ] ] 4.2. Destination options ] ] The base IPv6 standard [RFC2460] defines the destination options. ] These options are processed only by the ultimate receiver of the ] packet (as specified in the Destination Address field) and not by ] nodes on the path. Hence they do not meet R-1. That is not my interpretation of R-1. They're entirely "visible", being in a known place, easy to find, well delineated so we could concentrate on exactly what we're looking for. Furthermore, this seems to be where the 6MAN WG points everyone who suggests adding a new Extension Header. I do not interpret R-1 to mean that ConEx marking needs to be _observed_ by every node along the path. -- John Leslie From toby@moncaster.com Tue Mar 22 07:10:35 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D267B28C11D for ; Tue, 22 Mar 2011 07:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2SeHzjaY1Yc for ; Tue, 22 Mar 2011 07:10:34 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by core3.amsl.com (Postfix) with ESMTP id 1F66C28C0D0 for ; Tue, 22 Mar 2011 07:10:32 -0700 (PDT) Received: from TobysHP (host86-149-183-12.range86-149.btcentralplus.com [86.149.183.12]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0LhNIm-1Pfspf3a52-00meRg; Tue, 22 Mar 2011 15:12:04 +0100 From: "Toby Moncaster" To: "'John Leslie'" , References: <20110322125817.GD65272@verdi> In-Reply-To: <20110322125817.GD65272@verdi> Date: Tue, 22 Mar 2011 14:12:03 -0000 Message-ID: <004301cbe89b$1e7eea40$5b7cbec0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvokNI36Dpf3gq7QwS0SygOkjFSdQACaODg Content-Language: en-gb X-Provags-ID: V02:K0:qCXqvgfBoXwv+1WSazMzn08/gtbF/FXo1DvAy6/kFU3 ubgYXtdhbJ9u0YQqeqsY2jPlFz4VwCxmRT27vwrp+gxIW18TMS TcEaYeZ9+tqTusH7bZHbaKQZid2JPsbI4fs3W8/Kmc9NVHlhtp OUzFu+9eJkAJ6Wn6Ha/Y4TjVR3RyJc3lAFJU4Axci/Kf+co0q5 zNmIdrwA4ytC0pzR5HQhOaS4X/Uybu6Cuucu6iick8= Subject: Re: [conex] draft-krishnan-conex-ipv6-02 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 14:10:35 -0000 > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of John Leslie > Sent: 22 March 2011 12:58 > To: conex@ietf.org > Subject: [conex] draft-krishnan-conex-ipv6-02 > > Nandita Dukkipati wrote: > > > > Conex is scheduled to meet on Thursday afternoon (31 March) at Prague > > IETF. Please find the draft agenda at this link: > > http://www.ietf.org/proceedings/80/agenda/conex.txt > ]... > ] Suresh Krishnan > ] An update on IPv6 options > ] http://www.ietf.org/id/draft-krishnan-conex-ipv6-02.txt > ] 20 minutes. > > This is unquestionably worth agenda time; but I also think it's > worth some discussion before Prague. > > Specifically, I think we need to be clearer about requirement 1: > ] > ] R-1: The marking mechanism needs to be visible to all conex-capable > ] nodes on the path. > > Later in the draft, this is used to rule out Destination Options: > ] > ] 4.2. Destination options > ] > ] The base IPv6 standard [RFC2460] defines the destination options. > ] These options are processed only by the ultimate receiver of the > ] packet (as specified in the Destination Address field) and not by > ] nodes on the path. Hence they do not meet R-1. > > That is not my interpretation of R-1. > > They're entirely "visible", being in a known place, easy to find, > well delineated so we could concentrate on exactly what we're looking > for. I agree that "visible" is not the same as "actively observed". > > Furthermore, this seems to be where the 6MAN WG points everyone > who suggests adding a new Extension Header. We would certainly be well advised to ensure our work is not in opposition to 6MAN - there are more than enough problems as it is without creating new ones. I have to say I haven't really been following 6MAN though so I can't really comment on how sensible their advice is. > > I do not interpret R-1 to mean that ConEx marking needs to be > _observed_ by every node along the path. The key thing is that (some) ConEx marking may (possibly) need to be altered along the path. Bob had lots of stuff in an ID a couple of years ago talking about nodes that effectively act as congestion control endpoints but which aren't at the end of the e2e path. He had a natty name for these which I have completely forgotten! Toby > > -- > John Leslie > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From bob.briscoe@bt.com Tue Mar 22 12:04:44 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 931AC28C11E for ; Tue, 22 Mar 2011 12:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.433 X-Spam-Level: X-Spam-Status: No, score=-3.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h73K79RrLqH3 for ; Tue, 22 Mar 2011 12:04:43 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 74D1D28C0F8 for ; Tue, 22 Mar 2011 12:04:43 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Mar 2011 19:06:16 +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); Tue, 22 Mar 2011 19:06: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 1300820774584; Tue, 22 Mar 2011 19:06:14 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.131.97]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p2MJ6ELC026708; Tue, 22 Mar 2011 19:06:14 GMT Message-Id: <201103221906.p2MJ6ELC026708@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 22 Mar 2011 19:06:17 +0000 To: Toby Moncaster From: Bob Briscoe In-Reply-To: <004301cbe89b$1e7eea40$5b7cbec0$@com> References: <20110322125817.GD65272@verdi> <004301cbe89b$1e7eea40$5b7cbec0$@com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 22 Mar 2011 19:06:15.0774 (UTC) FILETIME=[37CF07E0:01CBE8C4] Cc: conex@ietf.org Subject: Re: [conex] draft-krishnan-conex-ipv6-02 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 19:04:44 -0000 Toby, John, At 14:12 22/03/2011, Toby Moncaster wrote: > > That is not my interpretation of R-1. > > > > They're entirely "visible", being in a known place, easy to find, > > well delineated so we could concentrate on exactly what we're looking > > for. > >I agree that "visible" is not the same as "actively observed". Perhaps Suresh was thinking they would not be visible if IPsec ESP were used (I believe destination options are considered e2e and therefore encrypted). If so, it should be clear that IPsec is the constraint in this case, as there may be a work-round. I think there are "absolute requirements" and "requirements with wriggle-room". For instance, there is perhaps a need to deploy ConEx in order to prove that it is worthwhile, so that there is a better case to take up IP header space for it. Then the initial deployment might have to rule out some constraints (like IPsec). Not ideal, but ideal is the enemy of the good. > > > > Furthermore, this seems to be where the 6MAN WG points everyone > > who suggests adding a new Extension Header. > >We would certainly be well advised to ensure our work is not in opposition >to 6MAN - there are more than enough problems as it is without creating new >ones. I have to say I haven't really been following 6MAN though so I can't >really comment on how sensible their advice is. > > > > > I do not interpret R-1 to mean that ConEx marking needs to be > > _observed_ by every node along the path. > >The key thing is that (some) ConEx marking may (possibly) need to be altered >along the path. In requirements for the ConEx signal, abstract-mech says: "The ConEx Signal SHOULD be immutable once set by the transport sender. " >Bob had lots of stuff in an ID a couple of years ago talking about nodes >that effectively act as congestion control endpoints but which aren't at the >end of the e2e path. He had a natty name for these which I have completely >forgotten! I think you're looking for "load regulator". This is a node potentially midpath that receives feedback and regulates load. PWE3 has some scenarios like this. So does PCN. Also there might be "sender proxy" scenarios. These nodes are effectively acting as the sender, but I guess we need to think about this some more. E.g. How a mid-path sender-proxy that wants to set ConEx signals interacts with the original source that might have deliberately not set ConEx. And exactly what is a mid-path load regulator allowed to do with ConEx signals, because effectively these architectures dived a path up into segments, each with their own congestion control feedback loop? But perhaps these are corner-cases? Bob >Toby ________________________________________________________________ Bob Briscoe, BT Innovate & Design From karagian@cs.utwente.nl Tue Mar 22 13:16:27 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B2EC28C166 for ; Tue, 22 Mar 2011 13:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oxn8EukBXrPA for ; Tue, 22 Mar 2011 13:16:26 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id 5377B28C12E for ; Tue, 22 Mar 2011 13:16:21 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p2MKHZUH012822; Tue, 22 Mar 2011 21:17:35 +0100 (MET) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Tue, 22 Mar 2011 20:17:45 +0000 To: "conex@ietf.org" Date: Tue, 22 Mar 2011 20:17:45 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 22 Mar 2011 21:17:44 +0100 (MET) Subject: [conex] Observations regarding the Conex concept X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 20:16:27 -0000 Hi all After discussing with Mirja and based on the previous Conex email discussions with Bob, I have derived some observations regarding the Conex concept, see below. These observations are expressed in questions. Hopefully we can answer them easily. Observation 1: Must the sender (of the data path and Conex exposure signals) be able to identify which packets were lost in the downstream direction, in addition to the calculated number of ECN marked packets in the downstream direction? Observation 2: If a sender sent a packet that carried a Congestion exposure signal and realizes that this packet is lost, should this sender include the same Congestion exposure signal in a retransmitted packet? Observation 3: Should a router/device not preferentially drop ECN congested marked packets? Observation 4: Should a router/device not preferentially drop Conex exposure marked packets? Observation 5: Should the Conex WG specify the operation of all Conex aware nodes? Best regards, Georgios From suresh.krishnan@ericsson.com Tue Mar 22 15:23:19 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64DBB3A6807 for ; Tue, 22 Mar 2011 15:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.566 X-Spam-Level: X-Spam-Status: No, score=-104.566 tagged_above=-999 required=5 tests=[AWL=2.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKrf3ZwBp6pS for ; Tue, 22 Mar 2011 15:23:18 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 4E1D73A6803 for ; Tue, 22 Mar 2011 15:23:18 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p2MMOdPS031734 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Mar 2011 17:24:51 -0500 Received: from [142.133.10.107] (147.117.20.213) by eusaamw0711.eamcs.ericsson.se (147.117.20.179) with Microsoft SMTP Server id 8.3.137.0; Tue, 22 Mar 2011 18:24:41 -0400 Message-ID: <4D8920D8.8030604@ericsson.com> Date: Tue, 22 Mar 2011 18:21:12 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: John Leslie References: <20110322125817.GD65272@verdi> In-Reply-To: <20110322125817.GD65272@verdi> Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Cc: "conex@ietf.org" Subject: Re: [conex] draft-krishnan-conex-ipv6-02 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 22:23:19 -0000 Hi John, On 03/22/11 08:58, John Leslie wrote: > Nandita Dukkipati wrote: >> Conex is scheduled to meet on Thursday afternoon (31 March) at Prague >> IETF. Please find the draft agenda at this link: >> http://www.ietf.org/proceedings/80/agenda/conex.txt > ]... > ] Suresh Krishnan > ] An update on IPv6 options > ] http://www.ietf.org/id/draft-krishnan-conex-ipv6-02.txt > ] 20 minutes. > > This is unquestionably worth agenda time; but I also think it's > worth some discussion before Prague. > > Specifically, I think we need to be clearer about requirement 1: > ] > ] R-1: The marking mechanism needs to be visible to all conex-capable > ] nodes on the path. > > Later in the draft, this is used to rule out Destination Options: > ] > ] 4.2. Destination options > ] > ] The base IPv6 standard [RFC2460] defines the destination options. > ] These options are processed only by the ultimate receiver of the > ] packet (as specified in the Destination Address field) and not by > ] nodes on the path. Hence they do not meet R-1. > > That is not my interpretation of R-1. > > They're entirely "visible", being in a known place, easy to find, > well delineated so we could concentrate on exactly what we're looking > for. Given the current state of IPv6, an intermediate node is not allowed to even examine destination options. Unfortunately, RFC2460 does not follow RFC2119 language. The following text is present in Section 4. "With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (...) identified in the Destination Address field of the IPv6 header" The exception of course is the Hop-by-hop extension header. Of course we can code conex aware routers on-path to look into the dest opts header, but that will rule out IPsec ESP protected packets (as Bob pointed out). This is of course a limitation we can decide to live with, but once the flow label bits are gone, they are gone forever :-(. > > Furthermore, this seems to be where the 6MAN WG points everyone > who suggests adding a new Extension Header. Correct. But extension headers and dest opts have end-to-end significance and not hop-by-hop significance. So I think that the recommendation is sound. > > I do not interpret R-1 to mean that ConEx marking needs to be > _observed_ by every node along the path. I was more thinking that the marking needs to be _observable_ by every node along the path, and a dest option is not legally observable by an intermediate node. Thanks Suresh From bob.briscoe@bt.com Wed Mar 23 11:50:13 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0336D3A68C1 for ; Wed, 23 Mar 2011 11:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.694 X-Spam-Level: X-Spam-Status: No, score=-2.694 tagged_above=-999 required=5 tests=[AWL=-0.584, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2-Hu8nsIAEh for ; Wed, 23 Mar 2011 11:50:12 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id C15903A68BF for ; Wed, 23 Mar 2011 11:50:11 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Mar 2011 18:51:44 +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); Wed, 23 Mar 2011 18:51:44 +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 130090630391; Wed, 23 Mar 2011 18:51:43 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.131.97]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p2NIpesF031028; Wed, 23 Mar 2011 18:51:40 GMT Message-Id: <201103231851.p2NIpesF031028@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 23 Mar 2011 18:51:05 +0000 To: John Leslie , Toby Moncaster 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: 23 Mar 2011 18:51:44.0549 (UTC) FILETIME=[5AEE6550:01CBE98B] Cc: ConEx IETF list Subject: [conex] Missing concept from conex-concepts-uses ? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 18:50:13 -0000 John, Toby, Altho we're co-authors, I thought I would straight off open this thought up to the whole list, as the w-g owns this doc. I just started re-reading the draft with my "Mr Skeptical" hat on. In other words, I put myself in a devil's advocate frame of mind where I start off hating it and have to be convinced. I immediately noticed it doesn't start from "What's the problem with over-provisioning?" Also, I just did a presentation to L2/L3 colleagues which started with why congestion is not strongly related to utilisation, and they all found it really difficult to 'get it'. This seems to be a cause of confusion for people coming from non-transport backgrounds. I think I've worked out how to explain it (John, I know this is one of your bug-bears too). Do you agree it would be useful to have a brief discussion of these issues near the start? I can propose some text, if you want. Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From john@jlc.net Wed Mar 23 12:30:41 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2F5428C0F9 for ; Wed, 23 Mar 2011 12:30:41 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cbwtu-jhRrvd for ; Wed, 23 Mar 2011 12:30:40 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id B247328C0F1 for ; Wed, 23 Mar 2011 12:30:40 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id AA8D833C2A; Wed, 23 Mar 2011 15:32:14 -0400 (EDT) Date: Wed, 23 Mar 2011 15:32:14 -0400 From: John Leslie To: Georgios Karagiannis Message-ID: <20110323193214.GG65272@verdi> References: 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.org" Subject: Re: [conex] Observations regarding the Conex concept X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 19:30:41 -0000 Georgios Karagiannis wrote: > > After discussing with Mirja and based on the previous Conex email > discussions with Bob, I have derived some observations regarding the > Conex concept, see below. These observations are expressed in questions. > Hopefully we can answer them easily. I'm not sure I'm the best person to answer, but here goes: > Observation 1: > Must the sender (of the data path and Conex exposure signals) be able to > identify which packets were lost in the downstream direction, in > addition to the calculated number of ECN marked packets in the > downstream direction? No. Well, at least not in order to be fully ConEx-enabled... _If_ the sender is speaking TCP, that is required by TCP; but for ConEx purposes, whether the lost packets are ever re-transmitted is quite strictly out-of-scope. > Observation 2: > If a sender sent a packet that carried a Congestion exposure signal and > realizes that this packet is lost, should this sender include the same > Congestion exposure signal in a retransmitted packet? Generally not. There is an assumption that ConEx will operate in an environment where the same packet can't be dropped twice. ;^) While it is possible that the same packet will be marked at one node and dropped at another, this is considered an outlier; and re-marking a retransmitted packet in hopes of exposing the right expected-congestion to yet a third node really doesn't make sense. (Of course, the re-transmitted lost-packet might be marked for a different reason...) > Observation 3: > Should a router/device not preferentially drop ECN congested marked > packets? Not sure I understand the question, with a double-negative... I'm guessing you mean, is there a reason to drop something else in preference to dropping a ConEx-marked packet. I'd answer that there is a reason, though I don't think we have consensus to recommend it yet: the reason being that the backoff by the sender can come sooner (just as is the case for ECN-marking instead of dropping). > Observation 4: > Should a router/device not preferentially drop Conex exposure marked > packets? I'm left guessing again: the same reason applies to any ConEx-marked packet that would otherwise be eligible for drop due to congestion -- whether it is marked ConEx-aware or Congestion-Expected. > Observation 5: > Should the Conex WG specify the operation of all Conex aware nodes? We should specify what it means to be ConEx-aware, which will constrain the operation of a "ConEx-aware" node, but not fully specify other actions it may take. -- John Leslie From john@jlc.net Wed Mar 23 12:41:42 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77BDA3A6940 for ; Wed, 23 Mar 2011 12:41:42 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4pH5chOUd20 for ; Wed, 23 Mar 2011 12:41:41 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 7906E28C0F1 for ; Wed, 23 Mar 2011 12:41:41 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id EF13133C2C; Wed, 23 Mar 2011 15:43:15 -0400 (EDT) Date: Wed, 23 Mar 2011 15:43:15 -0400 From: John Leslie To: Suresh Krishnan Message-ID: <20110323194315.GH65272@verdi> References: <20110322125817.GD65272@verdi> <4D8920D8.8030604@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D8920D8.8030604@ericsson.com> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] draft-krishnan-conex-ipv6-02 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 19:41:42 -0000 Suresh Krishnan wrote: > On 03/22/11 08:58, John Leslie wrote: >> >> That is not my interpretation of R-1. >> >> They're entirely "visible", being in a known place, easy to find, >> well delineated so we could concentrate on exactly what we're looking >> for. > > Given the current state of IPv6, an intermediate node is not allowed to > even examine destination options. Unfortunately, RFC2460 does not follow > RFC2119 language. The following text is present in Section 4. > > "With one exception, extension headers are not examined or processed > by any node along a packet's delivery path, until the packet reaches > the node (...) identified in the Destination Address field of the IPv6 > header" As you said, that doesn't include any MUSTard. IMHO, Section 4 is there stating an expectation, not a requirement. I don't recall that specific question being addressed in 6MAN, but there is a clear understanding there that there's nothing to prevent deep- packet inspection. > The exception of course is the Hop-by-hop extension header. Of course we > can code conex aware routers on-path to look into the dest opts header, > but that will rule out IPsec ESP protected packets (as Bob pointed out). > This is of course a limitation we can decide to live with, but once the > flow label bits are gone, they are gone forever :-(. It's not _quite_ that cut-and-dried. RFC2460 "recommends" an order of headers that puts Authentication and Encapsulating Security headers before Destination Options, but _requires_ IPv6 nodes to accept headers in any order. In any case, IPsec is probably not an issue for our initial Experimental spec. >> Furthermore, this seems to be where the 6MAN WG points everyone >> who suggests adding a new Extension Header. > > Correct. But extension headers and dest opts have end-to-end > significance and not hop-by-hop significance. So I think that the > recommendation is sound. Which recommendation? >> I do not interpret R-1 to mean that ConEx marking needs to be >> _observed_ by every node along the path. > > I was more thinking that the marking needs to be _observable_ by every > node along the path, and a dest option is not legally observable by an > intermediate node. I dissent on "not legally observable". I suppose we could put that question to the 6MAN WG, but I'm not sure I can guarantee an answer... -- John Leslie From john@jlc.net Wed Mar 23 12:45:41 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D145B3A6940 for ; Wed, 23 Mar 2011 12:45:41 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZkrjBqszW6n for ; Wed, 23 Mar 2011 12:45:41 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id EB7F73A67E1 for ; Wed, 23 Mar 2011 12:45:40 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 7FBD733C2E; Wed, 23 Mar 2011 15:47:15 -0400 (EDT) Date: Wed, 23 Mar 2011 15:47:15 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20110323194715.GI65272@verdi> References: <201103231851.p2NIpesF031028@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201103231851.p2NIpesF031028@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Cc: ConEx IETF list Subject: Re: [conex] Missing concept from conex-concepts-uses ? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 19:45:41 -0000 Bob Briscoe wrote: > > I just started re-reading the draft with my "Mr Skeptical" hat on. In > other words, I put myself in a devil's advocate frame of mind where I > start off hating it and have to be convinced. > > I immediately noticed it doesn't start from "What's the problem with > over-provisioning?" (It does at least mention _a_ problem with over-provisioning...) > Also, I just did a presentation to L2/L3 colleagues which started > with why congestion is not strongly related to utilisation, and they > all found it really difficult to 'get it'. This seems to be a cause > of confusion for people coming from non-transport backgrounds. I > think I've worked out how to explain it (John, I know this is one of > your bug-bears too). > > Do you agree it would be useful to have a brief discussion of these > issues near the start? Speaking for myself, yes. > I can propose some text, if you want. By all means, send text! -- John Leslie From karagian@cs.utwente.nl Thu Mar 24 07:30:05 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2B7D28C11B for ; Thu, 24 Mar 2011 07:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.077 X-Spam-Level: ** X-Spam-Status: No, score=2.077 tagged_above=-999 required=5 tests=[AWL=-2.419, BAYES_00=-2.599, GB_SUMOF=5, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGpKRgBEPeQw for ; Thu, 24 Mar 2011 07:30:03 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id F024C3A68E0 for ; Thu, 24 Mar 2011 07:30:02 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id p2OEV7ZR019200; Thu, 24 Mar 2011 15:31:12 +0100 (MET) From: "Georgios Karagiannis" To: "'John Leslie'" References: <20110323193214.GG65272@verdi> Date: Thu, 24 Mar 2011 15:31:14 +0100 Message-ID: <3FB33BF21F7C462CA7CD572EBDA980D9@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20110323193214.GG65272@verdi> Thread-Index: AcvplD22PpIOx04MTRSW4F12EbXtSwAmRhvg X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 24 Mar 2011 15:31:21 +0100 (MET) Cc: conex@ietf.org Subject: Re: [conex] Observations regarding the Conex concept X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 24 Mar 2011 14:30:05 -0000 Hi John Please see in line! > -----Original Message----- > From: John Leslie [mailto:john@jlc.net] > Sent: woensdag 23 maart 2011 20:32 > To: Georgios Karagiannis > Cc: conex@ietf.org > Subject: Re: [conex] Observations regarding the Conex concept > > Georgios Karagiannis wrote: > > > > After discussing with Mirja and based on the previous Conex email > > discussions with Bob, I have derived some observations > regarding the > > Conex concept, see below. These observations are expressed > in questions. > > Hopefully we can answer them easily. > > I'm not sure I'm the best person to answer, but here goes: > > > Observation 1: > > Must the sender (of the data path and Conex exposure > signals) be able > > to identify which packets were lost in the downstream direction, in > > addition to the calculated number of ECN marked packets in the > > downstream direction? > > No. > > Well, at least not in order to be fully ConEx-enabled... > > _If_ the sender is speaking TCP, that is required by TCP; > but for ConEx purposes, whether the lost packets are ever > re-transmitted is quite strictly out-of-scope. Georgios: But if the sender is not be able to identify which packets were lost in the downstream direction, then the calculation of the congestion rate will be inaccurate. Note that the congestion rate is the sum of the rate of packets that are lost and the packets that were ECN marked in the downsstream direction. > > > Observation 2: > > If a sender sent a packet that carried a Congestion exposure signal > > and realizes that this packet is lost, should this sender > include the > > same Congestion exposure signal in a retransmitted packet? > > Generally not. > > There is an assumption that ConEx will operate in an > environment where the same packet can't be dropped twice. ;^) > > While it is possible that the same packet will be marked > at one node and dropped at another, this is considered an > outlier; and re-marking a retransmitted packet in hopes of > exposing the right expected-congestion to yet a third node > really doesn't make sense. > > (Of course, the re-transmitted lost-packet might be marked > for a different reason...) Georgios: I think that the answer of this question is more complex than your answer! In my opinion we need to do evaluation studies to find out what is the impact of retransmitting or not retransmitting lost Congestion exposure signals. > > > Observation 3: > > Should a router/device not preferentially drop ECN congested marked > > packets? > > Not sure I understand the question, with a double-negative... > > I'm guessing you mean, is there a reason to drop something > else in preference to dropping a ConEx-marked packet. I'd > answer that there is a reason, though I don't think we have > consensus to recommend it yet: > the reason being that the backoff by the sender can come > sooner (just as is the case for ECN-marking instead of dropping). Georgios: Yes, the reason is a congestion. In a congestion situation a router might drop packets. Most routers implement the simple FIFS/FIFO Tail drop queing mechanism. This means that ECN marked packets may be dropped by congested routers. This will mean that the receiver might not receive ECN marked packets when one or more routers in the downstream path from sender to receiver are congested. This will aslo mean that the Sender will not be able to know that the lost packet was ECN marked. If the queuing mechanims in the router is such that ECN marked packets are not dropped in congestion situations then the problem that I mentioned earlier will not occur and the receiver and Sender will be notified about the ECN marked packet. > > > Observation 4: > > Should a router/device not preferentially drop Conex > exposure marked > > packets? > > I'm left guessing again: the same reason applies to any > ConEx-marked packet that would otherwise be eligible for drop > due to congestion -- whether it is marked ConEx-aware or > Congestion-Expected. Georgios: The reason is again a congestion. In a congestion situation a router might drop packets. Most routers implement the simple FIFS/FIFO Tail drop queing mechanism. This means that Conex exposure marked packets may be dropped by congested routers. This will mean that Audit devices and the receiver might not receive Conex exposure marked packets when one or more routers in the path from sender to receiver are congested. This will aslo mean that the Audit devices and the receiver will not be able to calculate in an accurate way the rate of the Conex exposure signals apassing by. If the queuing mechanims in the router is such that Conex exposure marked packets are not dropped in congestion situations then the problem that I mentioned earlier will not occur. > > > Observation 5: > > Should the Conex WG specify the operation of all Conex aware nodes? > > We should specify what it means to be ConEx-aware, which > will constrain the operation of a "ConEx-aware" node, but not > fully specify other actions it may take. Georgios: Yes that is true! What I actually mean is: Shoud the Conex WG specify how the Sender, Receiver and Audit devices should process the ECN marked packets and the Conex exposure signals? Should the Conex WG, for example, also specify that if a router processes Conex exposure signals, then in case of congestion these packets should be treated differently than other packets? Best regards, Georgios > > -- > John Leslie > From john@jlc.net Thu Mar 24 09:03:57 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9385D28C0F8 for ; Thu, 24 Mar 2011 09:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.043 X-Spam-Level: X-Spam-Status: No, score=-104.043 tagged_above=-999 required=5 tests=[AWL=-2.444, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tekn+nbRf4M for ; Thu, 24 Mar 2011 09:03:56 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 084AF28C105 for ; Thu, 24 Mar 2011 09:03:56 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id DF37033C2A; Thu, 24 Mar 2011 12:05:30 -0400 (EDT) Date: Thu, 24 Mar 2011 12:05:30 -0400 From: John Leslie To: Georgios Karagiannis Message-ID: <20110324160530.GB48769@verdi> References: <20110323193214.GG65272@verdi> <3FB33BF21F7C462CA7CD572EBDA980D9@dynamic.ewi.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FB33BF21F7C462CA7CD572EBDA980D9@dynamic.ewi.utwente.nl> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] Observations regarding the Conex concept X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 24 Mar 2011 16:03:57 -0000 Georgios Karagiannis wrote: > [John Leslie wrote:] >> Georgios Karagiannis wrote: >> >>> Must the sender (of the data path and Conex exposure signals) be able >>> to identify which packets were lost in the downstream direction, in >>> addition to the calculated number of ECN marked packets in the >>> downstream direction? >> >> No. >> >> Well, at least not in order to be fully ConEx-enabled... >> >> _If_ the sender is speaking TCP, that is required by TCP; >> but for ConEx purposes, whether the lost packets are ever >> re-transmitted is quite strictly out-of-scope. > > But if the sender is not be able to identify which packets were > lost in the downstream direction, then the calculation of the > congestion rate will be inaccurate. There is a possible minor inaccuracy if the sender guesses wrong on the _size_ of a dropped packet. We do not consider that important. > Note that the congestion rate is the sum of the rate of packets > that are lost and the packets that were ECN marked in the downsstream > direction. No. Well, not the arithmetic sum, anyway -- we could play word games and call it a "combinatorial sum". The point is, a packet can only be dropped once, and an ECN mark is equivalent to a drop. >>> If a sender sent a packet that carried a Congestion exposure signal >>> and realizes that this packet is lost, should this sender include >>> the same Congestion exposure signal in a retransmitted packet? >> >> Generally not. >> >> There is an assumption that ConEx will operate in an >> environment where the same packet can't be dropped twice. ;^) >> >> While it is possible that the same packet will be marked >> at one node and dropped at another, this is considered an >> outlier; and re-marking a retransmitted packet in hopes of >> exposing the right expected-congestion to yet a third node >> really doesn't make sense. >> >> (Of course, the re-transmitted lost-packet might be marked >> for a different reason...) > > I think that the answer of this question is more complex than your > answer! In my opinion we need to do evaluation studies to find out > what is the impact of retransmitting or not retransmitting lost > Congestion exposure signals. Feel free to do those yourself, as part of the experiment evaluation. We are designing according to an assumption that packet drops should be rare, and that exacting accuracy is less important as congestion rate grows large. >>> Should a router/device not preferentially drop ECN congested marked >>> packets? >> >> I'm guessing you mean, is there a reason to drop something >> else in preference to dropping a ConEx-marked packet. I'd >> answer that there is a reason, though I don't think we have >> consensus to recommend it yet: >> the reason being that the backoff by the sender can come >> sooner (just as is the case for ECN-marking instead of dropping). > > Yes, the reason is a congestion. In a congestion situation a router > might drop packets. Most routers implement the simple FIFS/FIFO Tail > drop queing mechanism. I'm not sure that's true any longer -- in any case, we can't assume it to be true, except for routers that essentially never drop anyway. > This means that ECN marked packets may be dropped by congested routers. That is true. Most routers (today) aren't ECN-aware. > This will mean that the receiver might not receive ECN marked packets > when one or more routers in the downstream path from sender to receiver > are congested. But the packets, being dropped, count towards congestion anyway. > This will aslo mean that the Sender will not be able to know that the > lost packet was ECN marked. That does not follow -- though it's unlikely the Sender would care... > If the queuing mechanims in the router is such that ECN marked packets > are not dropped in congestion situations then the problem that I > mentioned earlier will not occur and the receiver and Sender will be > notified about the ECN marked packet. Which is a happy thing... But not particularly critical to ConEx operation -- it only helps to react more quickly to congestion. >>> Should a router/device not preferentially drop Conex exposure marked >>> packets? >> >> I'm left guessing again: the same reason applies to any >> ConEx-marked packet that would otherwise be eligible for drop >> due to congestion -- whether it is marked ConEx-aware or >> Congestion-Expected. > > The reason is again a congestion. In a congestion situation a router > might drop packets. Most routers implement the simple FIFS/FIFO Tail > drop queing mechanism. Again, a poor assumption. > This means that Conex exposure marked packets may be dropped by > congested routers. Again, true. > This will mean that Audit devices and the receiver might not receive > Conex exposure marked packets when one or more routers in the path > from sender to receiver are congested. That is certainly possible. (It might help if you specified what particular ConEx marking you're worried about.) > This will also mean that the Audit devices and the receiver will not > be able to calculate in an accurate way the rate of the Conex exposure > signals apassing by. IMHO you're worried about an unimportant corner case. Any ConEx or ECN marking may get dropped anywhere along the remaining path. I expect we will specify something like ECN marking for congestion experienced and a ConEx congestion-expected marking for "building credit" They will be orthogonal bits but in the same packet. If that packet is dropped the effects will cancel each other. Only if these two marks are in different packets and the two marks have a different probability of being dropped would we have a significant imbalance. > If the queuing mechanims in the router is such that Conex exposure > marked packets are not dropped in congestion situations then the > problem that I mentioned earlier will not occur. You seem to be assuming a rather full deployment where all routers that might drop packets are ConEx enabled. That is actually out-of-scope per our charter. >>> Observation 5: >>> Should the Conex WG specify the operation of all Conex aware nodes? >> >> We should specify what it means to be ConEx-aware, which >> will constrain the operation of a "ConEx-aware" node, but not >> fully specify other actions it may take. > > Georgios: Yes that is true! What I actually mean is: Shoud the Conex > WG specify how the Sender, Receiver and Audit devices should process > the ECN marked packets and the Conex exposure signals? I would much prefer not to. A number of WGs make the mistake (IMHO) of specifying algorithms rather than meanings. Inevitably the actual implementations of these algorithms diverge, and the divergence can't be fully tested by interoperability testing. Sooner or later, a mess appears, and there's no good way to clean it up. > Should the Conex WG, for example, also specify that if a router > processes Conex exposure signals, then in case of congestion these > packets should be treated differently than other packets? We might want to specify a lower drop probability, but only to encourage faster reaction to congestion. I'd be happy without any such MUST in the spec. -- John Leslie From karagian@cs.utwente.nl Thu Mar 24 09:50:26 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E745B28C139 for ; Thu, 24 Mar 2011 09:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.22 X-Spam-Level: ** X-Spam-Status: No, score=2.22 tagged_above=-999 required=5 tests=[AWL=-2.276, BAYES_00=-2.599, GB_SUMOF=5, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiKVC2qep4Ui for ; Thu, 24 Mar 2011 09:50:23 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id 1F52428C0E1 for ; Thu, 24 Mar 2011 09:50:22 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id p2OGpUpR012669; Thu, 24 Mar 2011 17:51:33 +0100 (MET) From: "Georgios Karagiannis" To: "'John Leslie'" References: <20110323193214.GG65272@verdi> <3FB33BF21F7C462CA7CD572EBDA980D9@dynamic.ewi.utwente.nl> <20110324160530.GB48769@verdi> Date: Thu, 24 Mar 2011 17:51:37 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20110324160530.GB48769@verdi> Thread-Index: AcvqPVPMoanR2qrlSYKdQgRFAaVAVQABiqcw X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 24 Mar 2011 17:51:44 +0100 (MET) Cc: conex@ietf.org Subject: Re: [conex] Observations regarding the Conex concept X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 24 Mar 2011 16:50:26 -0000 Hi John Thanks for the answers. However, I think that we will need to discuss these issues in more detail during the Conex WG meeting in Prague! Best regards, Georgios > -----Original Message----- > From: John Leslie [mailto:john@jlc.net] > Sent: donderdag 24 maart 2011 17:06 > To: Georgios Karagiannis > Cc: conex@ietf.org > Subject: Re: [conex] Observations regarding the Conex concept > > Georgios Karagiannis wrote: > > [John Leslie wrote:] > >> Georgios Karagiannis wrote: > >> > >>> Must the sender (of the data path and Conex exposure signals) be > >>> able to identify which packets were lost in the downstream > >>> direction, in addition to the calculated number of ECN marked > >>> packets in the downstream direction? > >> > >> No. > >> > >> Well, at least not in order to be fully ConEx-enabled... > >> > >> _If_ the sender is speaking TCP, that is required by TCP; but for > >> ConEx purposes, whether the lost packets are ever > re-transmitted is > >> quite strictly out-of-scope. > > > > But if the sender is not be able to identify which packets > were lost > > in the downstream direction, then the calculation of the congestion > > rate will be inaccurate. > > There is a possible minor inaccuracy if the sender guesses > wrong on the _size_ of a dropped packet. We do not consider > that important. > > > Note that the congestion rate is the sum of the rate of > packets that > > are lost and the packets that were ECN marked in the downsstream > > direction. > > No. > > Well, not the arithmetic sum, anyway -- we could play word > games and call it a "combinatorial sum". The point is, a > packet can only be dropped once, and an ECN mark is > equivalent to a drop. > > >>> If a sender sent a packet that carried a Congestion > exposure signal > >>> and realizes that this packet is lost, should this sender include > >>> the same Congestion exposure signal in a retransmitted packet? > >> > >> Generally not. > >> > >> There is an assumption that ConEx will operate in an environment > >> where the same packet can't be dropped twice. ;^) > >> > >> While it is possible that the same packet will be marked > at one node > >> and dropped at another, this is considered an outlier; and > re-marking > >> a retransmitted packet in hopes of exposing the right > >> expected-congestion to yet a third node really doesn't make sense. > >> > >> (Of course, the re-transmitted lost-packet might be marked for a > >> different reason...) > > > > I think that the answer of this question is more complex than your > > answer! In my opinion we need to do evaluation studies to find out > > what is the impact of retransmitting or not retransmitting lost > > Congestion exposure signals. > > Feel free to do those yourself, as part of the experiment > evaluation. > We are designing according to an assumption that packet drops > should be rare, and that exacting accuracy is less important > as congestion rate grows large. > > >>> Should a router/device not preferentially drop ECN > congested marked > >>> packets? > >> > >> I'm guessing you mean, is there a reason to drop something else in > >> preference to dropping a ConEx-marked packet. I'd answer > that there > >> is a reason, though I don't think we have consensus to > recommend it > >> yet: > >> the reason being that the backoff by the sender can come > sooner (just > >> as is the case for ECN-marking instead of dropping). > > > > Yes, the reason is a congestion. In a congestion situation a router > > might drop packets. Most routers implement the simple > FIFS/FIFO Tail > > drop queing mechanism. > > I'm not sure that's true any longer -- in any case, we > can't assume it to be true, except for routers that > essentially never drop anyway. > > > This means that ECN marked packets may be dropped by > congested routers. > > That is true. Most routers (today) aren't ECN-aware. > > > This will mean that the receiver might not receive ECN > marked packets > > when one or more routers in the downstream path from sender to > > receiver are congested. > > But the packets, being dropped, count towards congestion anyway. > > > This will aslo mean that the Sender will not be able to > know that the > > lost packet was ECN marked. > > That does not follow -- though it's unlikely the Sender > would care... > > > If the queuing mechanims in the router is such that ECN > marked packets > > are not dropped in congestion situations then the problem that I > > mentioned earlier will not occur and the receiver and > Sender will be > > notified about the ECN marked packet. > > Which is a happy thing... > > But not particularly critical to ConEx operation -- it > only helps to react more quickly to congestion. > > >>> Should a router/device not preferentially drop Conex > exposure marked > >>> packets? > >> > >> I'm left guessing again: the same reason applies to any > ConEx-marked > >> packet that would otherwise be eligible for drop due to > congestion -- > >> whether it is marked ConEx-aware or Congestion-Expected. > > > > The reason is again a congestion. In a congestion situation > a router > > might drop packets. Most routers implement the simple > FIFS/FIFO Tail > > drop queing mechanism. > > Again, a poor assumption. > > > This means that Conex exposure marked packets may be dropped by > > congested routers. > > Again, true. > > > This will mean that Audit devices and the receiver might > not receive > > Conex exposure marked packets when one or more routers in the path > > from sender to receiver are congested. > > That is certainly possible. (It might help if you > specified what particular ConEx marking you're worried about.) > > > This will also mean that the Audit devices and the receiver > will not > > be able to calculate in an accurate way the rate of the > Conex exposure > > signals apassing by. > > IMHO you're worried about an unimportant corner case. Any > ConEx or ECN marking may get dropped anywhere along the > remaining path. I expect we will specify something like ECN > marking for congestion experienced and a ConEx > congestion-expected marking for "building credit" They will > be orthogonal bits but in the same packet. If that packet is > dropped the effects will cancel each other. > > Only if these two marks are in different packets and the > two marks have a different probability of being dropped would > we have a significant imbalance. > > > If the queuing mechanims in the router is such that Conex exposure > > marked packets are not dropped in congestion situations then the > > problem that I mentioned earlier will not occur. > > You seem to be assuming a rather full deployment where all > routers that might drop packets are ConEx enabled. That is > actually out-of-scope per our charter. > > >>> Observation 5: > >>> Should the Conex WG specify the operation of all Conex > aware nodes? > >> > >> We should specify what it means to be ConEx-aware, which will > >> constrain the operation of a "ConEx-aware" node, but not fully > >> specify other actions it may take. > > > > Georgios: Yes that is true! What I actually mean is: Shoud > the Conex > > WG specify how the Sender, Receiver and Audit devices > should process > > the ECN marked packets and the Conex exposure signals? > > I would much prefer not to. > > A number of WGs make the mistake (IMHO) of specifying > algorithms rather than meanings. Inevitably the actual > implementations of these algorithms diverge, and the > divergence can't be fully tested by interoperability testing. > Sooner or later, a mess appears, and there's no good way to > clean it up. > > > Should the Conex WG, for example, also specify that if a router > > processes Conex exposure signals, then in case of congestion these > > packets should be treated differently than other packets? > > We might want to specify a lower drop probability, but > only to encourage faster reaction to congestion. I'd be happy > without any such MUST in the spec. > > -- > John Leslie > From acooper@cdt.org Fri Mar 25 01:35:51 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EB8B3A6981 for ; Fri, 25 Mar 2011 01:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWP5xLksfvSf for ; Fri, 25 Mar 2011 01:35:50 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id 0D11F3A6980 for ; Fri, 25 Mar 2011 01:35:49 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Fri, 25 Mar 2011 04:37:06 -0400 Message-Id: <10CDB575-B519-4421-819E-3E911BF53D26@cdt.org> From: Alissa Cooper To: "Mcdysan, David E" In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 25 Mar 2011 09:37:04 +0100 References: X-Mailer: Apple Mail (2.936) Cc: "conex@ietf.org" , "Woundy, Richard" Subject: Re: [conex] comments/suggestions on draft-ietf-conex-concepts-uses-01 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 08:35:51 -0000 In my reading of section 6, it presents 2 distinct issues: 1) Long time scales: A use case (or perhaps a few variations on the =20 same use case) for the conex signal as currently described in abstract-=20= mech, wherein conex helps network operators to manage congestion, =20 conduct traffic shaping, and capacity-plan over periods much longer =20 than network speeds (e.g., minutes/hours/days/months) 2) Shaper presence: A suggestion that conex could signal the presence =20= of a traffic shaper (in addition to or instead of how the conex signal =20= is currently described in abstract-mech) and a use case for such a =20 signal wherein recipients of the signal can use it to request that =20 sender's traffic shaper parameters be altered I think the issue of long time scales, which is described in the =20 introductory text to section 6 and briefly in 6.1 and 6.2, could =20 instead be succinctly addressed by adding a couple of sentences to 5.1 =20= to explain that the use of conex for managing "heavy" users could =20 occur over shorter or longer time scales and could have the added =20 affect of helping operators to do longer-term capacity planning. Signaling the presence of a shaper seems to me to be a separate animal =20= altogether, and one over which there is some obvious disagreement. But =20= at least half of section 6 seems to be devoted to the idea that =20 operators would have uses for aggregating conex information over long =20= time frames, and I think those uses could be incorporated with a brief =20= addition to section 5.1. Alissa On Mar 17, 2011, at 12:25 PM, Mcdysan, David E wrote: > Hi Nandita, > > A few responses to your questions on the new section in line below =20 > prefixed by DM which were previously posted to the list that I =20 > believe (at least partially) address your comments. > > I propose that the working group work toward how to organize/merge/=20 > move the new text better into the existing outline. > > Thanks, > > Dave > > From: Nandita Dukkipati > Date: Thu, 17 Mar 2011 03:28:25 -0400 > To: Toby Moncaster , John Leslie , =20= > Bob Briscoe , "Woundy, Richard" = >, David McDysan > Cc: "conex@ietf.org" > Subject: comments/suggestions on draft-ietf-conex-concepts-uses-01 > > On reading the latest draft, I have three high level comments =20 > roughly in the following order of importance- > > *** > Statistical Multiplexing over different timescales. > This reads like a rambling story. I have read and re-read it, and I =20= > am still left wondering - > * What is _the_ main point? How about starting the section by =20 > stating your main point upfront as opposed leaving it to the reader =20= > to figure it out. > > DM - =46rom my 3/10/11 on the list > > 1) A few "heavy" users generate most of the traffic and service =20 > providers > want to better assign the cost (of provisioning an upgrade) for the =20= > time > when congestion is anticipated to occur. Existing mechanisms, flat =20 > rate, > bandwidth tier shapers, and usage tiers do not completely address the > service provider objective and/or are not popular with users. > > 2) In some service provider networks shapers are implemented to =20 > limit the > maximum bandwidth per user. Although overflow or marking in the shaper > queue appears as congestion to the receiver, this "self-congestion" > differs from congestion of a shared resource since a remedy could be =20= > to > indicate to the user that changing the shaper rate (i.e., "go faster") > would alleviate "self-congestion." > > * Why and how is this use case distinct from that of traffic =20 > management which already seems to have a broad scope? Is it really =20 > distinct? > > DM - =46rom my 3/11/11 post to the list > > Editorially, this (section 5.1) could be a place to state the =20 > problem with an additional > reference to [Varian]. > > Editorially, bandwidth tier pricing could be added to section 3.1, > Existing approaches. > > I am now thinking that editorially a separate section is not a good =20= > idea, > since the points can be merged into the existing outline, in at =20 > least the > places mentioned above. > > I think adding that the use case needs to meet service provider =20 > economic > congestion needs as well as be acceptable to users is an important =20 > point > not in the current text. Traffic management (aka policing) may have =20= > the > problem that it may not be popular with user. There has already been > negative feedback on the list regarding policing (IMO, Traffic =20 > management > is a better term). > > > * [minor] Why not make this use case a part of Sec. 5? > > DM =96 the minutes recorded adding the agreement to add this as a new =20= > section. (A new subsection, and or merging thoughts with other use =20 > cases (e.g., as suggested above) is what I believe the wg needs to =20 > discuss. > > *** > Partial versus full deployment. > Clearly, it belongs to this draft. But why is it a part of use =20 > cases? Looks out of place to me. > > *** > Sec 4. Exposing congestion. > =93We argue that congestion needs.... More specifically, a network =20 > needs to be able to measure how much congestion any particular =20 > traffic expects to cause between the monitoring point in the network =20= > and the destination ("rest-of-path congestion"). This would be a new =20= > capability.=94 > > Could you add more clarity and explanation on why local congestion =20 > information at any given node is not sufficient. Why does a node =20 > require congestion information from a monitoring point to the =20 > destination to be able to manage its own congestion? A succinct =20 > explanation and/or an example will go a long way. > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From dave.mcdysan@verizon.com Fri Mar 25 06:02:42 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62C923A69B2 for ; Fri, 25 Mar 2011 06:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.505 X-Spam-Level: X-Spam-Status: No, score=-3.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyrhPFmWZcnT for ; Fri, 25 Mar 2011 06:02:41 -0700 (PDT) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id 4F8043A69B0 for ; Fri, 25 Mar 2011 06:02:41 -0700 (PDT) Received: from fldsmtpi01.verizon.com (fldsmtpi01.verizon.com [166.68.71.143]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p2PD41MU001436 for ; Fri, 25 Mar 2011 09:04:16 -0400 (EDT) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.63,242,1299456000"; d="scan'208";a="18433696" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi01.verizon.com with ESMTP; 25 Mar 2011 13:04:01 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.32]) by FHDP1LUMXC7HB02.us.one.verizon.com ([2002:a644:3bbd::a644:3bbd]) with mapi; Fri, 25 Mar 2011 09:04:01 -0400 To: John Leslie , Bob Briscoe Date: Fri, 25 Mar 2011 09:03:59 -0400 Thread-Topic: [conex] Missing concept from conex-concepts-uses ? Thread-Index: Acvq7RwBLUrjmhnCQZCEy24kyPMbNA== Message-ID: In-Reply-To: <20110323194715.GI65272@verdi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ConEx IETF list Subject: Re: [conex] Missing concept from conex-concepts-uses ? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 13:02:42 -0000 Hi, I also read over the use case and abstract mechanism drafts yesterday and agree with Bob and John that the motivation could be better stated. The description of the congestion problem(s) to be solved and some definitions of various views of congestion from the reference [Bauer09] may help provide the motivation which could be better stated in the wg draft. The following three quotes from sections 3.3 and 3.4 of [Bauer09] capture the essence of what I believe is a significant motivational factor for (at least some) service providers: "Network operators tend to adopt another definition of congestion. They define "congestion" in terms of the load on a network over a particular period of time. (See Figure 4.) Ask a network operator how "congested" part of their network is, and they will respond with the average utilization of a link over some period of time. This period of time is typically on the order of minutes or longer." Snipped "From the MIT Dictionary of Modern Economics23: "When an increase in the use of a facility or service which is used by a number of people would impose a cost (not necessarily a monetary cost) on the existing users, that facility is said to be =8Ccongested'." Snipped "Is this economic definition of congestion close to the network operators' definition based upon usage levels? The answer to this depends upon how one interprets the size of the increase in load needed to cause the delays or drops and the time period in which this increase has to occur. If one believes that traffic might increase by 25% in the next six months and the network is currently at 80% utilization then a network might be deemed congested now since the projected increase will assuredly cause delays or drops over that longer duration time period.25 25 There might also be an opportunity cost born by a network operator if the network is loaded to a level that precludes them from accepting or attracting new subscribers. Thus, a network might be perceived to be "congested" if it is near the point where additional traffic would trigger a business decision to deploy additional capacity. Historically, some network operators adopted a rule-of-thumb that additional capacity would be deployed if the average link utilization during the busy period of the day exceeded 50% of the link capacity." Editorially, the essence of these quotes could be paraphrased more succinctly, attribution given to [Bauer09] and merged with the text at the bottom of page 3 in the Introduction of the use case wg draft. (I also propose aligning the time frame in the second sentence of the paragraph at the bottom of page 3 to be "months to years" as stated in [Bauer09, p.6] instead of a "few months" as stated in the current text. Also, the reference to Moore's law in that paragraph seems unnecessary.) Editorially, I suggest including the URL to this paper in the References section of the wg draft: http://mitas.csail.mit.edu/papers/Bauer_Clark_Lehr_2009.pdf Thanks, Dave On 3/23/11 3:47 PM, "John Leslie" wrote: Bob Briscoe wrote: >=20 > I just started re-reading the draft with my "Mr Skeptical" hat on. In > other words, I put myself in a devil's advocate frame of mind where I > start off hating it and have to be convinced. >=20 > I immediately noticed it doesn't start from "What's the problem with > over-provisioning?" (It does at least mention _a_ problem with over-provisioning...) > Also, I just did a presentation to L2/L3 colleagues which started > with why congestion is not strongly related to utilisation, and they > all found it really difficult to 'get it'. This seems to be a cause > of confusion for people coming from non-transport backgrounds. I > think I've worked out how to explain it (John, I know this is one of > your bug-bears too). >=20 > Do you agree it would be useful to have a brief discussion of these > issues near the start? Speaking for myself, yes. > I can propose some text, if you want. By all means, send text! -- John Leslie _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex From john@jlc.net Fri Mar 25 09:01:20 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 704083A67A2 for ; Fri, 25 Mar 2011 09:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.484 X-Spam-Level: X-Spam-Status: No, score=-106.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3b-8lLMwiiU for ; Fri, 25 Mar 2011 09:01:19 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 880943A67A6 for ; Fri, 25 Mar 2011 09:01:19 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 20D7A33C2E; Fri, 25 Mar 2011 12:02:55 -0400 (EDT) Date: Fri, 25 Mar 2011 12:02:55 -0400 From: John Leslie To: "Mcdysan, David E" Message-ID: <20110325160255.GE48769@verdi> References: <20110323194715.GI65272@verdi> 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] Missing concept from conex-concepts-uses ? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 16:01:20 -0000 Mcdysan, David E wrote: > > The following three quotes from sections 3.3 and 3.4 of [Bauer09] capture > the essence of what I believe is a significant motivational factor for (at > least some) service providers: Actually Bauer_Clark-Lehr_2009 gives four definitions of interest: Queueing theory definition: " In queuing theory, traffic congestion is said to occur if the arrival " rate into a system exceeds the service rate of the system at a point " in time. Textbook definition: " Congestion of a network router is said to occur if packets are dropped, " The buildup of packets in a queue is instead described as contention. Network Operator's definiton: " Ask a network operator how congested part of their network is and they " will respond with the average utilization of a link over some period of " time. Economic definition: " When an increase in the use of a facility or service which is used by " a number of people would impose a cost (not necessarily a monetary " cost) on the existing users, that facility is said to be congested. IMHO, it might be good to include all four before we try to state our own definition, simply because congestion _does_ mean so many different things to different observers, and the casual reader is likely to assume our definition is "vague" due to carelessness. ;^) > Editorially, the essence of these quotes could be paraphrased more > succinctly, I think they're succinct enough (as I quoted them above). > attribution given to [Bauer09] and merged with the text at the > bottom of page 3 in the Introduction of the use case wg draft. Toby has the pen... > (I also propose aligning the time frame in the second sentence of the > paragraph at the bottom of page 3 to be "months to years" as stated in > [Bauer09, p.6] instead of a "few months" as stated in the current text. Again, Toby has the pen; but I would dissent: "years" is simply too long of a time period in the world of Internet (even if some operators _do_ maintain multi-year upgrade plans). > Also, the reference to Moore's law in that paragraph seems unnecessary.) Toby has the pen... (but I consider the sentence following that one to be important.) > Editorially, I suggest including the URL to this paper in the References > section of the wg draft: > > http://mitas.csail.mit.edu/papers/Bauer_Clark_Lehr_2009.pdf Toby has the pen... -- John Leslie From bob.briscoe@bt.com Fri Mar 25 09:18:12 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAA983A67B2 for ; Fri, 25 Mar 2011 09:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMnSxX4SOex2 for ; Fri, 25 Mar 2011 09:18:12 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id DD7493A67B0 for ; Fri, 25 Mar 2011 09:18:11 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Mar 2011 16:19:46 +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); Fri, 25 Mar 2011 16:19:46 +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 1301069984795; Fri, 25 Mar 2011 16:19:44 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.131.97]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p2PGJhXJ007656; Fri, 25 Mar 2011 16:19:43 GMT Message-Id: <201103251619.p2PGJhXJ007656@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 25 Mar 2011 16:19:42 +0000 To: John Leslie From: Bob Briscoe In-Reply-To: <20110325160255.GE48769@verdi> References: <20110323194715.GI65272@verdi> <20110325160255.GE48769@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: 25 Mar 2011 16:19:46.0049 (UTC) FILETIME=[74B53710:01CBEB08] Cc: ConEx IETF list Subject: Re: [conex] Missing concept from conex-concepts-uses ? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 16:18:12 -0000 John, The important point to make is not just that we have chosen a definition, but the reason we have chosen it: We combine the economic definition with the definition at queuing timescales because incentives at these timescales can be extremely effective in altering the behaviour of computers that can respond that quickly (as TCP does). Bob At 16:02 25/03/2011, John Leslie wrote: > Actually Bauer_Clark-Lehr_2009 gives four definitions of interest: > >Queueing theory definition: >" In queuing theory, traffic congestion is said to occur if the arrival >" rate into a system exceeds the service rate of the system at a point >" in time. > >Textbook definition: >" Congestion of a network router is said to occur if packets are dropped, >" The buildup of packets in a queue is instead described as contention. > >Network Operator's definiton: >" Ask a network operator how congested part of their network is and they >" will respond with the average utilization of a link over some period of >" time. > >Economic definition: >" When an increase in the use of a facility or service which is used by >" a number of people would impose a cost (not necessarily a monetary >" cost) on the existing users, that facility is said to be congested. > > IMHO, it might be good to include all four before we try to state our >own definition, simply because congestion _does_ mean so many different >things to different observers, and the casual reader is likely to assume >our definition is "vague" due to carelessness. ;^) ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Fri Mar 25 09:56:06 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CC973A67D4 for ; Fri, 25 Mar 2011 09:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.425 X-Spam-Level: X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLER4S4IDDE4 for ; Fri, 25 Mar 2011 09:56:05 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 7BDC53A67B7 for ; Fri, 25 Mar 2011 09:56:04 -0700 (PDT) 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 Mar 2011 16:57:39 +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 Mar 2011 16:57:39 +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 1301072258313; Fri, 25 Mar 2011 16:57:38 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.131.97]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p2PGvbIn007792; Fri, 25 Mar 2011 16:57:37 GMT Message-Id: <201103251657.p2PGvbIn007792@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 25 Mar 2011 16:56:39 +0000 To: John Leslie From: Bob Briscoe In-Reply-To: <20110323194715.GI65272@verdi> References: <201103231851.p2NIpesF031028@bagheera.jungle.bt.co.uk> <20110323194715.GI65272@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: 25 Mar 2011 16:57:39.0086 (UTC) FILETIME=[BF8B22E0:01CBEB0D] Cc: ConEx IETF list Subject: Re: [conex] Missing concept from conex-concepts-uses ? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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 Mar 2011 16:56:06 -0000 John, At 19:47 23/03/2011, John Leslie wrote: > > I immediately noticed it doesn't start from "What's the problem with > > over-provisioning?" > > (It does at least mention _a_ problem with over-provisioning...) We need to more than mention it. We need to be clear what we want to say about it... Over-provisioning is a fantastic illustration that the problem ConEx solves is not only a problem of excess congestion. For instance, a major motivation of ConEx is to solve the problem where an operator over-provisions as the only way to offer decent quality. This is an excessive cost problem, not an excessive congestion problem. So, as I keep saying, ConEx is solving an information problem, not a congestion problem. It's about revealing whether packets contribute or *not* to congestion. 0.00000000000% congestion is a signal, not a problem. Then other systems can focus on congestion-causing packets *and* ignore non-congestion-causing packets. So users don't have to always be limited unnecessarily, just because the operator can't be sure what to limit. The problem starts when we set the tone of the introduction by saying the problem is excessive congestion, which implies ConEx will (only) solve excessive congestion (as in para 1). Then in order to justify having started like this, we have to focus on all the negative aspects, rather than being able to balance positive and negative and shout about the positive. Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From suresh.krishnan@ericsson.com Sat Mar 26 03:04:10 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFEDB3A6863 for ; Sat, 26 Mar 2011 03:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.647 X-Spam-Level: X-Spam-Status: No, score=-104.647 tagged_above=-999 required=5 tests=[AWL=1.952, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GI7OeMVcQ7xx for ; Sat, 26 Mar 2011 03:04:09 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 877AC3A684F for ; Sat, 26 Mar 2011 03:04:09 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p2QA5h7D008788; Sat, 26 Mar 2011 05:05:44 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.203]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Sat, 26 Mar 2011 06:05:37 -0400 From: Suresh Krishnan To: John Leslie Date: Sat, 26 Mar 2011 06:05:37 -0400 Thread-Topic: [conex] draft-krishnan-conex-ipv6-02 Thread-Index: AcvpkpatWgD/b9JcSQ2cSrcU0xuA/ACAwImA Message-ID: <4FD1E7CD248BF84F86BD4814EDDDBCC150F15462F7@EUSAACMS0703.eamcs.ericsson.se> References: <20110322125817.GD65272@verdi> <4D8920D8.8030604@ericsson.com> <20110323194315.GH65272@verdi> In-Reply-To: <20110323194315.GH65272@verdi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] draft-krishnan-conex-ipv6-02 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 10:04:10 -0000 Hi John, > -----Original Message----- > From: John Leslie [mailto:john@jlc.net]=20 > Sent: Wednesday, March 23, 2011 8:43 PM > To: Suresh Krishnan > Cc: conex@ietf.org > Subject: Re: [conex] draft-krishnan-conex-ipv6-02 >=20 > Suresh Krishnan wrote: > > On 03/22/11 08:58, John Leslie wrote: > >> > >> That is not my interpretation of R-1. > >> > >> They're entirely "visible", being in a known place, easy to find,=20 > >> well delineated so we could concentrate on exactly what=20 > we're looking=20 > >> for. > >=20 > > Given the current state of IPv6, an intermediate node is=20 > not allowed=20 > > to even examine destination options. Unfortunately, RFC2460=20 > does not=20 > > follow > > RFC2119 language. The following text is present in Section 4. > >=20 > > "With one exception, extension headers are not examined or=20 > processed =20 > > by any node along a packet's delivery path, until the=20 > packet reaches =20 > > the node (...) identified in the Destination Address field=20 > of the IPv6 =20 > > header" >=20 > As you said, that doesn't include any MUSTard. Correct. This is true for all of RFC2460. >=20 > IMHO, Section 4 is there stating an expectation, not a requirement. > I don't recall that specific question being addressed in=20 > 6MAN, but there is a clear understanding there that there's=20 > nothing to prevent deep- packet inspection. >=20 > > The exception of course is the Hop-by-hop extension header.=20 > Of course=20 > > we can code conex aware routers on-path to look into the dest opts=20 > > header, but that will rule out IPsec ESP protected packets=20 > (as Bob pointed out). > > This is of course a limitation we can decide to live with, but once=20 > > the flow label bits are gone, they are gone forever :-(. >=20 > It's not _quite_ that cut-and-dried. >=20 > RFC2460 "recommends" an order of headers that puts=20 > Authentication and Encapsulating Security headers before=20 > Destination Options, but _requires_ > IPv6 nodes to accept headers in any order. The order of the headers is not the issue. The issue is that ESP would encr= ypt the dest opts header so that it would not be visible. >=20 > In any case, IPsec is probably not an issue for our=20 > initial Experimental spec. >=20 > >> Furthermore, this seems to be where the 6MAN WG points=20 > everyone who=20 > >> suggests adding a new Extension Header. > >=20 > > Correct. But extension headers and dest opts have end-to-end=20 > > significance and not hop-by-hop significance. So I think that the=20 > > recommendation is sound. >=20 > Which recommendation? That destination options should be used instead of extension hedaers for ca= rrying optional data with end-to-end significance. >=20 > >> I do not interpret R-1 to mean that ConEx marking needs to be=20 > >> _observed_ by every node along the path. > >=20 > > I was more thinking that the marking needs to be=20 > _observable_ by every=20 > > node along the path, and a dest option is not legally=20 > observable by an=20 > > intermediate node. >=20 > I dissent on "not legally observable". I suppose we could=20 > put that question to the 6MAN WG, but I'm not sure I can=20 > guarantee an answer... I guess a lot of intermediate nodes do a lot more than look at the IP heade= r, and this is common practice. But that does not make it legal :-). In eit= her case, I contend that a destination option cannot be observed by conex-a= ware nodes at wire speed, and will hit the same issues as the hop-by-hop op= tions. The only saving grace is that the non-conex aware intermediate nodes= will not get tripped up over dest opts. Thanks Suresh From menth@informatik.uni-tuebingen.de Sat Mar 26 14:35:15 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E2BE3A6974 for ; Sat, 26 Mar 2011 14:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxqrKF-FAYDC for ; Sat, 26 Mar 2011 14:35:12 -0700 (PDT) Received: from mx3.informatik.uni-tuebingen.de (mx3.Informatik.Uni-Tuebingen.De [134.2.12.26]) by core3.amsl.com (Postfix) with SMTP id 2AFAA3A684B for ; Sat, 26 Mar 2011 14:35:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 2A1CA52CC; Sat, 26 Mar 2011 22:36:45 +0100 (MET) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx3.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx3.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xbr01An3TGn0; Sat, 26 Mar 2011 22:36:39 +0100 (MET) Received: from zcs-bs.informatik.uni-tuebingen.de (zcs-bs.Informatik.Uni-Tuebingen.De [134.2.12.62]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 7DED2529F; Sat, 26 Mar 2011 22:36:39 +0100 (MET) Received: from [192.168.1.100] (HSI-KBW-095-208-114-108.hsi5.kabel-badenwuerttemberg.de [95.208.114.108]) by zcs-bs.informatik.uni-tuebingen.de (Postfix) with ESMTP id 3DC431795214; Sat, 26 Mar 2011 22:36:39 +0100 (CET) Message-ID: <4D8E5C6A.3070607@informatik.uni-tuebingen.de> Date: Sat, 26 Mar 2011 22:36:42 +0100 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: conex@ietf.org, Bob Briscoe , mattmathis@google.com References: <20110314230002.28547.97880.idtracker@localhost> In-Reply-To: <20110314230002.28547.97880.idtracker@localhost> Content-Type: multipart/alternative; boundary="------------070509000108060606000705" Subject: Re: [conex] I-D ACTION:draft-ietf-conex-abstract-mech-01.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 21:35:15 -0000 This is a multi-part message in MIME format. --------------070509000108060606000705 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi Bob, hi Matt, I read the conex concepts draft. The section on audits needs rework. An explantation of audits must go first, then the two different approaches may come. Why do you differentiate between re-echo-ECN, re-echo-loss, and credits? The conex policer treats them all just as conex-marked, right? But the auditing device respects only re-echo-ECN and credits. Why? Is that because it cannot see losses in the data path? Best wishes, Michael Am 15.03.2011 00:00, schrieb Internet-Drafts@ietf.org: > A new Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Congestion Exposure Working Group of the IETF. > > Title : Congestion Exposure (ConEx) Concepts and Abstract Mechanism > > Author(s) : M. Mathis, et al > Filename : draft-ietf-conex-abstract-mech-01.txt > Pages : 18 > Date : 2011-03-14 > > This document describes an abstract mechanism by which senders inform > the network about the congestion encountered by packets earlier in > the same flow. Today, the network may signal congestion to the > receiver by ECN markings or by dropping packets, and the receiver > passes this information back to the sender in transport-layer > feedback. The mechanism to be developed by the ConEx WG will enable > the sender to also relay this congestion information back into the > network in-band at the IP layer, such that the total level of > congestion is visible to all IP devices along the path, from where it > could, for example, provide input to traffic management. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-conex-abstract-mech-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de --------------070509000108060606000705 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Bob, hi Matt,

I read the conex concepts draft.

The section on audits needs rework. An explantation of audits must go first, then the two different approaches may come.

Why do you differentiate between re-echo-ECN, re-echo-loss, and credits?
The conex policer treats them all just as conex-marked, right?
But the auditing device respects only re-echo-ECN and credits. Why? Is that because it cannot see losses in the data path?

Best wishes,

=A0=A0=A0 Michael


Am 15.03.2011 00:00, schrieb Internet-Drafts@ietf.org: 
A new Internet-Draft is available from the on-line I=
nternet-Drafts directories.
This draft is a work item of the Congestion Exposure Working Group of the=
 IETF.

    Title         : Congestion Exposure (ConEx) Concepts and Abstract Mec=
hanism

    Author(s)     : M. Mathis, et al
    Filename      : draft-ietf-conex-abstract-mech-01.txt
    Pages         : 18
    Date          : 2011-03-14
   =20
This document describes an abstract mechanism by which senders inform
   the network about the congestion encountered by packets earlier in
   the same flow.  Today, the network may signal congestion to the
   receiver by ECN markings or by dropping packets, and the receiver
   passes this information back to the sender in transport-layer
   feedback.  The mechanism to be developed by the ConEx WG will enable
   the sender to also relay this congestion information back into the
   network in-band at the IP layer, such that the total level of
   congestion is visible to all IP devices along the path, from where it
   could, for example, provide input to traffic management.



A URL for this Internet-Draft is:
http://www.ietf.org/internet=
-drafts/draft-ietf-conex-abstract-mech-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


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


--=20
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:menth@uni-tuebingen.de
http://www-kn.informatik.uni-tuebingen.de
--------------070509000108060606000705-- From bob.briscoe@bt.com Mon Mar 28 01:55:17 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 751F13A6962 for ; Mon, 28 Mar 2011 01:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.44 X-Spam-Level: X-Spam-Status: No, score=-3.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKGh87Ihw7hY for ; Mon, 28 Mar 2011 01:55:14 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 59BF83A68B1 for ; Mon, 28 Mar 2011 01:55:14 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Mar 2011 09:56:50 +0100 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, 28 Mar 2011 09:56:50 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1301302609643; Mon, 28 Mar 2011 09:56:49 +0100 Received: from MUT.jungle.bt.co.uk ([10.142.66.49]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p2S8uifq028758 for ; Mon, 28 Mar 2011 09:56:48 +0100 Message-Id: <201103280856.p2S8uifq028758@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 28 Mar 2011 09:46:41 +0100 To: ConEx IETF list From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 28 Mar 2011 08:56:50.0244 (UTC) FILETIME=[13887040:01CBED26] Subject: [conex] Fwd: Re: Comments on draft-briscoe-tsvwg-ecn-encap-guidelines-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 08:55:17 -0000 ConEx list, I'm cross-posting this from tsvwg. One of Nandita's points was that ConEx should=20 work equally if the underlying congestion=20 signalling is forwards or backwards. This intial=20 draft aims to make recommendations on the=20 interface between lower layer congestion signalling and ECN in IP. It's also relevant to the two talks Lei Zhu gave=20 a couple of ConEx meetings ago. Links to slides for tsvwg (Thu) and to the draft are here: Cheers Bob >Date: Mon, 28 Mar 2011 09:27:18 +0100 >To: Gorry Fairhurst >From: Bob Briscoe >Subject: Re: Comments on draft-briscoe-tsvwg-ecn-encap-guidelines-00 >Cc: > >Gorry, > >I'm about to rspond to you cc the list. > >This is just an off-list response to say I said=20 >at the top of my mail (still quoted in your=20 >reply) that you could reply on-list :) > > >Bob > >At 08:40 28/03/2011, Gorry Fairhurst wrote: >>I'm sending this to you off-list (only because your mail was off-list). >> >>I suspect some of this should be posted to the=20 >>list (feel free to post some or all of my response). >> >>We seem to agree mostly. See brief notes below: >> >>On 28/03/2011 03:01, Bob Briscoe wrote: >>>Gorry, >>> >>>Thank you for your v useful (as always) and comprehensive (as always) >>>review and chair comments. >>> >>>I'd be happy for any future response to cc the discussion so far to the >>>list. >>> >>>Inline responses... >>> >>> >>>At 18:55 27/03/2011, Gorry Fairhurst wrote: >>> >>>>draft-briscoe-tsvwg-ecn-encap-guidelines-00 >>>> >>>>Thanks for uploading the draft on Congestion Notification for link >>>>layers. I have some comments and suggestions below. >>>> >>>>Best wishes, >>>> >>>>Gorry >>>> >>>>I have reviewed the above draft as a member of TSVWG (Chair hat >>>>comments at the end). >>>> >>>>- I'm interested in this topic and would be happy to read and >>>>contribute to the evolution of this draft. >>>> >>>>" Even a whole >>>>meshed subnetwork can be made immune to interior congestion by >>>>careful network design; interior links can be sufficiently >>>>provisioned relative to the edge capacities to absorb even worst-case >>>>patterns of load." >>>>- This seems to imply internal congestion can always be avoided. Is >>>>this always the case? I'm not sure I believe this. In contrast, I'd >>>>suggest the "worst-case" is that the interface/subnetwork drops >>>>packets under load. >>> >>>I only said 'a network can be'. I was thinking of a 3-stage clos network >>>as discussed in S.8 of the (long but highly interesting) paper below >>>[Reid05]. It becomes prohibitive to scale this to keep it guaranteed >>>non-blocking, but such a multipath topology does strongly reduce the >>>chances of congestion on interior links. >>> >>>Reid, A., "Economics and Scalability of QoS Solutions," BT Technology >>>Journal 23(2):97--117 (April 2005) ((access requires registration but no >>>fee)) Abstract URL: >>>http://www.btplc.com/Innovation/Journal/BTTJ/archive/Abstract.aspx?JType= =3DBTTJ&IDVol=3D23&IDArt=3D2&IDAbs=3D19 >>I just didn't want to give the impression that=20 >>L2 offered a generic solution in all cases. >> >>> >>>>- RFC3819 S 13 says something about L2 buffers and congestion, and may >>>>also be useful reference point on some terminology. >>> >>>Thank you - I had completely forgotten about that. >>> >>> >>>>"Also it might be costly to find an IP >>>>header (v4 or v6) when it may be encapsulated by more than one >>>>Ethernet header (e.g. when using multiple encapsulations of MAC in >>>>MAC [IEEE802.1Qah])." >>>>- IP encapsulation in its various forms also makes this deep pack >>>>inspection more complex. The IP router at the L2 edge of subnet needs >>>>to do this anyway? >>> >>>Well no, the whole point is that if the marking is being done in a L3 >>>queue, the IP header is the one being acted on - it's already been >>>decapsulated and doesn't have to be looked for - it *is* the outer. But >>>if marking is being done by a switch that is acting on a L2 header, >>>there's no saying how deep it will have to bury to find the first IP >>>header to mark. >>This was probably just language clarity - we agree. >> >>>>"the end-station" >>>>- I wonder if we can find a better term? Can you describe this as the >>>>L2 destination, link egress or the L2 network edge or something like >>>>this? Later sections speak of "subnets" - how does this relate to >>>>these terms? >>> >>>OK. I mentioned all this, when I defined the terms encapsulator & >>>decapsulator, but then I've been inconsistent in the text itself. Thanks. >>> >>>>"reaches the destination transport" >>>>- I think this would be a good place to mention "endpoint" or "host" >>>>or something. >>>> >>>>"the source transport" >>>>- Would transport layer at the sending endpoint be better, since >>>>destination transport is a term that can have multiple meanings to L2 >>>>people. >>> >>>Good point. I'll work on these. >>> >>> >>>>Page 4: >>>> >>>>- I think the word "transport" would benefit from being very clearly >>>>explained including a diagram to show what the IETF means by >>>>transport. I suspect many in the intended group of "users" for the >>>>document will think of transport as being below IP, in contrast to >>>>where the IETF places this term. >>> >>>Yes - I argue with them that they should disambiguate, so I should. >>> >>>[However, I must add that when I challenge them to refer to any document >>>at all for a definition for their use of the word transport, they have >>>absolutely nothing formal to cite. It's just a general word for stuff >>>that carries things, much like we talk of cars and buses as transport. >> > >>Agree. >>> >>>>- Inner header and outer header are also terms that may benefit from a >>>>little more detail for a layer 2 audience? >>> >>>I assume you are saying the terminology section entries are not even >>>enough. >>> >>> >>>>- Congestion baseline: I didn't understand this definition, and >>>>suspect this is important, can you explain? >>> >>>OK, yes, the definition is unclear. "Congestion notification baseline" >>>would be a more intuitive but longer phrase. The place where congestion >>>notification was last zeroed (typically at the ultimate source endpoint). >>The shorter form seems OK, but more info, e.g. a picture may help. >> >>> >>>>Page 5: >>>>"If the lower layer has its own >>>>feedback and load regulation, there is no need to propagate >>>>congestion signalling up the layers. " >>>>- Is this *always* true? >>> >>>There is no need to have a *deliberate* mechanism to propagate >>>signalling up the layers. But that doesn't mean it won't happen >>>naturally - when the lower layer cannot clear the load, the higher layer >>>queue at the subnet ingress will back-up and *it* might then signal >>>congestion (without any direct link to the lower layer congestion >>>notification signalling). >>> >>>I've seen this approach described in a patent filed by someone working >>>on QCN (IEEE 802.1Qau). >>> >>> >>>>S 3.1 >>>> >>>>- The statement that lower layer protocols need to distinguish ECN >>>>support by PDU seems harsh? I'd have thought that many do not not, and >>>>the implication is that the egress of the L2 network then needs to >>>>take appropriate action. >>> >>>You're right - I had evolved my thinking since writing that, but >>>overlooked changing it. Will do next rev. >>> >>> >>>>- Is the sentence below correct? >>>>"For instance, ECN- >>>>capable transports might only be allowed to use PDUs identified by a >>>>particular set of labels or tags." >>>>- Or is it "For instance, Only ECN-capable transports may be allowed=85" >>> >>>you're right >>> >>> >>>>"This strategy might not be appropriate for >>>>other link technologies targeted at zero-configuration deployment by >>>>the general public (e.g. " >>>>- I wonder if the issue here is more about "zero-configuration >>>>deployment" and the "general public" is an example of typical usage, >>>>i.e. I'd have expected any zero-conf approach to have these properties. >>> >>>yes. The general public ought to be an example of users of zero-conf. >>> >>> >>>>S 3.2 bullet 1. >>>> >>>>- I think my comment may resemble ones for other sections, but I'd >>>>like to understand: This talks about copying ECN markings, but is it >>>>acceptable also to discard packets that are marked at this point? >>> >>>Ooh no. At ingress, an arriving marking will arrive in the IP header, so >>>one has to assume it was put there after safely checking the IP header >>>said the transport was ECN aware. >>> >>>At the ingress, the issue is about checking whether the ECN capability >>>of the lower layer (the one about to encapsulate) would be appropriately >>>handled when it is decapsulated. There's no need to resort to drop for >>>that - just turn off ECN capability in the outer. >>I see. We can thrash-out the guidance detail later. >> >>> >>>>S 3.2 bullet 2. >>>>- Is the assumption that the outer header does carry an ECN marking? >>>>Is it possible that the ECN properties of a flow could be in the >>>>control plane and therefore not part of the PDU, but would be visible >>>>at the egress. How would this best be handled? >>> >>>Yes, I need to treat in- and out-of-band congestion signalling as two >>>separate cases. So far I've only dealt with the former. >>> >>>You'll see I say in my slides I need help making this doc less >>>prescriptive about what the lower layer looks like (without making it so >>>abstract it becomes confusing). >>> >>> >>>>S 3.2 final para. >>>>- The actors and intention for this point were not clear to me. >>> >>>OK, I need to flesh this out - perhaps I'll use an example like an ATM >>>subnet. >>> >>>>/the whole path/ - is this end-to-end path or something else? >>> >>>e2e >>> >>>>/divided into segments/ - i.e. several segments combine to make the >>>>path or do you mean several L2 functions combine together (i >>>>parallel?) to provide the subnet service? /start of segment/, I >>>>presume this is ingress to the L2? >>> >>>"segments" aren't necessarily congruent with L2 subnets. They can be >>>aligned with the scope of tunnels (e.g. pseudowires). A sequence of PCN >>>domains would be another case. They are characterised by a load >>>regulator at the segment ingress and a feedback loop between segment >>>egress and ingress. >>> >>> >>>>S 3.3 bullet 1 >>>> >>>>" * If the outer header carries an explicit congestion marking, >>>>the packet SHOULD be dropped--the only indication of >>>>congestion the transport will understand." >>>>- Why isn't this a MUST? >>>>- If the intention is to indicate something to the endpoint, then the >>>>packet needs to be dropped. Otherwise don't pass the marking upwards >>>>to IP. Am I missing something? >>> >>>Because I said I would say nothing as a MUST :) >>> >>>Even in RFC6040, this ended up being a SHOULD in one case (where the >>>marking wasn't the most severe). >> > >>Not sure, but can be thrashed-out later. >> >>> >>>>S 3.3 bullet 1 >>>>- Is it possible to insist that the Highest marking MUST either set an >>>>IP marking or result in discard (using the above rule to decide >>>>which), lesser levels MAY have the same behaviour. That way we have >>>>more "sense" that the endpoint will react. >>> >>>Seriously, I don't like MUST in guidelines. But you're right, SHOULD >>>gives a liberal impression that is unwarranted. Your solution is one >>>approach - I'll think about it. >>I think it's more than "should". >> >>> >>>>S 3.3 bullet 4 >>>>- I think this should also refer to the RFC that defines alternate ECN >>>>markings with DS. >>> >>>Yup. >>> >>> >>>>--- Chair comments --- >>>> >>>>I didn't do a complete review of this revision as a TSVWG Chair, and I >>>>am making no judgement at this time about whether this should be made >>>>a TSVWG work item. I suggest it would be first good to see more >>>>discussion on the contents voa the TSVWG list. >>>> >>>>I have the following comments that may be useful to consider for the >>>>next edit: >>>> >>>>- The draft proposes work on a topic that has been brought to the IETF >>>>before, although I am not aware of a published IETF document on this. >>>>However, this does not alone justify why the IETF should work on this >>>>topic: What are the risks and threats of NOT publishing this document? >>> >>>I've addressed this in my slides. >>>We need a place for temporal motivation text. It's not appropriate for >>>RFCs which are meant to be timeless, but we need to record somewhere why >>>we did something at a particular time. >>Exactly. it's best handled in email/meeting notes. >> >>>I have the same problem with trying to find a motivation for RSVP drafts. >>> >>>Perhaps there ought to be a requirement for a motivation statement on >>>the mailing list when a draft is first posted. >>That would suit me. >> >>> >>>>- This document does not appear to change an existing IETF >>>>specification, are there any current or proposed IETF documents that >>>>would be updated if this were to be published? >>> >>>Amazingly, I couldn't find one. Altho I'll have to look at 3819. >>> >>> >>>>- Section 1 says "The IETF would like to encourage this trend." - This >>>>is a consensus judgement that maybe needs to be confirmed by TSVWG. >>> >>>Of course. The idea of putting it in is to allow people to either agree >>>or not. >>OK >>> >>>>- The topic may benefit from coordination with other groups outside of >>>>he IETF. >>> >>>Yup - if it is adopted as WG item, it could benefit from a note at least >>>to IEEE, and possibly 3GPP (see slides about next steps - to include >>>propagating ECN through tunnelling protocol modules in the stack, even >>>tho they aren't ever the outer on the wire, e.g. GTP). >>> >>>Even if they aren't working on this, the statement to the IEEE might say >>>they ought to consider it, because switch vendors are putting out kit >>>that is getting used for this without a standard. >>OK >> >>>>--- END Chair comments --- >>> >>>Excellent - thank you - as always highly useful comments. >>> >>> >>>Bob >>> >>> >>>________________________________________________________________ >>>Bob Briscoe, BT Innovate & Design >________________________________________________________________ >Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design =20 From philip.eardley@bt.com Mon Mar 28 02:27:28 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF67D3A690B for ; Mon, 28 Mar 2011 02:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.915 X-Spam-Level: X-Spam-Status: No, score=-101.915 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HYb1IvOI0py for ; Mon, 28 Mar 2011 02:27:27 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by core3.amsl.com (Postfix) with ESMTP id 78A9C3A6A26 for ; Mon, 28 Mar 2011 02:27:24 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 28 Mar 2011 10:29:01 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.142]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Mon, 28 Mar 2011 10:28:59 +0100 From: To: , Date: Mon, 28 Mar 2011 10:28:59 +0100 Thread-Topic: possible conex use case in ops wg meeting Thread-Index: AQHL7SqRndx09eCrCkSUkFDRxCjW2w== Message-ID: <9510D26531EF184D9017DF24659BB87F327E900C41@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [conex] possible conex use case in ops wg meeting X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 09:27:28 -0000 This Draft was just briefly presented in the opsawg meeting.it struck me th= at something on this line might be a use case for conex Phil= From philip.eardley@bt.com Mon Mar 28 02:28:26 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E1523A6910 for ; Mon, 28 Mar 2011 02:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.92 X-Spam-Level: X-Spam-Status: No, score=-101.92 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chVzzqkN14wn for ; Mon, 28 Mar 2011 02:28:25 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by core3.amsl.com (Postfix) with ESMTP id DA9CD3A681B for ; Mon, 28 Mar 2011 02:28:24 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 28 Mar 2011 10:30:01 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.142]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Mon, 28 Mar 2011 10:30:01 +0100 From: To: , Date: Mon, 28 Mar 2011 10:30:01 +0100 Thread-Topic: possible conex use case in ops wg meeting Thread-Index: AQHL7Sq2R96oc8Q8yEi/ZkKcSiUjAg== Message-ID: <9510D26531EF184D9017DF24659BB87F327E900C42@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [conex] possible conex use case in ops wg meeting X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 09:28:26 -0000 This Draft was just briefly presented in the opsawg meeting.it struck me th= at something on this line might be a use case for conex Phil= From philip.eardley@bt.com Mon Mar 28 02:29:11 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE39C3A6925 for ; Mon, 28 Mar 2011 02:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.925 X-Spam-Level: X-Spam-Status: No, score=-101.925 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28E9l71Ja34P for ; Mon, 28 Mar 2011 02:29:11 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by core3.amsl.com (Postfix) with ESMTP id 9A0073A68B0 for ; Mon, 28 Mar 2011 02:29:10 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 28 Mar 2011 10:30:47 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.142]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Mon, 28 Mar 2011 10:30:47 +0100 From: To: , Date: Mon, 28 Mar 2011 10:30:47 +0100 Thread-Topic: possible conex use case in ops wg meeting Thread-Index: AQHL7SrR9CLA6mLfaEm1XDLi5qhDIA== Message-ID: <9510D26531EF184D9017DF24659BB87F327E900C43@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [conex] possible conex use case in ops wg meeting X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 09:29:12 -0000 This Draft was just briefly presented in the opsawg meeting.it struck me th= at something on this line might be a use case for conex Phil= From bob.briscoe@bt.com Mon Mar 28 02:51:39 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C509C3A68E3 for ; Mon, 28 Mar 2011 02:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R81-AXAKUbUF for ; Mon, 28 Mar 2011 02:51:38 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id EB8A93A681B for ; Mon, 28 Mar 2011 02:51:37 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Mar 2011 10:53:14 +0100 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, 28 Mar 2011 10:53:14 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1301305993306; Mon, 28 Mar 2011 10:53:13 +0100 Received: from MUT.jungle.bt.co.uk ([10.142.66.49]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p2S9rCN6029320; Mon, 28 Mar 2011 10:53:12 +0100 Message-Id: <201103280953.p2S9rCN6029320@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 28 Mar 2011 10:53:12 +0100 To: Mirja Kuehlewind From: Bob Briscoe In-Reply-To: <201103081324.25218.mirja.kuehlewind@ikr.uni-stuttgart.de> References: <201103081324.25218.mirja.kuehlewind@ikr.uni-stuttgart.de> 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: 28 Mar 2011 09:53:14.0298 (UTC) FILETIME=[F49619A0:01CBED2D] Cc: conex@ietf.org Subject: Re: [conex] Proposed Text for New Section in Use Case Draft - Statistical multiplexing over Longer Timescales X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 09:51:39 -0000 Mirja, I just (late as always) noticed this statement that I have to challenge, because it misses the whole essence of ConEx IMO: At 13:24 08/03/2011, Mirja Kuehlewind wrote: >- First, there is no difference between having a shaper or having a limited >access bandwidth. There is a world of difference. If I have 40Mb/s limited access bandwidth on a shared network (e.g. cable, or a PON), it's because the operator has to limit my peak information rate in order to give other users a committed information rate. If the operator has ConEx signalling and a ConEx policer in its toolkit, if the underlying access link has a physical capacity of 1Gb/s (say), the operator can allow each customer 1Gb/s peak, not 40Mb/s. Obviously, if many are trying to use 1Gb/s all at once, they won't all be able to use 1Gb/s each. But then, if they don't respond themselves (which they normally would) the Congestion policer will limit them to a fair share of the network, where 'fair' will depend on their long term behaviour in response to congestion, not just instantaneous. Lesson: We shouldn't assume that MAC layer policies will always reflect the way networking was done before the operator could see congestion. MAC layer sharing policies are generally possible to change at a single point. Then ConEx could make traffic patterns on a public access network much more like on a LAN: with faster transfer bursts that finish sooner, so the next one can burst faster. One could say this hasn't been proved in practice. But when you're on a campus LAN accessing some data centre over the Internet, this is how things have always worked (except you don't have a ConEx policer to limit heavy contributors to congestion). Bob PS. Assuming you mean shaper = congestion policer (please can we stop using the word "shaper") ________________________________________________________________ Bob Briscoe, BT Innovate & Design From don@sandvine.com Mon Mar 28 03:45:18 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0E9E3A6A67 for ; Mon, 28 Mar 2011 03:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQaVHfTIevdR for ; Mon, 28 Mar 2011 03:45:18 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by core3.amsl.com (Postfix) with ESMTP id CFA383A6A31 for ; Mon, 28 Mar 2011 03:45:17 -0700 (PDT) Received: from WTL-EXCH-1.sandvine.com ([fe80::f523:8e57:71d7:5206]) by wtl-exch-2.sandvine.com ([fe80::8959:ede3:2dbe:c1b%15]) with mapi; Mon, 28 Mar 2011 06:46:54 -0400 From: Don Bowman To: Bob Briscoe , Mirja Kuehlewind Thread-Topic: [conex] Proposed Text for New Section in Use Case Draft - Statistical multiplexing over Longer Timescales Thread-Index: AQHL7S35hFJZkPuOkEWsWffQbnLyO5RCjiYg Date: Mon, 28 Mar 2011 10:46:53 +0000 Message-ID: <942A83603E075D499AEBA76ACECF7C6804C3E7@wtl-exch-1.sandvine.com> References: <201103081324.25218.mirja.kuehlewind@ikr.uni-stuttgart.de> <201103280953.p2S9rCN6029320@bagheera.jungle.bt.co.uk> In-Reply-To: <201103280953.p2S9rCN6029320@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] Proposed Text for New Section in Use Case Draft - Statistical multiplexing over Longer Timescales X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 10:45:19 -0000 Bob Briscoe wrote: > At 13:24 08/03/2011, Mirja Kuehlewind wrote: > >- First, there is no difference between having a shaper or having a > limited > >access bandwidth. >=20 > There is a world of difference. >=20 > If I have 40Mb/s limited access bandwidth on a shared network (e.g. > cable, or a PON), it's because the operator has to limit my peak > information rate in order to give other users a committed information > rate. >=20 ... >=20 > PS. Assuming you mean shaper =3D congestion policer (please can we stop > using the word "shaper") >=20 FWIW, we use the term 'shaper' as something which has (sometimes large)=20 buffering, and is conditioning something of about the right rate into a=20 specific output. In general use a shaper doesn't drop much packets, and is used to gasket a peaky-network into a non-peaky network. A policer on the other hand forces a peak rate strictly, dropping above it. So there is indeed another big difference between a limited access bandwidt= h (e.g. physically capable of some rate) vs one that is 'shaped' or 'policed'= . In the 'MAC limit' sense, the only latency introduced is that of the MAC-la= yer buffers. In e.g. Cable modem this can be pretty significant, often=20 64KB @ e.g. 1Mbps =3D=3D ~1/2s latency. In the properly-setup shaper case, the latency introduced due to buffering is something like 2x the jitter of the upstream. In the (strict) policer case, the latency introduced is 0, and all peaks ar= e=20 discarded. --don From bob.briscoe@bt.com Mon Mar 28 04:42:17 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08B563A67E6 for ; Mon, 28 Mar 2011 04:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7KCmNzMS8hT for ; Mon, 28 Mar 2011 04:42:15 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 88E193A6A3A for ; Mon, 28 Mar 2011 04:42:04 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Mar 2011 12:43:41 +0100 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, 28 Mar 2011 12:43:41 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1301312619857; Mon, 28 Mar 2011 12:43:39 +0100 Received: from MUT.jungle.bt.co.uk ([10.142.66.49]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p2SBhcLe030524; Mon, 28 Mar 2011 12:43:38 +0100 Message-Id: <201103281143.p2SBhcLe030524@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 28 Mar 2011 12:43:38 +0100 To: John Leslie From: Bob Briscoe In-Reply-To: <20110303203456.GB89966@verdi> References: <20110226145616.GH7663@verdi> <20110303203456.GB89966@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: 28 Mar 2011 11:43:41.0171 (UTC) FILETIME=[6282AC30:01CBED3D] Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 11:42:17 -0000 John, Ah - I realised I didn't click send on this, some time back... [I hope people can reload the state from the quoted thread - point to is relevant to discussion right now.] 1/ ECN is a signal of congestion. Drop is (ambiguously) a signal of congestion or the outcome of policy action (or 13 other things). Just because drop shares one meaning with ECN, doesn't mean ECN has to share one of the meanings of drop. A policer needs to impair the traffic. ECN isn't impairment. So ECN isn't relevant as an outcome of policing. There's no room for debate here IMO - a policer adding ECN markings is just plain stupid. If someone isn't responding sufficiently to ECN markings, adding more ECN markings is never going to be used by a sentient network operator to punish them. 2/ Can we stop calling the policer a shaper please? Shaping is theoretically one action a policer might take, but it's one that causes more confusion and arguments because it's so weak. Shaping is something some operators still do to make a packet network look like a phone network in the belief it will improve things, when it merely adds delay deterministically that might otherwise not be added statistically. Like ECN, it's not really a useful tool in the punishment armory. A thing that punishes out of contract behaviour is called a policer. Let's stop using confusing terms. 3/ Distinguishing self-congestion from shared congestion is a real issue. It's actually even more subtle. Self-congestion can be further divided into: * congestion of a resource you're leasing from your provider for (e.g. your access line), which you expect the provider to maintain and upgrade, * congestion of something you bought yourself (e.g. your home network). The network provider might want to include the former (sole-congestion of leased equipment) with shared congestion as part of the economic signals to indicate what needs upgrading. Bob At 21:34 03/03/2011, John Leslie wrote: >Mcdysan, David E wrote: > > On 2/26/11 9:56 AM, "John Leslie" wrote: > > > >> Clearly, we do have to produce a use-cases document, though I would > >> prefer that at least an "abstract mechanism" could be agreed to as a > >> basis for it. > > > > Not sure I understand what you are proposing. > > I was stating a preference (not expecting it to be satisfied). > > > The wg decided to take mechanism largely out of the use case draft in > > IETF 78, and in IETF 79 the exclusion of a use case that did not match > > the adopted abstract mechanism was explicitly agreed (see meeting > > minutes snippet in my response to Allison). > > My preference was that we might have had sufficient agreement on an >abstract mechanism so that we didn't have to dance-around that issue >(which IMHO tends to confuse readers). > > >> I am hesitant to go the path of labeling use-cases according to what > >> metric best serves them. IMHO, our use-cases document should only include > >> things achievable with a particular metric, which I have been assuming > >> to be congestion-expected-during-transit. > > > > Metric is mentioned once in the use case document in section 3 in the > > context of existing approaches. Are you referring to the measures in > > definitions of use cases, or something in the abstract mechanism draft? > > (where the term metric is not used at all) > > I have explained elsewhere what I mean by "metric". I may well continue >to use that term (to mean what I said I meant) in preference to "measure" >until we come up with an agreed meaning for "measure". (Alas, the >mathematical usage of "measure" is IMHO a poor fit to what I hope we >mean to talk about. > > (I do not wish to argue semantics -- I merely reserve the right to >speak exactly instead of vaguely, where what I say will mean different >things to different readers.) > > >> Certainly, ConEx will need to operate in an environment where such > >> "shaping" occurs. I am considerably less sure how (if at all) it should > >> be discussed in a use-cases document. > > > > I asked this question in IETF 78 of Bob regarding a non-work conserving > > scheduler (e.g., shaper), which can experiences the congestion measure as > > defined in the current use case draft. > > Now _I'm_ not sure I understand what you're proposing... > > "Shaper" is a vague term -- and AFAICT must remain vague because its >function(s) will be determined by many parties so as to satisfy their >(many different) business models. > > Discussion elsewhere throws light on what some of us are thinking: >that whether or not we accept "shaping" as "congestion", it is not >"contention" -- it doesn't reflect an attempt to take resources away >from other flows. > > IMHO, if we go the ECN route, we have to accept ECN marks as indicating >"congestion": if a "shaper" ECN-marks, that's "congestion" we must expose. >OTOH, if the "shaper" drops, it's no longer a "must"; and if a "shaper" >merely delays, we don't necessarily have to do anything. > > Speaking for myself, I don't believe we can cover all the cases of >"shaper" actions. At some point, we have to "treat it as damage" (and >assume routing-around-it is Somebody Else's Problem). ;^) > > > At a minimum I think the statement in the first paragraph of section 4 > > that describes what I called "inter-user congestion" as "---- congestion > > means that your traffic impacts other users, and conversely that their > > traffic impacts you." needs to exclude the use case of what I called > > "self-congestion" needs to address the use case employed by many ISPs (as > > Toby points out). > > I agree -- that's not a sufficient definition of "congestion". > > >> To me, it is "congestion" even if it is not resource-congestion. > >> Congestion-expected markings could better inform decisions about > >> "shaping". The issues about whether ConEx marking is considered at > >> any point of congestion are much the same... > > > > I didn't follow this. Could you please elaborate. > > So far, I don't see a practical way to distinguish ECN-marking due to >queue-filling from ECN-marking due to shaping. I have little desire to >try; and I suggest that deserves to be an area-for-future-work. I >consider both to be "congestion" that we are charged to "expose". > >-- >John Leslie >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design From swmike@swm.pp.se Mon Mar 28 04:49:28 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A9353A6811 for ; Mon, 28 Mar 2011 04:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZAOtIsND7TR for ; Mon, 28 Mar 2011 04:49:27 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id DBED03A67E6 for ; Mon, 28 Mar 2011 04:49:26 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1969F9C; Mon, 28 Mar 2011 13:51:02 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 14E289A; Mon, 28 Mar 2011 13:51:02 +0200 (CEST) Date: Mon, 28 Mar 2011 13:51:02 +0200 (CEST) From: Mikael Abrahamsson To: Bob Briscoe In-Reply-To: <201103281143.p2SBhcLe030524@bagheera.jungle.bt.co.uk> Message-ID: References: <20110226145616.GH7663@verdi> <20110303203456.GB89966@verdi> <201103281143.p2SBhcLe030524@bagheera.jungle.bt.co.uk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 11:49:28 -0000 On Mon, 28 Mar 2011, Bob Briscoe wrote: > There's no room for debate here IMO - a policer adding ECN markings is > just plain stupid. If someone isn't responding sufficiently to ECN > markings, adding more ECN markings is never going to be used by a > sentient network operator to punish them. I don't agree with this at all. Let's take the case with a router/switch with small buffers. I don't see the huge difference in having a policer doing ECN markings at 95% of wirespeed and then letting the small buffer taildrop at 3-5ms of buffering, compared to something that has 50ms of buffering and using RED starts doing ECN markings/RED after 5ms of buffers fill. > 2/ Can we stop calling the policer a shaper please? > Shaping is theoretically one action a policer might take, but it's one that > causes more confusion and arguments because it's so weak. A policer NEVER ever shapes. Shaping is the delaying/buffering of packets. A policer is something that has buckets and either drops, marks and/or transmits packets, never ever delays them. > Shaping is something some operators still do to make a packet network look > like a phone network in the belief it will improve things, when it merely > adds delay deterministically that might otherwise not be added statistically. > Like ECN, it's not really a useful tool in the punishment armory. A thing > that punishes out of contract behaviour is called a policer. Let's stop using > confusing terms. It seems we need a discussion on the basic terms people use to describe behaviour. -- Mikael Abrahamsson email: swmike@swm.pp.se From dave.mcdysan@verizon.com Mon Mar 28 05:31:12 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1766B3A68C0 for ; Mon, 28 Mar 2011 05:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.508 X-Spam-Level: X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MbpTlddDr+q for ; Mon, 28 Mar 2011 05:31:09 -0700 (PDT) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id 11A4D3A680B for ; Mon, 28 Mar 2011 05:31:04 -0700 (PDT) Received: from fldsmtpi03.verizon.com (fldsmtpi03.verizon.com [166.68.71.145]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p2SCWKVs027769 for ; Mon, 28 Mar 2011 08:32:29 -0400 (EDT) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.63,255,1299456000"; d="scan'208";a="19537853" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi03.verizon.com with ESMTP; 28 Mar 2011 12:32:20 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.173]) by FHDP1LUMXC7HB02.us.one.verizon.com ([2002:a644:3bbd::a644:3bbd]) with mapi; Mon, 28 Mar 2011 08:32:20 -0400 To: Mikael Abrahamsson , Bob Briscoe Date: Mon, 28 Mar 2011 08:32:18 -0400 Thread-Topic: [conex] Discussion of new Use Cases pt 1 - Shaper Definition Thread-Index: AcvtRC3ejeRRw6bHQ+GxEighrks+0g== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 - Shaper Definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 12:31:12 -0000 I agree with Mikael that we need to agree on what is meant by specific terms. When I used the term "shaper" I use it as defined in RFC 2475 as follows: 2.3.3.3 Shapers Shapers delay some or all of the packets in a traffic stream in order to bring the stream into compliance with a traffic profile. A shaper usually has a finite-size buffer, and packets may be discarded if there is not sufficient buffer space to hold the delayed packets. I propose that a reference to this definition be added to the definitions section in the conex use case document to resolve this terminology issue. Does anyone in the wg object? A few responses in line below. Thanks, Dave On Monday3/28/11 7:51 AM, "Mikael Abrahamsson" wrote: >On Mon, 28 Mar 2011, Bob Briscoe wrote: > >> There's no room for debate here IMO - a policer adding ECN markings is >> just plain stupid. If someone isn't responding sufficiently to ECN >> markings, adding more ECN markings is never going to be used by a >> sentient network operator to punish them. > >I don't agree with this at all. > >Let's take the case with a router/switch with small buffers. I don't see >the huge difference in having a policer doing ECN markings at 95% of >wirespeed and then letting the small buffer taildrop at 3-5ms of >buffering, compared to something that has 50ms of buffering and using RED >starts doing ECN markings/RED after 5ms of buffers fill. I think that different cases are assumed here. > >> 2/ Can we stop calling the policer a shaper please? >> Shaping is theoretically one action a policer might take, but it's one >>that=20 >> causes more confusion and arguments because it's so weak. > >A policer NEVER ever shapes. Shaping is the delaying/buffering of >packets.=20 >A policer is something that has buckets and either drops, marks and/or >transmits packets, never ever delays them. See above. > >> Shaping is something some operators still do to make a packet network >>look=20 >> like a phone network in the belief it will improve things, when it >>merely=20 >> adds delay deterministically that might otherwise not be added >>statistically.=20 >> Like ECN, it's not really a useful tool in the punishment armory. A >>thing=20 >> that punishes out of contract behaviour is called a policer. Let's stop >>using=20 >> confusing terms. > >It seems we need a discussion on the basic terms people use to describe >behaviour. Shapers, as defined in RFC 2475, also known as "rate limiters" on a queue as described in Appendix B of DSL Forum TR-059 are used in many ISP networks. [DSL Forum TR-059] Technical Report DSL Forum TR-059, "DSL Evolution - Architecture Requirements for the Support of QoS-Enabled IP Services," September 2003,=20 http://www.broadband-forum.org/technical/download/TR-059.pdf A shaper defines a virtual circuit peak bandwidth and burst duration type behavior for downstream and upstream customer access. This is easy for customers and connecion-oriented operators to understand and relatively easy to measure.=20 However, it does have issues since operators don't allocate the peak rate and instead allocated aggregate capacity across users based upon a multiplier of the average rate. I posed the 20% of users create 80% of the load problem and conex information may be helpful in addressing part of this issue.=20 Section 6.3 of the current draft was based upon a concept advanced by Toby, edited by myself and John to describe a possible way to do this. The feedback from at least 3 people on the list was that this level of detail was not needed in the wg use case document and that a briefer description would be appropriate. I hope to send out some proposed additional text for section 5.1 where a sentence or two in an additional paragraph would capture this though. > >--=20 >Mikael Abrahamsson email: swmike@swm.pp.se >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex From swmike@swm.pp.se Mon Mar 28 05:58:49 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 437CE3A6A80 for ; Mon, 28 Mar 2011 05:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EBdH38Qp+Rd for ; Mon, 28 Mar 2011 05:58:48 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 2A6023A6A2C for ; Mon, 28 Mar 2011 05:58:47 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D4C749C; Mon, 28 Mar 2011 15:00:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CF66E9A for ; Mon, 28 Mar 2011 15:00:23 +0200 (CEST) Date: Mon, 28 Mar 2011 15:00:23 +0200 (CEST) From: Mikael Abrahamsson To: "conex@ietf.org" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [conex] Discussion of new Use Cases pt 1 - Shaper Definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 12:58:49 -0000 On Mon, 28 Mar 2011, Mcdysan, David E wrote: > Shapers, as defined in RFC 2475, also known as "rate limiters" on a > queue as described in Appendix B of DSL Forum TR-059 are used in many > ISP networks. For me a "rate limiter" is a policer, not a shaper. I'd imagine most of the ISP business would give you the exact same answer. > A shaper defines a virtual circuit peak bandwidth and burst duration > type behavior for downstream and upstream customer access. This is easy > for customers and connecion-oriented operators to understand and > relatively easy to measure. A shaper emulates the behaviour of a port that is full and is doing output queueing, but at any speed and in any direction. It can do WRED/ECN, just like a port doing queueing. I think someone needs to define the terms in the document itself, otherwise you'll get confusion as different organisations define these terms differently. Also, I think anyone who wants to present CONEX to a wider audience needs to create me concrete examples about what's going on. I've been doing routing/QOS engineering for 10+ years, most of the time I don't get what people in this group are talking about. It's like you're living in a completely different world and using completely different words to describe things. I understand exactly how ECN works, I have read the CONEX documents fairly well, but it's still extremely abstract what the discussions are about and this is going to work in the real world (ie where the rubber meets the road). -- Mikael Abrahamsson email: swmike@swm.pp.se From toby@moncaster.com Mon Mar 28 07:32:26 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 846F23A68F3 for ; Mon, 28 Mar 2011 07:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqOKc5s6-QkE for ; Mon, 28 Mar 2011 07:32:25 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id 568213A659A for ; Mon, 28 Mar 2011 07:32:25 -0700 (PDT) Received: from TobysHP (host86-149-183-12.range86-149.btcentralplus.com [86.149.183.12]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MT5yY-1QWMl42Pw6-00S3t1; Mon, 28 Mar 2011 16:34:00 +0200 From: "Toby Moncaster" To: "'Mikael Abrahamsson'" , References: In-Reply-To: Date: Mon, 28 Mar 2011 15:34:00 +0100 Message-ID: <005d01cbed55$2e415df0$8ac419d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvtSB2WDjeQ1V1vRD6VpWMedTMHfwACzgYw Content-Language: en-gb X-Provags-ID: V02:K0:8GKl58nvFOiJCufVhnxxbwRuOFqhe6x5YFePo0OlgWD rax51/kv07CjeFEJYxDiDatU2+B0AnCfdycTISR1mCHE5u9sSy 31e5iY90Vysq75EtoWJuR7sWrALFdElhFED6VLcKFDk0KfaiTJ 6RwgiXDCkl2yaam1RPaXg27R1QclooROaB/Na/gCfX5vY4Ex5M rXLky0X2n3Sw8pc4LycHi9LJkQlCnpeFxGRJNQqF0c= Subject: Re: [conex] Discussion of new Use Cases pt 1 - Shaper Definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 14:32:26 -0000 > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Mikael Abrahamsson > Sent: 28 March 2011 14:00 > To: conex@ietf.org > Subject: Re: [conex] Discussion of new Use Cases pt 1 - Shaper > Definition > > On Mon, 28 Mar 2011, Mcdysan, David E wrote: > > > Shapers, as defined in RFC 2475, also known as "rate limiters" on a > > queue as described in Appendix B of DSL Forum TR-059 are used in many > > ISP networks. > > For me a "rate limiter" is a policer, not a shaper. I'd imagine most of > the ISP business would give you the exact same answer. > > > A shaper defines a virtual circuit peak bandwidth and burst duration > > type behavior for downstream and upstream customer access. This is > easy > > for customers and connecion-oriented operators to understand and > > relatively easy to measure. > > A shaper emulates the behaviour of a port that is full and is doing > output > queueing, but at any speed and in any direction. It can do WRED/ECN, > just > like a port doing queueing. I suspect a lot of the confusion comes about because many ISPs use what are sometimes called DPI boxes or traffic management boxes to impose a host of controls on a user's traffic. Some of these controls are shaping to a given rate, some are policing by dropping, some I suspect are something of a mix. >From my (admittedly fairly limited) observations, ISPs tend to be prosaic about these things - they don't care what the official terms are for what they are doing, they simply fiddle until they reach a situation where most customers are getting a better service with minimal cost to the ISP. > > I think someone needs to define the terms in the document itself, > otherwise you'll get confusion as different organisations define these > terms differently. I agree 100% - we will make sure we define exactly what we mean within the document to overcome this confusion over terminology. > > Also, I think anyone who wants to present CONEX to a wider audience > needs > to create me concrete examples about what's going on. I've been doing > routing/QOS engineering for 10+ years, most of the time I don't get > what > people in this group are talking about. It's like you're living in a > completely different world and using completely different words to > describe things. > > I understand exactly how ECN works, I have read the CONEX documents > fairly > well, but it's still extremely abstract what the discussions are about > and > this is going to work in the real world (ie where the rubber meets the > road). The BIG problem all along for ConEx is that it operates (almost uniquely) at a complex intersection between network economics, ISP network management, e2e transport, IP, etc. Experts in all these fields are contributing, but all of them speak very different languages and all viewing the world with very different pre-conceptions. It is proving nigh impossible to write text that is unambiguous enough to get everyone to understand what we are aiming to do. Almost every time we describe it in a different way we get new people understanding it, but seem to lose some others that had though they knew what we were doing! Part of the problem is that ConEx truly is a revolutionary concept - it isn't easy to see what it does, or why it is needed. It is currently stuck in the trap famously described by Thomas Kuhn in "The structure of scientific revolutions" - we are in challenging some of the paradigms of networking, and just to make life interesting, we have chosen to challenge more than one at a time! BTW, I realise that does nothing at all to explain ConEx to you! What allowed me to "get it" originally was the belief that knowledge (and by extension, information) is good - ConEx closes the information gap between the network and end user and allows the network to be vaguely intelligent about how it controls the end user (and please don't restart the arguments about why a network needs to control users at all - it is apparent that a majority of ISPs do think it necessary to impose controls, so let's try and help them do it more sensibly). Toby > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From toby@moncaster.com Mon Mar 28 07:39:09 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43B8E28C0CE for ; Mon, 28 Mar 2011 07:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIyln7UeTi9g for ; Mon, 28 Mar 2011 07:39:08 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id BE2C63A6978 for ; Mon, 28 Mar 2011 07:39:07 -0700 (PDT) Received: from TobysHP (host86-149-183-12.range86-149.btcentralplus.com [86.149.183.12]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0M8K0I-1PigZC1YHq-00vwns; Mon, 28 Mar 2011 16:40:44 +0200 From: "Toby Moncaster" To: "'Bob Briscoe'" , "'John Leslie'" References: <20110226145616.GH7663@verdi> <20110303203456.GB89966@verdi> <201103281143.p2SBhcLe030524@bagheera.jungle.bt.co.uk> In-Reply-To: <201103281143.p2SBhcLe030524@bagheera.jungle.bt.co.uk> Date: Mon, 28 Mar 2011 15:40:44 +0100 Message-ID: <005e01cbed56$1efb09d0$5cf11d70$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvtPWyKVRILn7KeQNiRvhz4du6qcgAF97cQ Content-Language: en-gb X-Provags-ID: V02:K0:lv11WqGJVUKD9eLaaIwWDzSmvSixgnVqH6u6++sgUk2 cbrVUXiaAnZ75SmewdtNsG0IWx9HMwyzFiIZGADf9lwB2M+qo2 zV7ijId7f0wdWzrXYMtZcUkf+msKxC1EJC9gCcfluVol/4+2yv XPimoTF7KbTMhv9lcn78Lq5kK9J6C23mbqNiuKyhK+9d0xDOso muofMZ7i2TWmjkyL57Ql+FKFNR355x5GfvCRQpfbpY= Cc: conex@ietf.org Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 14:39:09 -0000 Borrowing Bob's Devil's Advocate hat... > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Bob Briscoe > Sent: 28 March 2011 12:44 > To: John Leslie > Cc: conex@ietf.org > Subject: Re: [conex] Discussion of new Use Cases pt 1 > > John, > > Ah - I realised I didn't click send on this, some time back... > [I hope people can reload the state from the quoted thread - point to > is relevant to discussion right now.] > > 1/ ECN is a signal of congestion. Drop is (ambiguously) a signal of > congestion or the outcome of policy action (or 13 other things). Just > because drop shares one meaning with ECN, doesn't mean ECN has to > share one of the meanings of drop. > > A policer needs to impair the traffic. ECN isn't impairment. So ECN > isn't relevant as an outcome of policing. So why can't a "policer" work by ECN marking traffic? Obviously the traffic could ignore the marks, but the action of marking traffic would force a compliant (RFC3168) sender to react as if it had seen drop, in other words, as if the policer had dropped its traffic > > There's no room for debate here IMO - a policer adding ECN markings > is just plain stupid. If someone isn't responding sufficiently to ECN > markings, adding more ECN markings is never going to be used by a > sentient network operator to punish them. > > 2/ Can we stop calling the policer a shaper please? > Shaping is theoretically one action a policer might take, but it's > one that causes more confusion and arguments because it's so weak. > > Shaping is something some operators still do to make a packet network > look like a phone network in the belief it will improve things, when > it merely adds delay deterministically that might otherwise not be > added statistically. Like ECN, it's not really a useful tool in the > punishment armory. A thing that punishes out of contract behaviour is > called a policer. Let's stop using confusing terms. I think we need a standalone discussion on appropriate terms to use for ConEx. There seems to be too much confusion round "shaper", "policer" and "rate limiter" > > 3/ Distinguishing self-congestion from shared congestion is a real > issue. > > It's actually even more subtle. Self-congestion can be further divided > into: > * congestion of a resource you're leasing from your provider for > (e.g. your access line), which you expect the provider to maintain > and upgrade, > * congestion of something you bought yourself (e.g. your home network). And even congestion of a local medium due to current conditions (eg wireless congestion) which is outside anyone's control Toby > > The network provider might want to include the former > (sole-congestion of leased equipment) with shared congestion as part > of the economic signals to indicate what needs upgrading. > > > > Bob > > > At 21:34 03/03/2011, John Leslie wrote: > >Mcdysan, David E wrote: > > > On 2/26/11 9:56 AM, "John Leslie" wrote: > > > > > >> Clearly, we do have to produce a use-cases document, though I > would > > >> prefer that at least an "abstract mechanism" could be agreed to as > a > > >> basis for it. > > > > > > Not sure I understand what you are proposing. > > > > I was stating a preference (not expecting it to be satisfied). > > > > > The wg decided to take mechanism largely out of the use case draft > in > > > IETF 78, and in IETF 79 the exclusion of a use case that did not > match > > > the adopted abstract mechanism was explicitly agreed (see meeting > > > minutes snippet in my response to Allison). > > > > My preference was that we might have had sufficient agreement on > an > >abstract mechanism so that we didn't have to dance-around that issue > >(which IMHO tends to confuse readers). > > > > >> I am hesitant to go the path of labeling use-cases according to > what > > >> metric best serves them. IMHO, our use-cases document should only > include > > >> things achievable with a particular metric, which I have been > assuming > > >> to be congestion-expected-during-transit. > > > > > > Metric is mentioned once in the use case document in section 3 in > the > > > context of existing approaches. Are you referring to the measures > in > > > definitions of use cases, or something in the abstract mechanism > draft? > > > (where the term metric is not used at all) > > > > I have explained elsewhere what I mean by "metric". I may well > continue > >to use that term (to mean what I said I meant) in preference to > "measure" > >until we come up with an agreed meaning for "measure". (Alas, the > >mathematical usage of "measure" is IMHO a poor fit to what I hope we > >mean to talk about. > > > > (I do not wish to argue semantics -- I merely reserve the right to > >speak exactly instead of vaguely, where what I say will mean different > >things to different readers.) > > > > >> Certainly, ConEx will need to operate in an environment where such > > >> "shaping" occurs. I am considerably less sure how (if at all) it > should > > >> be discussed in a use-cases document. > > > > > > I asked this question in IETF 78 of Bob regarding a non-work > conserving > > > scheduler (e.g., shaper), which can experiences the congestion > measure as > > > defined in the current use case draft. > > > > Now _I'm_ not sure I understand what you're proposing... > > > > "Shaper" is a vague term -- and AFAICT must remain vague because > its > >function(s) will be determined by many parties so as to satisfy their > >(many different) business models. > > > > Discussion elsewhere throws light on what some of us are thinking: > >that whether or not we accept "shaping" as "congestion", it is not > >"contention" -- it doesn't reflect an attempt to take resources away > >from other flows. > > > > IMHO, if we go the ECN route, we have to accept ECN marks as > indicating > >"congestion": if a "shaper" ECN-marks, that's "congestion" we must > expose. > >OTOH, if the "shaper" drops, it's no longer a "must"; and if a > "shaper" > >merely delays, we don't necessarily have to do anything. > > > > Speaking for myself, I don't believe we can cover all the cases of > >"shaper" actions. At some point, we have to "treat it as damage" (and > >assume routing-around-it is Somebody Else's Problem). ;^) > > > > > At a minimum I think the statement in the first paragraph of > section 4 > > > that describes what I called "inter-user congestion" as "---- > congestion > > > means that your traffic impacts other users, and conversely that > their > > > traffic impacts you." needs to exclude the use case of what I > called > > > "self-congestion" needs to address the use case employed by many > ISPs (as > > > Toby points out). > > > > I agree -- that's not a sufficient definition of "congestion". > > > > >> To me, it is "congestion" even if it is not resource-congestion. > > >> Congestion-expected markings could better inform decisions about > > >> "shaping". The issues about whether ConEx marking is considered at > > >> any point of congestion are much the same... > > > > > > I didn't follow this. Could you please elaborate. > > > > So far, I don't see a practical way to distinguish ECN-marking due > to > >queue-filling from ECN-marking due to shaping. I have little desire to > >try; and I suggest that deserves to be an area-for-future-work. I > >consider both to be "congestion" that we are charged to "expose". > > > >-- > >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 From dave.mcdysan@verizon.com Mon Mar 28 08:28:18 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9486E3A6828 for ; Mon, 28 Mar 2011 08:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.51 X-Spam-Level: X-Spam-Status: No, score=-3.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83JgnFqCD5JZ for ; Mon, 28 Mar 2011 08:28:17 -0700 (PDT) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id 1907A3A67E4 for ; Mon, 28 Mar 2011 08:28:13 -0700 (PDT) Received: from fldsmtpi02.verizon.com (fldsmtpi02.verizon.com [166.68.71.144]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p2SFTZAZ008052 for ; Mon, 28 Mar 2011 11:29:40 -0400 (EDT) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.63,256,1299456000"; d="scan'208";a="19688507" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi02.verizon.com with ESMTP; 28 Mar 2011 15:29:35 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.173]) by FHDP1LUMXC7HB03.us.one.verizon.com ([2002:a644:3bbe::a644:3bbe]) with mapi; Mon, 28 Mar 2011 11:29:34 -0400 To: Mikael Abrahamsson , "conex@ietf.org" Date: Mon, 28 Mar 2011 11:29:32 -0400 Thread-Topic: [conex] Discussion of new Use Cases pt 1 - Shaper Definition Thread-Index: AcvtXPDikRPcxhNOTh2uu/WYmW2npw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [conex] Discussion of new Use Cases pt 1 - Shaper Definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 15:28:18 -0000 HI Mikael, A few responses in line below. Dave On Monday3/28/11 9:00 AM, "Mikael Abrahamsson" wrote: >On Mon, 28 Mar 2011, Mcdysan, David E wrote: > >> Shapers, as defined in RFC 2475, also known as "rate limiters" on a >> queue as described in Appendix B of DSL Forum TR-059 are used in many >> ISP networks. > >For me a "rate limiter" is a policer, not a shaper. I'd imagine most of >the ISP business would give you the exact same answer. The term rate limiter is not used often when referring to routers, and has the ambiguity of whether it is in fact a policer or a shaper as defined in RFC 2475. In L2 ATM DSLAMs, the term used in Appendix B of TR-059 is in fact rate limiter of a queue and IS NOT a policer (policers are called policers). > >> A shaper defines a virtual circuit peak bandwidth and burst duration >> type behavior for downstream and upstream customer access. This is easy >> for customers and connecion-oriented operators to understand and >> relatively easy to measure. > >A shaper emulates the behaviour of a port that is full and is doing >output=20 >queueing, but at any speed and in any direction. It can do WRED/ECN, just >like a port doing queueing. In routers this is true, in some L2 devices (e.g., DSLAMs) WRED/ECN is not done by a rate limiter on a queue. I think it may be helpful to define this distinction in the document. > >I think someone needs to define the terms in the document itself, >otherwise you'll get confusion as different organisations define these >terms differently. Agreed. Instead of a reference, the document should quote the relevant terms, mapping any choices between different names referring to the same thing to a single agreed name. From bob.briscoe@bt.com Mon Mar 28 10:35:34 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCF7D28B56A for ; Mon, 28 Mar 2011 10:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.452 X-Spam-Level: X-Spam-Status: No, score=-3.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+yMb-uvBYJA for ; Mon, 28 Mar 2011 10:35:33 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 8B93E3A6948 for ; Mon, 28 Mar 2011 10:35:33 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Mar 2011 18:37:10 +0100 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, 28 Mar 2011 18:37:09 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1301333829119; Mon, 28 Mar 2011 18:37:09 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.0.105]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p2SHb7QX001580; Mon, 28 Mar 2011 18:37:07 +0100 Message-Id: <201103281737.p2SHb7QX001580@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 28 Mar 2011 18:37:07 +0100 To: Mikael Abrahamsson , "Mcdysan, David E" From: Bob Briscoe In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 28 Mar 2011 17:37:09.0902 (UTC) FILETIME=[C3E632E0:01CBED6E] Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 - Shaper Definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 17:35:35 -0000 Mikael (& David), Are you in Prague? I'd like to find what you don't like/understand about what's written, wihch may be quicker f2f, if you are willing. I've been talking about these things to various of the audiences that Toby lists for a number of years now. I've learned to be careful about explaining what it's not, because most of the time the problem is that someone makes some jump in their own mind that isn't appropriate, but it's hard to stop people assuming things. Shifting to the subject of the thread, it's a congestion-rate limiter. There is absolutely no (= none, zero, nothing, zilch) bit-rate limiting needed for ConEx-capable traffic. The concept of a congestion-rate limiter is not defined in any RFCs, because it was impossible before ConEx exposed congestion so that a congestion-rate could be limited. Therefore we should only reference RFCs about policers in the negative. But my earlier point was: * the term shaper generally means smoothing inter-packet gaps, which requires adding delay to some packets (because you can't make time go backwards for the other packets). * the general term policer is about keeping traffic within a contract. So I added the word congestion to the word policer to define a new concept... The contract is a congestion-rate (and a congestion-volume burst), so I thought it's reasonable to call the thing a congestion-rate policer, (or congestion policer for short, but perhaps we should avoid shortening this?) Does this help? Bob At 16:29 28/03/2011, Mcdysan, David E wrote: >HI Mikael, > >A few responses in line below. > >Dave > >On Monday3/28/11 9:00 AM, "Mikael Abrahamsson" wrote: > > >On Mon, 28 Mar 2011, Mcdysan, David E wrote: > > > >> Shapers, as defined in RFC 2475, also known as "rate limiters" on a > >> queue as described in Appendix B of DSL Forum TR-059 are used in many > >> ISP networks. > > > >For me a "rate limiter" is a policer, not a shaper. I'd imagine most of > >the ISP business would give you the exact same answer. > >The term rate limiter is not used often when referring to routers, and has >the ambiguity of whether it is in fact a policer or a shaper as defined in >RFC 2475. In L2 ATM DSLAMs, the term used in Appendix B of TR-059 is in >fact rate limiter of a queue and IS NOT a policer (policers are called >policers). > > > > >> A shaper defines a virtual circuit peak bandwidth and burst duration > >> type behavior for downstream and upstream customer access. This is easy > >> for customers and connecion-oriented operators to understand and > >> relatively easy to measure. > > > >A shaper emulates the behaviour of a port that is full and is doing > >output > >queueing, but at any speed and in any direction. It can do WRED/ECN, just > >like a port doing queueing. > >In routers this is true, in some L2 devices (e.g., DSLAMs) WRED/ECN is not >done by a rate limiter on a queue. I think it may be helpful to define >this distinction in the document. > > > > >I think someone needs to define the terms in the document itself, > >otherwise you'll get confusion as different organisations define these > >terms differently. > >Agreed. Instead of a reference, the document should quote the relevant >terms, mapping any choices between different names referring to the same >thing to a single agreed name. > > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design From swmike@swm.pp.se Mon Mar 28 11:08:23 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776233A67D1 for ; Mon, 28 Mar 2011 11:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdfNI7A8ntOq for ; Mon, 28 Mar 2011 11:08:22 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 434523A67D6 for ; Mon, 28 Mar 2011 11:08:21 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CDCE19C; Mon, 28 Mar 2011 20:09:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CA80B9A; Mon, 28 Mar 2011 20:09:57 +0200 (CEST) Date: Mon, 28 Mar 2011 20:09:57 +0200 (CEST) From: Mikael Abrahamsson To: Bob Briscoe In-Reply-To: <201103281737.p2SHb7QX001580@bagheera.jungle.bt.co.uk> Message-ID: References: <201103281737.p2SHb7QX001580@bagheera.jungle.bt.co.uk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 - Shaper Definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 18:08:23 -0000 On Mon, 28 Mar 2011, Bob Briscoe wrote: > Are you in Prague? I'd like to find what you don't like/understand about > what's written, wihch may be quicker f2f, if you are willing. Nope, sorry, wasn't able to go. > I've been talking about these things to various of the audiences that Toby > lists for a number of years now. I've learned to be careful about explaining > what it's not, because most of the time the problem is that someone makes > some jump in their own mind that isn't appropriate, but it's hard to stop > people assuming things. I think someone needs to make a document that explains thing in a practical hands-on kind of way. Graphics would help. This talks about tokens, burst size, out of profile tokens etc. The policer acts on all packets according to a simple algorithm. It doesn't act on "flows". > The contract is a congestion-rate (and a congestion-volume burst), so I > thought it's reasonable to call the thing a congestion-rate policer, (or > congestion policer for short, but perhaps we should avoid shortening this?) > > Does this help? I think of a world in packets, queuing, packets being dropped or marked. If they are queued, dropped or in ECN case, marked, there is congestion. The draft-ietf-conex-concepts-uses talks about "CONEX policers" and "congestion volume" and "flows". I guess I just fail to see how this is actually implemented in a real world device and what it would do, and how this would scale. -- Mikael Abrahamsson email: swmike@swm.pp.se From dave.mcdysan@verizon.com Mon Mar 28 11:31:14 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F2E73A68E7 for ; Mon, 28 Mar 2011 11:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oY+Nm2w7PArk for ; Mon, 28 Mar 2011 11:31:13 -0700 (PDT) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id 4CB493A68E5 for ; Mon, 28 Mar 2011 11:31:13 -0700 (PDT) Received: from fldsmtpi03.verizon.com (fldsmtpi03.verizon.com [166.68.71.145]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p2SIWZnv025138 for ; Mon, 28 Mar 2011 14:32:40 -0400 (EDT) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.63,256,1299456000"; d="scan'208";a="19831131" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi03.verizon.com with ESMTP; 28 Mar 2011 18:32:35 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.173]) by FHDP1LUMXC7HB03.us.one.verizon.com ([2002:a644:3bbe::a644:3bbe]) with mapi; Mon, 28 Mar 2011 14:32:34 -0400 To: Bob Briscoe , Mikael Abrahamsson Date: Mon, 28 Mar 2011 14:32:32 -0400 Thread-Topic: [conex] Discussion of new Use Cases pt 1 - Shaper Definition Thread-Index: AcvtdoGCBuDxAS//QsqUKkB7ML6uwg== Message-ID: In-Reply-To: <201103281737.p2SHb7QX001580@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 - Shaper Definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 18:31:14 -0000 Bob, In my view "shaper" and "policer" and "rate limiter" are terms used to describe what exists and this text would be in Existing Approaches section of the use cases draft. What you are describing is a new concept with Conex, and this should probably be described in mechanisms with some high-level reference in use cases. The [Policing Freedom] reference is currently given in both drafts and I recommend that to Mikael and others wanting to better understand this new approach. The terminology in that paper seemed clear enough to me, and I suggest using those instead of creating new terms as you have at the end of your post below. (There are some inconsistencies in the current drafts use of terminology that would need to be made to do this). I think that section 5 of the use cases draft would be a good place to summarize how the new approaches solve problems with the existing approaches.=20 A few questions, responses in line below. I would like to meet f2f to see if we can agree on how to describe this better and also better describe the potential benefit of the abstract mechanism. Thanks, Dave On Monday3/28/11 1:37 PM, "Bob Briscoe" wrote: >Mikael (& David), > >Are you in Prague? I'd like to find what you don't like/understand >about what's written, wihch may be quicker f2f, if you are willing. > >I've been talking about these things to various of the audiences that >Toby lists for a number of years now. I've learned to be careful >about explaining what it's not, because most of the time the problem >is that someone makes some jump in their own mind that isn't >appropriate, but it's hard to stop people assuming things. > >Shifting to the subject of the thread, it's a congestion-rate >limiter. There is absolutely no (=3D none, zero, nothing, zilch) >bit-rate limiting needed for ConEx-capable traffic. For the case described in [Policing Freedom] this is true. But if an ISP still wants to sell service based upon bandwidth tiers, then an "Existing Approach Shaper" may still be needed, and the action of this "Existing Approach Shaper" could create loss and/or ECN marking, which after thinking about this more should work. > >The concept of a congestion-rate limiter is not defined in any RFCs, >because it was impossible before ConEx exposed congestion so that a >congestion-rate could be limited. Therefore we should only reference >RFCs about policers in the negative. Negative means existing approach? That is, conex eliminates the need for them? > >But my earlier point was: >* the term shaper generally means smoothing inter-packet gaps, which >requires adding delay to some packets (because you can't make time go >backwards for the other packets). >* the general term policer is about keeping traffic within a contract. These describe certain aspects of how these are used in existing approaches. > >So I added the word congestion to the word policer to define a new >concept... > >The contract is a congestion-rate (and a congestion-volume burst), so >I thought it's reasonable to call the thing a congestion-rate >policer, (or congestion policer for short, but perhaps we should >avoid shortening this?) Suggest using terminology from [Policing Freedom]. > >Does this help? > > >Bob > >At 16:29 28/03/2011, Mcdysan, David E wrote: >>HI Mikael, >> >>A few responses in line below. >> >>Dave >> >>On Monday3/28/11 9:00 AM, "Mikael Abrahamsson" wrote: >> >> >On Mon, 28 Mar 2011, Mcdysan, David E wrote: >> > >> >> Shapers, as defined in RFC 2475, also known as "rate limiters" on a >> >> queue as described in Appendix B of DSL Forum TR-059 are used in many >> >> ISP networks. >> > >> >For me a "rate limiter" is a policer, not a shaper. I'd imagine most of >> >the ISP business would give you the exact same answer. >> >>The term rate limiter is not used often when referring to routers, and >>has >>the ambiguity of whether it is in fact a policer or a shaper as defined >>in >>RFC 2475. In L2 ATM DSLAMs, the term used in Appendix B of TR-059 is in >>fact rate limiter of a queue and IS NOT a policer (policers are called >>policers). >> >> > >> >> A shaper defines a virtual circuit peak bandwidth and burst duration >> >> type behavior for downstream and upstream customer access. This is >>easy >> >> for customers and connecion-oriented operators to understand and >> >> relatively easy to measure. >> > >> >A shaper emulates the behaviour of a port that is full and is doing >> >output >> >queueing, but at any speed and in any direction. It can do WRED/ECN, >>just >> >like a port doing queueing. >> >>In routers this is true, in some L2 devices (e.g., DSLAMs) WRED/ECN is >>not >>done by a rate limiter on a queue. I think it may be helpful to define >>this distinction in the document. >> >> > >> >I think someone needs to define the terms in the document itself, >> >otherwise you'll get confusion as different organisations define these >> >terms differently. >> >>Agreed. Instead of a reference, the document should quote the relevant >>terms, mapping any choices between different names referring to the same >>thing to a single agreed name. >> >> >>_______________________________________________ >>conex mailing list >>conex@ietf.org >>https://www.ietf.org/mailman/listinfo/conex > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design > From nanditad@google.com Mon Mar 28 12:10:11 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6F128C0D8 for ; Mon, 28 Mar 2011 12:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ce1Jjjo9cOW for ; Mon, 28 Mar 2011 12:10:10 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 82A863A686E for ; Mon, 28 Mar 2011 12:10:10 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p2SJBlmm024614 for ; Mon, 28 Mar 2011 12:11:47 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301339507; bh=WDlokphXzeZKilGnbTnJHfNp3rI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=NZvPs4tLzN7Ek/q/hHm8d7tAXLnmIy94wOJ/+vz6mQuhaPULXyBQxuEUna2Ud0TVf r0CZOspBD0xuN/IEbfM5g== Received: from yia28 (yia28.prod.google.com [10.243.65.28]) by hpaq12.eem.corp.google.com with ESMTP id p2SJBfEf007507 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 28 Mar 2011 12:11:45 -0700 Received: by yia28 with SMTP id 28so1259739yia.21 for ; Mon, 28 Mar 2011 12:11:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ih1GG9Tm09aNLIq1kUxgTgKW1jySnN3bL7LinYl6taU=; b=sRIO/l/OHo/XDMidEF4gjmjkMlJfpBqVoAHCT+QLt1vVlQ5b7v1z8jwIPb1FvdvBMj BOsnrTsJZkARcHSBN4sg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kSwUMq4nXrvrHL42RjuPrET25GNta6Kff7mqKgLOoI+984uGTKtMiFnAv3W8HXSqL0 TIw/pG8DfYalro09IB6g== MIME-Version: 1.0 Received: by 10.91.76.2 with SMTP id d2mr4195291agl.208.1301339504673; Mon, 28 Mar 2011 12:11:44 -0700 (PDT) Received: by 10.91.219.10 with HTTP; Mon, 28 Mar 2011 12:11:44 -0700 (PDT) In-Reply-To: <20110314230002.28547.97880.idtracker@localhost> References: <20110314230002.28547.97880.idtracker@localhost> Date: Mon, 28 Mar 2011 21:11:44 +0200 Message-ID: From: Nandita Dukkipati To: Matthew Mathis , Bob Briscoe Content-Type: multipart/alternative; boundary=0016e6464ea4e8828b049f8fb698 X-System-Of-Record: true Cc: conex@ietf.org Subject: Re: [conex] I-D ACTION:draft-ietf-conex-abstract-mech-01.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 19:10:12 -0000 --0016e6464ea4e8828b049f8fb698 Content-Type: text/plain; charset=ISO-8859-1 My comments on this draft are as an individual contributor. First of, nice draft! Overall reads well and the points being made are clear. A couple of high level questions and a few minor ones. 1) Of the three kinds of encoding schemes described (ECN based, independent bits, and codepoint), ultimately we have to go with one - which one would you recommend and why? What are the other factors external to this draft that the choice is dependent on? 2) The use of credit to simplify audit is a nice concept. While it makes audit easier, it does push the onus onto the hosts to build up sufficient credit. Any thoughts on how a transport may know in advance on how to build up credit prior to receiving any ECN signals? It's out of scope for this draft, but the TCP modifications draft needs to address this. [Clarification qs] 3) Sec. 2 - "For congestion signaled by ECN, auditing is most accurate when located near the transport receiver. Within any flow or aggregate of flows, the volume of data tagged with ConEx Signals should never be less than the total volume of ECN marked data seen near the receiver." This statement doesn't necessarily hold true in the presence of reverse congestion when ACKs may get lost. Correct? 4) Sec 3.3.2 Codepoint Encoding What's the purpose of ConEx-Not-Marked? Is there an equivalent of it with independent bits encoding? 5) Sec 4.3 Audit Is it fair to assume that Re-Echo-Loss signal is marked only on retransmitted packets? If not, what are the scenarios where non-retrans. packets can carry Re-Echo-Loss? 6) Sec. 1.1 Terminology What is the purpose of colors (Re-Echo-Loss aka Purple etc.)? I didn't see the use of them in rest of the draft. -Nandita On Mon, Mar 14, 2011 at 4:00 PM, wrote: > A new Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Congestion Exposure Working Group of the > IETF. > > Title : Congestion Exposure (ConEx) Concepts and Abstract > Mechanism > > Author(s) : M. Mathis, et al > Filename : draft-ietf-conex-abstract-mech-01.txt > Pages : 18 > Date : 2011-03-14 > > This document describes an abstract mechanism by which senders inform > the network about the congestion encountered by packets earlier in > the same flow. Today, the network may signal congestion to the > receiver by ECN markings or by dropping packets, and the receiver > passes this information back to the sender in transport-layer > feedback. The mechanism to be developed by the ConEx WG will enable > the sender to also relay this congestion information back into the > network in-band at the IP layer, such that the total level of > congestion is visible to all IP devices along the path, from where it > could, for example, provide input to traffic management. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-conex-abstract-mech-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex > > --0016e6464ea4e8828b049f8fb698 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
My comments on this draft are as an individual contributor.
=
First of, nice draft! Overall reads well and the points bein= g made are clear. A couple of high level questions and a few minor ones.

1) Of the three kinds of encoding schemes described (EC= N based, independent bits, and codepoint), ultimately we have to go with on= e - which one would you recommend and why? What are the other factors exter= nal to this draft that the choice is dependent on?

2) The use of credit to simplify audit is a nice concep= t. While it makes audit easier, it does push the onus onto the hosts to bui= ld up sufficient credit. Any thoughts on how a transport may know in advanc= e on how to build up credit prior to receiving any ECN signals? It's ou= t of scope for this draft, but the TCP modifications draft needs to address= this.

[Clarification qs]
3) Sec. 2 -=A0"For co= ngestion signaled by ECN, auditing is most accurate when located near the t= ransport receiver. =A0Within any flow or aggregate of flows, the volume of = data tagged with ConEx Signals should never be less than the total volume o= f ECN marked data seen near the receiver."
This statement doesn't necessarily hold true in the presence of re= verse congestion when ACKs may get lost. Correct?

= 4) Sec 3.3.2 Codepoint Encoding
What's the purpose of ConEx-N= ot-Marked? Is there an equivalent of it with independent bits encoding?

5) Sec 4.3 Audit
Is it fair to assume that Re= -Echo-Loss signal is marked only on retransmitted packets? If not, what are= the scenarios where non-retrans. packets can carry Re-Echo-Loss?

6) Sec. 1.1 Terminology
What is the purpose o= f colors (Re-Echo-Loss aka Purple etc.)? I didn't see the use of them i= n rest of the draft.

-Nandita

On Mon, Mar 14, 2011 at 4:00 PM, <Internet-Drafts@ietf.or= g> wrote:
A new Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Congestion Exposure Working Group of the I= ETF.

=A0 =A0Title =A0 =A0 =A0 =A0 : Congestion Exposure (ConEx) Concepts and Ab= stract Mechanism

=A0 =A0Author(s) =A0 =A0 : M. Mathis, et al
=A0 =A0Filename =A0 =A0 =A0: draft-ietf-conex-abstract-mech-01.txt
=A0 =A0Pages =A0 =A0 =A0 =A0 : 18
=A0 =A0Date =A0 =A0 =A0 =A0 =A0: 2011-03-14

This document describes an abstract mechanism by which senders inform
=A0 the network about the congestion encountered by packets earlier in
=A0 the same flow. =A0Today, the network may signal congestion to the
=A0 receiver by ECN markings or by dropping packets, and the receiver
=A0 passes this information back to the sender in transport-layer
=A0 feedback. =A0The mechanism to be developed by the ConEx WG will enable=
=A0 the sender to also relay this congestion information back into the
=A0 network in-band at the IP layer, such that the total level of
=A0 congestion is visible to all IP devices along the path, from where it<= br> =A0 could, for example, provide input to traffic management.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf= -conex-abstract-mech-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


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


--0016e6464ea4e8828b049f8fb698-- From bob.briscoe@bt.com Mon Mar 28 15:08:52 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD6D73A6A84 for ; Mon, 28 Mar 2011 15:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.456 X-Spam-Level: X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Z7s5FWUIdSJ for ; Mon, 28 Mar 2011 15:08:51 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 556593A679F for ; Mon, 28 Mar 2011 15:08:51 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Mar 2011 23:10:27 +0100 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, 28 Mar 2011 23:10:28 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1301350226499; Mon, 28 Mar 2011 23:10:26 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.192.60]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p2SMAL0a003959; Mon, 28 Mar 2011 23:10:25 +0100 Message-Id: <201103282210.p2SMAL0a003959@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 28 Mar 2011 23:10:22 +0100 To: Mikael Abrahamsson From: Bob Briscoe In-Reply-To: References: <201103281737.p2SHb7QX001580@bagheera.jungle.bt.co.uk> 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: 28 Mar 2011 22:10:28.0040 (UTC) FILETIME=[F1F37C80:01CBED94] Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 - Shaper Definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 22:08:53 -0000 Mikael, At 19:09 28/03/2011, Mikael Abrahamsson wrote: >On Mon, 28 Mar 2011, Bob Briscoe wrote: > >>Are you in Prague? I'd like to find what you don't like/understand >>about what's written, wihch may be quicker f2f, if you are willing. > >Nope, sorry, wasn't able to go. > >>I've been talking about these things to various of the audiences >>that Toby lists for a number of years now. I've learned to be >>careful about explaining what it's not, because most of the time >>the problem is that someone makes some jump in their own mind that >>isn't appropriate, but it's hard to stop people assuming things. > >I think someone needs to make a document that explains thing in a >practical hands-on kind of way. Graphics would help. Try this - I have found this paper best describes the idea to someone familiar with existing traffic management techniques: Policing Freedom to Use the Internet Resource Pool However, it was written pre-ConEx. The big difference is that document only focused on using ECN, not loss on the first of the three passes around the feedback loop. ConEx now aims to work with either loss or ECN. We're going to have to invest the time in doing more ASCII art. Bob > > >This talks about tokens, burst size, out of profile tokens etc. The >policer acts on all packets according to a simple algorithm. It >doesn't act on "flows". > >>The contract is a congestion-rate (and a congestion-volume burst), >>so I thought it's reasonable to call the thing a congestion-rate >>policer, (or congestion policer for short, but perhaps we should >>avoid shortening this?) >> >>Does this help? > >I think of a world in packets, queuing, packets being dropped or >marked. If they are queued, dropped or in ECN case, marked, there is >congestion. > >The draft-ietf-conex-concepts-uses talks about "CONEX policers" and >"congestion volume" and "flows". I guess I just fail to see how this >is actually implemented in a real world device and what it would do, >and how this would scale. > >-- >Mikael Abrahamsson email: swmike@swm.pp.se ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Mon Mar 28 15:11:00 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6E683A6A8C for ; Mon, 28 Mar 2011 15:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9O6xQdmnXynb for ; Mon, 28 Mar 2011 15:10:58 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 659C03A6A85 for ; Mon, 28 Mar 2011 15:10:56 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Mar 2011 23:12:33 +0100 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, 28 Mar 2011 23:12:33 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1301350352555; Mon, 28 Mar 2011 23:12:32 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.192.60]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p2SMCVMr004001; Mon, 28 Mar 2011 23:12:31 +0100 Message-Id: <201103282212.p2SMCVMr004001@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 28 Mar 2011 23:12:32 +0100 To: Mikael Abrahamsson From: Bob Briscoe In-Reply-To: References: <20110226145616.GH7663@verdi> <20110303203456.GB89966@verdi> <201103281143.p2SBhcLe030524@bagheera.jungle.bt.co.uk> 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: 28 Mar 2011 22:12:33.0903 (UTC) FILETIME=[3CF8A7F0:01CBED95] Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 22:11:01 -0000 Mikael, At 12:51 28/03/2011, Mikael Abrahamsson wrote: >On Mon, 28 Mar 2011, Bob Briscoe wrote: > >>There's no room for debate here IMO - a policer adding ECN markings >>is just plain stupid. If someone isn't responding sufficiently to >>ECN markings, adding more ECN markings is never going to be used by >>a sentient network operator to punish them. > >I don't agree with this at all. See my comment at the end - I believe that the reason you disagree with this is because *you* are reading and using the term 'policing' inappropriately. Unless you can quote an authoritative source for using the term policing in this sense, please re-adjust your dictionary. >Let's take the case with a router/switch with small buffers. I don't >see the huge difference in having a policer doing ECN markings at >95% of wirespeed and then letting the small buffer taildrop at 3-5ms >of buffering, compared to something that has 50ms of buffering and >using RED starts doing ECN markings/RED after 5ms of buffers fill. This is AQM. There's nothing wrong with what you're saying, it's just very little to do with ConEx. Looking again at the ConEx docs (particularly conex-abstract-mech) I can see the problem: We omit to say that one basic idea of ConEx is that all the forwarding nodes (L2 & L3) do nothing more than FIFO forwarding preferably with AQM and possibly ECN marking. But none of that is policing. Each forwarding node alone has insufficient information to determine whether a particular site is keeping to contract or not. So they don't do any policing (meaning keeping traffic to a contract). Instead, with ConEx, congestion-rate policing is done at one node that all a customer's traffic passes through (or in multi-homed cases one logically single policing node), preferably near the ingress edge. Much like the ingress to the 2475 Diffserv architecture. But unlike Diffserv, each interior forwarding node does no policing whatsoever - nothing, zilch, zero, null, none. Already, in the existing Internet architecture, through e2e transport feedback the source sees information about congestion (loss or ECN) from all the forwarding nodes its traffic is going through, everywhere it passes in the whole Internet. The idea of ConEx is for all the sources within a site to expose this information back to the network, so that the policing node at the ingress where the site attaches can limit the congestion this site as a whole contributes to the Internet. The site might be a campus, or a home network, or just a tenant on one blade in a data centre. This ingress policing node uses information from ConEx, which has come round the feedback loop and back into the front of the network via the sender. It doesn't police based on its local congestion, it polices based on all the congestion it is told about by the source. I can see we need to say a lot more about what ConEx is NOT. >>2/ Can we stop calling the policer a shaper please? >>Shaping is theoretically one action a policer might take, but it's >>one that causes more confusion and arguments because it's so weak. > >A policer NEVER ever shapes. Shaping is the delaying/buffering of >packets. A policer is something that has buckets and either drops, >marks and/or transmits packets, never ever delays them. Exactly - people in this wg keep using the term shaping where it's not applicable, and it's just confusing everyone. >>Shaping is something some operators still do to make a packet >>network look like a phone network in the belief it will improve >>things, when it merely adds delay deterministically that might >>otherwise not be added statistically. Like ECN, it's not really a >>useful tool in the punishment armory. A thing that punishes out of >>contract behaviour is called a policer. Let's stop using confusing terms. > >It seems we need a discussion on the basic terms people use to >describe behaviour. I think actually you are incorrectly stretching the term 'policing' above in you ECN marking at 95% wirespeed. No-one else calls that policing. When a node polices to a rate, it drops packets above that rate (possibly with a burst allowance). If it ECN marks above a rate, that is AQM or it might be called metering and marking, but not policing. You are describing metering & marking for pre-congestion notification (RFC5696). Does this help? Bob >-- >Mikael Abrahamsson email: swmike@swm.pp.se ________________________________________________________________ Bob Briscoe, BT Innovate & Design From menth@informatik.uni-tuebingen.de Mon Mar 28 15:34:30 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0F2F3A6A2B for ; Mon, 28 Mar 2011 15:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgbKe2bRpmlE for ; Mon, 28 Mar 2011 15:34:28 -0700 (PDT) Received: from mx3.informatik.uni-tuebingen.de (mx3.Informatik.Uni-Tuebingen.De [134.2.12.26]) by core3.amsl.com (Postfix) with SMTP id 14C1E3A6970 for ; Mon, 28 Mar 2011 15:34:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id C0BAA52C2; Tue, 29 Mar 2011 00:36:02 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx3.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx3.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZFBXjjj9eWu; Tue, 29 Mar 2011 00:36:00 +0200 (MEST) Received: from zcs-pu.informatik.uni-tuebingen.de (zcs-pu.Informatik.Uni-Tuebingen.De [134.2.12.61]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 7436B52A6; Tue, 29 Mar 2011 00:36:00 +0200 (MEST) Received: from [192.168.2.92] (unknown [88.208.109.142]) by zcs-pu.informatik.uni-tuebingen.de (Postfix) with ESMTP id 08E02F36B9A; Tue, 29 Mar 2011 00:35:59 +0200 (CEST) Message-ID: <4D910D4A.107@informatik.uni-tuebingen.de> Date: Tue, 29 Mar 2011 00:35:54 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Bob Briscoe References: <201103281737.p2SHb7QX001580@bagheera.jungle.bt.co.uk> In-Reply-To: <201103281737.p2SHb7QX001580@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 - Shaper Definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 22:34:30 -0000 Hi Bob, Mikael, Dave, Policer: makes flow compliant to some profile by dropping packets. Shaper: makes flow clompliant to some profile by delaying packets to some extent, dropping starts only if the delaying buffer overflows. Do you agree? With conex, a flow must be compliant to the "congestion-profile" defined by the "congestion allowance". Using the above definitions suggests that the "conex-policer" may be implemented either as policer or as shaper. Why do we always talk only about a conex-policer? Why is delaying packets not an option? I think the traffic leaving the "conex-policer" must just be compliant to the "congestion-profile. Best wishes, Michael -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From bob.briscoe@bt.com Mon Mar 28 16:27:56 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2AF93A6960 for ; Mon, 28 Mar 2011 16:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.462 X-Spam-Level: X-Spam-Status: No, score=-3.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lfO-sq1bBVI for ; Mon, 28 Mar 2011 16:27:55 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 77B053A679F for ; Mon, 28 Mar 2011 16:27:53 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Mar 2011 00:29:30 +0100 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, 29 Mar 2011 00:29:30 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1301354969383; Tue, 29 Mar 2011 00:29:29 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.192.60]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p2SNTSap004606; Tue, 29 Mar 2011 00:29:28 +0100 Message-Id: <201103282329.p2SNTSap004606@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 29 Mar 2011 00:29:28 +0100 To: Michael Menth From: Bob Briscoe In-Reply-To: <4D910D4A.107@informatik.uni-tuebingen.de> References: <201103281737.p2SHb7QX001580@bagheera.jungle.bt.co.uk> <4D910D4A.107@informatik.uni-tuebingen.de> 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: 28 Mar 2011 23:29:30.0516 (UTC) FILETIME=[FCAFE540:01CBED9F] Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 - Shaper Definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 23:27:56 -0000 Michael, At 23:35 28/03/2011, Michael Menth wrote: >Hi Bob, Mikael, Dave, > >Policer: makes flow compliant to some profile by dropping packets. >Shaper: makes flow clompliant to some profile by delaying packets to >some extent, dropping starts only if the delaying buffer overflows. > >Do you agree? Yes. >With conex, a flow must be compliant to the "congestion-profile" >defined by the "congestion allowance". > >Using the above definitions suggests that the "conex-policer" may be >implemented either as policer or as shaper. Why do we always talk >only about a conex-policer? Why is delaying packets not an option? I >think the traffic leaving the "conex-policer" must just be compliant >to the "congestion-profile. It is *theoretically* possible to shape traffic to keep it to a congestion profile, but it would require such huge amounts of delay that would make it unworkable. This is mostly because congestion is signalled as a unary encoding (some packets marked, some not). So the congestion rate is only measurable on occasional packets. SO if you tried to shape this, you would have to hold back thousands of packets waiting for a token to release a marked packet and the other unmarked packets stacked behind it. Bob >Best wishes, > > Michael > >-- >Prof. Dr. habil. Michael Menth >University of Tuebingen >Faculty of Science >Department of Computer Science >Chair of Communication Networks >Sand 13, 72076 Tuebingen, Germany >phone: (+49)-7071/29-70505 >fax: (+49)-7071/29-5220 >mailto:menth@uni-tuebingen.de >http://www-kn.informatik.uni-tuebingen.de ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Mon Mar 28 17:29:33 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22D1F3A6A90 for ; Mon, 28 Mar 2011 17:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UVbsTvg42LV for ; Mon, 28 Mar 2011 17:29:31 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id E87A93A6A89 for ; Mon, 28 Mar 2011 17:29:30 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Mar 2011 01:31:07 +0100 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, 29 Mar 2011 01:31:07 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1301358665960; Tue, 29 Mar 2011 01:31:05 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.192.60]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p2T0V14I005082; Tue, 29 Mar 2011 01:31:04 +0100 Message-Id: <201103290031.p2T0V14I005082@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 29 Mar 2011 01:31:00 +0100 To: Nandita Dukkipati From: Bob Briscoe In-Reply-To: References: <20110314230002.28547.97880.idtracker@localhost> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_152204949==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 29 Mar 2011 00:31:07.0572 (UTC) FILETIME=[984DDF40:01CBEDA8] Cc: conex@ietf.org Subject: Re: [conex] I-D ACTION:draft-ietf-conex-abstract-mech-01.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 00:29:33 -0000 --=====================_152204949==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Nandita, At 20:11 28/03/2011, Nandita Dukkipati wrote: >My comments on this draft are as an individual contributor. > >First of, nice draft! Overall reads well and the points being made >are clear. A couple of high level questions and a few minor ones. Mikael's comments make me realise though that we still have to be a lot clearer about what ConEx is not. Also, I've recently read RFC4301 Writing Protocol Models, which we ought to try to follow - it has good advice for writing protocol drafts, especially this abstract one ought to follow it. And I think it would help to put the policy function & audit function in a second figure that is otherwise similar to the first (which we do when presenting slides). >1) Of the three kinds of encoding schemes described (ECN based, >independent bits, and codepoint), ultimately we have to go with one >- which one would you recommend and why? What are the other factors >external to this draft that the choice is dependent on? This is intended to remain open while encoding issues are discussed. I would say - independent bits is overkill - Codepoint is sufficient, and - ECN is last resort if we only have one bit. I guess we could say that (if Matt agrees). >2) The use of credit to simplify audit is a nice concept. While it >makes audit easier, it does push the onus onto the hosts to build up >sufficient credit. Any thoughts on how a transport may know in >advance on how to build up credit prior to receiving any ECN >signals? It's out of scope for this draft, but the TCP modifications >draft needs to address this. My thesis has loads of simulation expts on this. I plan to publish it by May'11 (I have to by Uni regulations). Mirja has also reported on her expts (first ConEx mtg I think). The idea is that it depends how well other parts of the code avoid overshoot at the end of slow-start. For instance, the latest Linux does packet-pair on each pair of packets released by each ack during slow-start, and gets a good estimate of where ssthresh should start this way. >[Clarification qs] >3) Sec. 2 - "For congestion signaled by ECN, auditing is most >accurate when located near the transport receiver. Within any flow >or aggregate of flows, the volume of data tagged with ConEx Signals >should never be less than the total volume of ECN marked data seen >near the receiver." >This statement doesn't necessarily hold true in the presence of >reverse congestion when ACKs may get lost. Correct? If working with an unmodified recvr, I agree. However, the scheme for modifying TCP's ECN feedback (in re-ECN, which I believe Mirja is going to put in the ConEx TCP draft) maintains a correct count robust to ack loss (at least once you get an ack again after a loss). >4) Sec 3.3.2 Codepoint Encoding >What's the purpose of ConEx-Not-Marked? Is there an equivalent of it >with independent bits encoding? It means ConEx is supported, but nothing is being re-echoed. The need to distinguish ConEx from non-ConEx packets is motivated at the start. Relative to independent bits, it's equivalent to 'ConEx' with all the other flags off (Not-*). >5) Sec 4.3 Audit >Is it fair to assume that Re-Echo-Loss signal is marked only on >retransmitted packets? If not, what are the scenarios where >non-retrans. packets can carry Re-Echo-Loss? If TCP or a reliable transport, former is correct. But ConEx is for any transport. In the detailed TCP spec, we will need to say what the sender does in response to a ConEx marked packet being dropped etc. (one of Georgios's points). >6) Sec. 1.1 Terminology >What is the purpose of colors (Re-Echo-Loss aka Purple etc.)? I >didn't see the use of them in rest of the draft. They tend to get used a lot when explaining ConEx, so we thought it best to put them in here, even though we don't use them ourselves. Black, Red, Green & Grey have fairly intuitive meanings (at least for me from a western culture) of Credit, debit, start and neutral. Purple was an attempt to find a colour that hadn't already been used and that was close to black. HTH Bob >-Nandita > >On Mon, Mar 14, 2011 at 4:00 PM, ><Internet-Drafts@ietf.org> wrote: >A new Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Congestion Exposure Working Group >of the IETF. > > Title : Congestion Exposure (ConEx) Concepts and > Abstract Mechanism > > Author(s) : M. Mathis, et al > Filename : draft-ietf-conex-abstract-mech-01.txt > Pages : 18 > Date : 2011-03-14 > >This document describes an abstract mechanism by which senders inform > the network about the congestion encountered by packets earlier in > the same flow. Today, the network may signal congestion to the > receiver by ECN markings or by dropping packets, and the receiver > passes this information back to the sender in transport-layer > feedback. The mechanism to be developed by the ConEx WG will enable > the sender to also relay this congestion information back into the > network in-band at the IP layer, such that the total level of > congestion is visible to all IP devices along the path, from where it > could, for example, provide input to traffic management. > > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-conex-abstract-mech-01.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex > ________________________________________________________________ Bob Briscoe, BT Innovate & Design --=====================_152204949==.ALT Content-Type: text/html; charset="us-ascii" Nandita,

At 20:11 28/03/2011, Nandita Dukkipati wrote:
My comments on this draft are as an individual contributor.

First of, nice draft! Overall reads well and the points being made are clear. A couple of high level questions and a few minor ones.

Mikael's comments make me realise though that we still have to be a lot clearer about what ConEx is not.

Also, I've recently read RFC4301 Writing Protocol Models, which we ought to try to follow - it has good advice for writing protocol drafts, especially this abstract one ought to follow it.

And I think it would help to put the policy function & audit function in a second figure that is otherwise similar to the first (which we do when presenting slides).


1) Of the three kinds of encoding schemes described (ECN based, independent bits, and codepoint), ultimately we have to go with one - which one would you recommend and why? What are the other factors external to this draft that the choice is dependent on?

This is intended to remain open while encoding issues are discussed.

I would say
- independent bits is overkill
- Codepoint is sufficient, and
- ECN is last resort if we only have one bit.
I guess we could say that (if Matt agrees).


2) The use of credit to simplify audit is a nice concept. While it makes audit easier, it does push the onus onto the hosts to build up sufficient credit. Any thoughts on how a transport may know in advance on how to build up credit prior to receiving any ECN signals? It's out of scope for this draft, but the TCP modifications draft needs to address this.

My thesis has loads of simulation expts on this. I plan to publish it by May'11 (I have to by Uni regulations). Mirja has also reported on her expts (first ConEx mtg I think).

The idea is that it depends how well other parts of the code avoid overshoot at the end of slow-start. For instance, the latest Linux does packet-pair on each pair of packets released by each ack during slow-start, and gets a good estimate of where ssthresh should start this way.


[Clarification qs]
3) Sec. 2 - "For congestion signaled by ECN, auditing is most accurate when located near the transport receiver.  Within any flow or aggregate of flows, the volume of data tagged with ConEx Signals should never be less than the total volume of ECN marked data seen near the receiver."
This statement doesn't necessarily hold true in the presence of reverse congestion when ACKs may get lost. Correct?

If working with an unmodified recvr, I agree.

However, the scheme for modifying TCP's ECN feedback (in re-ECN, which I believe Mirja is going to put in the ConEx TCP draft) maintains a correct count robust to ack loss (at least once you get an ack again after a loss).


4) Sec 3.3.2 Codepoint Encoding
What's the purpose of ConEx-Not-Marked? Is there an equivalent of it with independent bits encoding?

It means ConEx is supported, but nothing is being re-echoed. The need to distinguish ConEx from non-ConEx packets is motivated at the start.

Relative to independent bits, it's equivalent to 'ConEx' with all the other flags off (Not-*).


5) Sec 4.3 Audit
Is it fair to assume that Re-Echo-Loss signal is marked only on retransmitted packets? If not, what are the scenarios where non-retrans. packets can carry Re-Echo-Loss?

If TCP or a reliable transport, former is correct.
But ConEx is for any transport.

In the detailed TCP spec, we will need to say what the sender does in response to a ConEx marked packet being dropped etc. (one of Georgios's points).


6) Sec. 1.1 Terminology
What is the purpose of colors (Re-Echo-Loss aka Purple etc.)? I didn't see the use of them in rest of the draft.

They tend to get used a lot when explaining ConEx, so we thought it best to put them in here, even though we don't use them ourselves.

Black, Red, Green & Grey have fairly intuitive meanings (at least for me from a western culture) of Credit, debit, start and neutral.

Purple was an attempt to find a colour that hadn't already been used and that was close to black.

HTH


Bob


-Nandita

On Mon, Mar 14, 2011 at 4:00 PM, <Internet-Drafts@ietf.org > wrote:
A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Congestion Exposure Working Group of the IETF.

   Title         : Congestion Exposure (ConEx) Concepts and Abstract Mechanism

   Author(s)     : M. Mathis, et al
   Filename      : draft-ietf-conex-abstract-mech-01.txt
   Pages         : 18
   Date          : 2011-03-14

This document describes an abstract mechanism by which senders inform
  the network about the congestion encountered by packets earlier in
  the same flow.  Today, the network may signal congestion to the
  receiver by ECN markings or by dropping packets, and the receiver
  passes this information back to the sender in transport-layer
  feedback.  The mechanism to be developed by the ConEx WG will enable
  the sender to also relay this congestion information back into the
  network in-band at the IP layer, such that the total level of
  congestion is visible to all IP devices along the path, from where it
  could, for example, provide input to traffic management.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-conex-abstract-mech-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


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

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design --=====================_152204949==.ALT-- From swmike@swm.pp.se Mon Mar 28 20:24:33 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 049B53A68F6 for ; Mon, 28 Mar 2011 20:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQd659XtlNUt for ; Mon, 28 Mar 2011 20:24:32 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id CB3EA3A67A7 for ; Mon, 28 Mar 2011 20:24:31 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id DD8B09C; Tue, 29 Mar 2011 05:26:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D824E9A; Tue, 29 Mar 2011 05:26:06 +0200 (CEST) Date: Tue, 29 Mar 2011 05:26:06 +0200 (CEST) From: Mikael Abrahamsson To: Bob Briscoe In-Reply-To: <201103282212.p2SMCVMr004001@bagheera.jungle.bt.co.uk> Message-ID: References: <20110226145616.GH7663@verdi> <20110303203456.GB89966@verdi> <201103281143.p2SBhcLe030524@bagheera.jungle.bt.co.uk> <201103282212.p2SMCVMr004001@bagheera.jungle.bt.co.uk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 03:24:33 -0000 On Mon, 28 Mar 2011, Bob Briscoe wrote: > Mikael, > > At 12:51 28/03/2011, Mikael Abrahamsson wrote: >> On Mon, 28 Mar 2011, Bob Briscoe wrote: >> >>> There's no room for debate here IMO - a policer adding ECN markings is >>> just plain stupid. If someone isn't responding sufficiently to ECN >>> markings, adding more ECN markings is never going to be used by a sentient >>> network operator to punish them. >> >> I don't agree with this at all. > > See my comment at the end - I believe that the reason you disagree with this > is because *you* are reading and using the term 'policing' inappropriately. > Unless you can quote an authoritative source for using the term policing in > this sense, please re-adjust your dictionary. See the cisco document I referred to earlier. I don't know if you think this is authoritative or not, but they have 40% of the market so they have considerable influence on the terms people use. But I'll wait for next iteration of documents, because from reading so far I still don't understand what does what and how, in the proposed CONEX world. -- Mikael Abrahamsson email: swmike@swm.pp.se From menth@informatik.uni-tuebingen.de Mon Mar 28 23:12:58 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDEC93A6ABF for ; Mon, 28 Mar 2011 23:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEwfTFOSRi2G for ; Mon, 28 Mar 2011 23:12:57 -0700 (PDT) Received: from mx3.informatik.uni-tuebingen.de (mx3.Informatik.Uni-Tuebingen.De [134.2.12.26]) by core3.amsl.com (Postfix) with SMTP id DEF4C3A6AB3 for ; Mon, 28 Mar 2011 23:12:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id D5AF652C2; Tue, 29 Mar 2011 08:14:33 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx3.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx3.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqNrsOhL+EKg; Tue, 29 Mar 2011 08:14:30 +0200 (MEST) Received: from zcs-pu.informatik.uni-tuebingen.de (zcs-pu.Informatik.Uni-Tuebingen.De [134.2.12.61]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 26CFC52B0; Tue, 29 Mar 2011 08:14:30 +0200 (MEST) Received: from [192.168.1.142] (unknown [88.208.109.142]) by zcs-pu.informatik.uni-tuebingen.de (Postfix) with ESMTP id E2CD8F39461; Tue, 29 Mar 2011 08:14:29 +0200 (CEST) Message-ID: <4D9178C5.20004@informatik.uni-tuebingen.de> Date: Tue, 29 Mar 2011 08:14:29 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Bob Briscoe References: <201103281737.p2SHb7QX001580@bagheera.jungle.bt.co.uk> <4D910D4A.107@informatik.uni-tuebingen.de> <201103282329.p2SNTSap004606@bagheera.jungle.bt.co.uk> In-Reply-To: <201103282329.p2SNTSap004606@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 - Shaper Definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 06:12:58 -0000 Hi Bob, Am 29.03.2011 01:29, schrieb Bob Briscoe: > Michael, > > > At 23:35 28/03/2011, Michael Menth wrote: >> Hi Bob, Mikael, Dave, >> >> Policer: makes flow compliant to some profile by dropping packets. >> Shaper: makes flow clompliant to some profile by delaying packets to >> some extent, dropping starts only if the delaying buffer overflows. >> >> Do you agree? > > Yes. > > > >> With conex, a flow must be compliant to the "congestion-profile" >> defined by the "congestion allowance". >> >> Using the above definitions suggests that the "conex-policer" may be >> implemented either as policer or as shaper. Why do we always talk >> only about a conex-policer? Why is delaying packets not an option? I >> think the traffic leaving the "conex-policer" must just be compliant >> to the "congestion-profile. > > It is *theoretically* possible to shape traffic to keep it to a > congestion profile, but it would require such huge amounts of delay > that would make it unworkable. This is mostly because congestion is > signalled as a unary encoding (some packets marked, some not). So the > congestion rate is only measurable on occasional packets. SO if you > tried to shape this, you would have to hold back thousands of packets > waiting for a token to release a marked packet and the other unmarked > packets stacked behind it. Yes that's true. Shaping in this case can even create bursty traffic which is possibly not a good idea. But still, most important is that a conditioner enforces the "congestion profile". If sticking to the mere policer, a hint should be added why the conditioner must drop packets but cannot delay them. That improves clarity and underlines the behavior of the policer. Best wishes, Michael > > > > Bob > > >> Best wishes, >> >> Michael >> >> -- >> Prof. Dr. habil. Michael Menth >> University of Tuebingen >> Faculty of Science >> Department of Computer Science >> Chair of Communication Networks >> Sand 13, 72076 Tuebingen, Germany >> phone: (+49)-7071/29-70505 >> fax: (+49)-7071/29-5220 >> mailto:menth@uni-tuebingen.de >> http://www-kn.informatik.uni-tuebingen.de > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From john@jlc.net Tue Mar 29 03:23:17 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 353983A693E for ; Tue, 29 Mar 2011 03:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.486 X-Spam-Level: X-Spam-Status: No, score=-106.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpAw17kRz0Rb for ; Tue, 29 Mar 2011 03:23:15 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 8CA5B3A6930 for ; Tue, 29 Mar 2011 03:23:15 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 4A8F533C23; Tue, 29 Mar 2011 06:24:53 -0400 (EDT) Date: Tue, 29 Mar 2011 06:24:53 -0400 From: John Leslie To: Mikael Abrahamsson Message-ID: <20110329102453.GB20866@verdi> References: 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.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 - Shaper Definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 10:23:17 -0000 Mikael Abrahamsson wrote: > On Mon, 28 Mar 2011, Mcdysan, David E wrote: > >> Shapers, as defined in RFC 2475, also known as "rate limiters" on a >> queue as described in Appendix B of DSL Forum TR-059 are used in many >> ISP networks. > > For me a "rate limiter" is a policer, not a shaper. I'd imagine most of > the ISP business would give you the exact same answer. Well, I wouldn't... But then, I don't believe in rate-limiting by delay: many ISPs do. Rate-limiting, to me, means some packets must be dropped; to many ISPs, it means you need bigger buffers. Thus, I avoid talking of a "rate-limiter" in such a way as to either include or exclude shaping by delay. >> A shaper defines a virtual circuit peak bandwidth and burst duration >> type behavior for downstream and upstream customer access. This is >> easy for customers and connecion-oriented operators to understand >> and relatively easy to measure. Well, actually it isn't easy to _understand_ -- it's merely easy to pretend you understand... :^( > A shaper emulates the behaviour of a port that is full and is doing > output queueing, but at any speed and in any direction. It can do > WRED/ECN, just like a port doing queueing. I agree with the "emulates" part. > I think someone needs to define the terms in the document itself, > otherwise you'll get confusion as different organisations define > these terms differently. You're almost certainly right. Alas, defining within the document may not be enough: folks tend to stick with their familiar definitions regardless of definitions within the document. :^( > Also, I think anyone who wants to present CONEX to a wider audience > needs to create me concrete examples about what's going on. I'm not sure we're there yet... > I've been doing routing/QOS engineering for 10+ years, most of the > time I don't get what people in this group are talking about. Welcome to the club! > It's like you're living in a completely different world and using > completely different words to describe things. Unfortunately, Humpty-Dumpty lives on in all too many of us. > I understand exactly how ECN works, I have read the CONEX documents > fairly well, but it's still extremely abstract what the discussions > are about and this is going to work in the real world (ie where the > rubber meets the road). You're the _ideal_ contributor to this work! Some of the abstract-ness is forced upon us by our charter. We _can't_ do anything to fix that right now -- our Area Director is retiring. We could tackle that in a few months -- but it's not clear it would be worth the effort. We have two WG documents: a Use-Cases and an Abstract-Mechanism. They _must_ serve those purposes. There seems to be consensus that it isn't helpful for Use-Cases to separately state mechanism; and Abstract-Mechanism _must_ remain abstract. datatracker.ietf.org/wg/conex lists six "related documents", all individual submissions. None of these reflects WG consensus, and it's not at all clear any of them deserve to become WG documents at this time. (Several of them clearly don't, being absorbed into the two WG documents.) I could try to outline possibilities for how ConEx may work in the "real world"; but I tend to avoid it, because opinions are so strong that even suggesting that policing might be done in two different ways tends to start two flame-wars about how anyone could be so stupid as to consider the other way. :^( Nonetheless, I'm open to suggestions... -- John Leslie From john@jlc.net Tue Mar 29 03:46:42 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A9E528C14F for ; Tue, 29 Mar 2011 03:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.489 X-Spam-Level: X-Spam-Status: No, score=-106.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GiMae5BsGOq for ; Tue, 29 Mar 2011 03:46:41 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 3AFA428C13F for ; Tue, 29 Mar 2011 03:46:41 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 7E6EA33C23; Tue, 29 Mar 2011 06:48:19 -0400 (EDT) Date: Tue, 29 Mar 2011 06:48:19 -0400 From: John Leslie To: Mikael Abrahamsson Message-ID: <20110329104819.GC20866@verdi> References: <201103281737.p2SHb7QX001580@bagheera.jungle.bt.co.uk> 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.org Subject: Re: [conex] Discussion of new Use Cases pt 1 - Shaper Definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 10:46:42 -0000 Mikael Abrahamsson wrote: > > "Understanding QoS Policing and Marking ond the Catalyst 3550" > This talks about tokens, burst size, out of profile tokens etc. The > policer acts on all packets according to a simple algorithm. It doesn't > act on "flows". The Catalyst 3550 does many things other than QoS policing. > > I think of a world in packets, queuing, packets being dropped or marked. > If they are queued, dropped or in ECN case, marked, there is congestion. Ah, our old friend: which meaning of "congestion" are you using? > The draft-ietf-conex-concepts-uses talks about "CONEX policers" and > "congestion volume" and "flows". I guess I just fail to see how this > is actually implemented in a real world device and what it would do, > and how this would scale. How it is _actually_ implemented isn't a protocol issue; and we're not even talking _protocol_ yet. :^( How it would scale is a very good question -- and I'm happy to talk about that until the WGCs stamp on me. ;^) The chief scaling issue is keeping flow state. We don't actually envision flow state being kept at all except near sender and/or receiver. Even there, we have plenty of ideas how to radically minimize flow-state -- it's just that we avoid stating them for fear of flame-wars. But I'll state flat-out that there is nothing about the _protocol_ we envision which requires flow-state anywhere except the two endpoints. There _are_ some policing algorithms that could work better with some flow-state; but they absolutely are NOT necessary to the protocol. The protocol can work fine treating all traffic to/from one customer (or peer) as a single flow. If you're happy thinking in terms of dropping packets, go ahead and think of it that way. The packet marking we think in terms of is either by the sender or by an ECN-enabled forwarder. (Though I must admit some of the possibilities we entertain might better be called "forged" ECN marking, they're fundamentally indistinguishable from "genuine" ECN marking. ;^) -- John Leslie From john@jlc.net Tue Mar 29 04:01:49 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6CF128C113 for ; Tue, 29 Mar 2011 04:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.492 X-Spam-Level: X-Spam-Status: No, score=-106.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gs1BQiR30-vx for ; Tue, 29 Mar 2011 04:01:49 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id CCCA33A6948 for ; Tue, 29 Mar 2011 04:01:48 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 065E333C20; Tue, 29 Mar 2011 07:03:27 -0400 (EDT) Date: Tue, 29 Mar 2011 07:03:26 -0400 From: John Leslie To: Nandita Dukkipati Message-ID: <20110329110326.GD20866@verdi> References: <20110314230002.28547.97880.idtracker@localhost> 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.org Subject: Re: [conex] I-D ACTION:draft-ietf-conex-abstract-mech-01.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 11:01:49 -0000 Nandita Dukkipati wrote: > > My comments on this draft are as an individual contributor. Nonetheless, Nandita, you can't entirely escape your WGC role... > 1) Of the three kinds of encoding schemes described (ECN based, > independent bits, and codepoint), ultimately we have to go with one > - which one would you recommend and why? What are the other factors > external to this draft that the choice is dependent on? I don't think it's appropriate for the authors to choose one yet. As far as external factors, that's certainly appropriate to discuss, but you're not clear whether you are suggesting discussing it _in_ the I-D. > 2) The use of credit to simplify audit is a nice concept. While it > makes audit easier, it does push the onus onto the hosts to build up > sufficient credit. Any thoughts on how a transport may know in advance > on how to build up credit prior to receiving any ECN signals? It's out > of scope for this draft, but the TCP modifications draft needs to > address this. As you said, out of scope for this draft. I suggest it be discussed in a separate thread. > [Clarification qs] > 3) Sec. 2 - "For congestion signaled by ECN, auditing is most accurate > when located near the transport receiver. Within any flow or aggregate > of flows, the volume of data tagged with ConEx Signals should never be > less than the total volume of ECN marked data seen near the receiver." > This statement doesn't necessarily hold true in the presence of reverse > congestion when ACKs may get lost. Correct? I don't follow... Are you concentrating on the "never"? Lost ACKs merely delay the signal. I read this text to say that, in aggregate, ConEx congestion-expected markings should equal or exceed ECN congestion-experienced markings. Both travel the same direction (and arguably the same path) and neither is affected by the particulars of how the sender learns of congestion. > 4) Sec 3.3.2 Codepoint Encoding > What's the purpose of ConEx-Not-Marked? Is there an equivalent of it > with independent bits encoding? I'll leave that one for Bob... > 5) Sec 4.3 Audit > Is it fair to assume that Re-Echo-Loss signal is marked only on > retransmitted packets? If not, what are the scenarios where non-retrans. > packets can carry Re-Echo-Loss? Likewise. > 6) Sec. 1.1 Terminology > What is the purpose of colors (Re-Echo-Loss aka Purple etc.)? I didn't > see the use of them in rest of the draft. I believe that's a historical artifact. It _did_ make things easier to follow on some old Bob Briscoe slides. ;^) -- John Leslie From ingemar.s.johansson@ericsson.com Tue Mar 29 04:43:47 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A89813A681B for ; Tue, 29 Mar 2011 04:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHgXofSanjJ5 for ; Tue, 29 Mar 2011 04:43:46 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id CE37F3A67B6 for ; Tue, 29 Mar 2011 04:43:45 -0700 (PDT) X-AuditID: c1b4fb3d-b7bbbae000005311-ff-4d91c653f752 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B6.64.21265.356C19D4; Tue, 29 Mar 2011 13:45:23 +0200 (CEST) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.98]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 29 Mar 2011 13:45:22 +0200 From: Ingemar Johansson S To: Mikael Abrahamsson Date: Tue, 29 Mar 2011 13:45:21 +0200 Thread-Topic: [conex] Discussion of new Use Cases pt 1 Thread-Index: Acvt+4+a4IsWXuroR8iLqmbB1aaCuAACgGKQ Message-ID: References: <20110226145616.GH7663@verdi> <20110303203456.GB89966@verdi> <201103281143.p2SBhcLe030524@bagheera.jungle.bt.co.uk> <201103282212.p2SMCVMr004001@bagheera.jungle.bt.co.uk> In-Reply-To: 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 11:43:47 -0000 Hi I have always had a hard time to understand IETF docs, mainly because of th= e ASCII-flaw. For this reason, to understand ConEx what what it does and wh= y, it is probably better to read some of the re-ECN stuff that contains hum= an readable graphics :-). Bobs page is a good starter http://bobbriscoe.net/projects/refb/ This doc can be particularly useful http://bobbriscoe.net/projects/refb/polfree_rearch08.pdf=20 I am not that worried whether or not you call the "policer" or "shaper" a "= shaper" or "policer", I would rather say that if sufficient time is spent o= n understanding the concept, it becomes quite clear what is meant in the en= d. Of course it is good to have a good terminology but please don't waste a= ll the energy on this. Regards =20 -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 Sent: den 29 mars 2011 05:26 To: Bob Briscoe Cc: conex@ietf.org Subject: Re: [conex] Discussion of new Use Cases pt 1 On Mon, 28 Mar 2011, Bob Briscoe wrote: > Mikael, > > At 12:51 28/03/2011, Mikael Abrahamsson wrote: >> On Mon, 28 Mar 2011, Bob Briscoe wrote: >>=20 >>> There's no room for debate here IMO - a policer adding ECN markings=20 >>> is just plain stupid. If someone isn't responding sufficiently to=20 >>> ECN markings, adding more ECN markings is never going to be used by=20 >>> a sentient network operator to punish them. >>=20 >> I don't agree with this at all. > > See my comment at the end - I believe that the reason you disagree=20 > with this is because *you* are reading and using the term 'policing' inap= propriately. > Unless you can quote an authoritative source for using the term=20 > policing in this sense, please re-adjust your dictionary. See the cisco document I referred to earlier. I don't know if you think thi= s is authoritative or not, but they have 40% of the market so they have con= siderable influence on the terms people use. But I'll wait for next iteration of documents, because from reading so far = I still don't understand what does what and how, in the proposed CONEX worl= d. --=20 Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Tue Mar 29 04:44:25 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F4533A6948 for ; Tue, 29 Mar 2011 04:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTSOUuYTgg20 for ; Tue, 29 Mar 2011 04:44:24 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 9DDA03A67B6 for ; Tue, 29 Mar 2011 04:44:24 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 075FB9C; Tue, 29 Mar 2011 13:46:02 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0539C9A; Tue, 29 Mar 2011 13:46:02 +0200 (CEST) Date: Tue, 29 Mar 2011 13:46:02 +0200 (CEST) From: Mikael Abrahamsson To: John Leslie In-Reply-To: <20110329104819.GC20866@verdi> Message-ID: References: <201103281737.p2SHb7QX001580@bagheera.jungle.bt.co.uk> <20110329104819.GC20866@verdi> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: conex@ietf.org Subject: Re: [conex] Discussion of new Use Cases pt 1 - Shaper Definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 11:44:25 -0000 On Tue, 29 Mar 2011, John Leslie wrote: > How it is _actually_ implemented isn't a protocol issue; and we're > not even talking _protocol_ yet. :^( I'm quite baffled by this statement. Could you please elaborate on this view? Whenever I design something, I have in the back of my mind how it would actually be implemented and if it actually could be done in the real world in the forseeable future at decent cost. The whole "use-case" of CONEX is to save money by not upgrading access/distribution link speed. If it's going to be usable in this scenario it needs to be cheap, otherwise there is no money to be saved. -- Mikael Abrahamsson email: swmike@swm.pp.se From john@jlc.net Tue Mar 29 05:06:59 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3949C3A67B0 for ; Tue, 29 Mar 2011 05:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.494 X-Spam-Level: X-Spam-Status: No, score=-106.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fcil-o7sbY3n for ; Tue, 29 Mar 2011 05:06:58 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 60F283A6784 for ; Tue, 29 Mar 2011 05:06:58 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id CB84733C20; Tue, 29 Mar 2011 08:08:35 -0400 (EDT) Date: Tue, 29 Mar 2011 08:08:35 -0400 From: John Leslie To: Mikael Abrahamsson Message-ID: <20110329120835.GG20866@verdi> References: <201103281737.p2SHb7QX001580@bagheera.jungle.bt.co.uk> <20110329104819.GC20866@verdi> 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.org Subject: Re: [conex] Discussion of new Use Cases pt 1 - Shaper Definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 12:06:59 -0000 This deserves a brief answer: Mikael Abrahamsson wrote: > On Tue, 29 Mar 2011, John Leslie wrote: > >> How it is _actually_ implemented isn't a protocol issue; and we're >> not even talking _protocol_ yet. :^( > > I'm quite baffled by this statement. Could you please elaborate on this > view? It's a simple statement of process: we're considering two WG documents, neither of which discusses _actual_ protocol; _one_ of them discusses "abstract mechanism", which it a pre-protocol stage. > Whenever I design something, I have in the back of my mind how it would > actually be implemented and if it actually could be done in the real world > in the forseeable future at decent cost. I fully agree. But the WG isn't designing a protocol yet. > The whole "use-case" of CONEX is to save money by not upgrading > access/distribution link speed. If it's going to be usable in this > scenario it needs to be cheap, otherwise there is no money to be saved. Actually, use-cases covers a lot of other reasons to proceed with ConEx. -- John Leslie From toby@moncaster.com Tue Mar 29 06:16:18 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F277C3A67C3 for ; Tue, 29 Mar 2011 06:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1rsIWl+4rXW for ; Tue, 29 Mar 2011 06:16:17 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id A37BB3A6784 for ; Tue, 29 Mar 2011 06:16:16 -0700 (PDT) Received: from TobysHP (host86-149-183-12.range86-149.btcentralplus.com [86.149.183.12]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MFOmu-1QA4az1nQi-00EXsA; Tue, 29 Mar 2011 15:17:53 +0200 From: "Toby Moncaster" To: References: <201103281737.p2SHb7QX001580@bagheera.jungle.bt.co.uk> <20110329104819.GC20866@verdi> <20110329120835.GG20866@verdi> In-Reply-To: <20110329120835.GG20866@verdi> Date: Tue, 29 Mar 2011 14:17:52 +0100 Message-ID: <005401cbee13$b5c384b0$214a8e10$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcvuCgpL2D4uSrKhROi8mQhwtaptcAACKkZw Content-Language: en-gb X-Provags-ID: V02:K0:av4Qm6F/jXDXjbgJsB1d+guRpqmKG2H14wdQLNW+jBT 0g3/P5QmR+qR6MM/MD3IOg3OadWNNsHcrj7fIRhqMkYUEhIdxd NseruDdspVx2FnI7g8URRUXTvL3swk4k9hX5bniryJjmG662g7 r5NiM/h4kwGXpbsT9aWgXTA5RTKMOEbgM9JYb/IW8osP/cBIc8 LM+iZwxexN0gYd1nFTUzlLkk13kIZo11rRnTYajjYw= Subject: Re: [conex] Discussion of new Use Cases pt 1 - Shaper Definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 13:16:18 -0000 > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of John Leslie > Sent: 29 March 2011 13:09 > To: Mikael Abrahamsson > Cc: conex@ietf.org > Subject: Re: [conex] Discussion of new Use Cases pt 1 - Shaper > Definition > > This deserves a brief answer: > > Mikael Abrahamsson wrote: > > On Tue, 29 Mar 2011, John Leslie wrote: > > > >> How it is _actually_ implemented isn't a protocol issue; and we're > >> not even talking _protocol_ yet. :^( > > > > I'm quite baffled by this statement. Could you please elaborate on > this > > view? > > It's a simple statement of process: we're considering two WG > documents, > neither of which discusses _actual_ protocol; _one_ of them discusses > "abstract mechanism", which it a pre-protocol stage. And that is how the WG was chartered... > > > Whenever I design something, I have in the back of my mind how it > would > > actually be implemented and if it actually could be done in the real > world > > in the forseeable future at decent cost. > > I fully agree. But the WG isn't designing a protocol yet. There are people that have specific protocols in mind for ConEx. I accept that in the absence of a specific protocol you can reasonably ask "how do we know this will work?" but that is not the same as judging whether the concept of ConEx is worthwhile. > > > The whole "use-case" of CONEX is to save money by not upgrading > > access/distribution link speed. If it's going to be usable in this > > scenario it needs to be cheap, otherwise there is no money to be > saved. > > Actually, use-cases covers a lot of other reasons to proceed with > ConEx. "saving money" is actually fairly low on the list of aims for ConEx. Much more significant are: giving users more control over their network connections, allowing users to prioritise their own traffic (rather than having priorities foisted on them), allowing operators to track sources of congestion, allowing operators to make intelligent decisions about traffic management, allowing operators to target upgrades most effectively, ... > > -- > John Leslie > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From swmike@swm.pp.se Tue Mar 29 07:57:25 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD9EB3A682B for ; Tue, 29 Mar 2011 07:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3JFUk+3vFE9 for ; Tue, 29 Mar 2011 07:57:25 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 043063A67AB for ; Tue, 29 Mar 2011 07:57:24 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D50459C; Tue, 29 Mar 2011 16:59:01 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D05999A; Tue, 29 Mar 2011 16:59:01 +0200 (CEST) Date: Tue, 29 Mar 2011 16:59:01 +0200 (CEST) From: Mikael Abrahamsson To: Toby Moncaster In-Reply-To: <005401cbee13$b5c384b0$214a8e10$@com> Message-ID: References: <201103281737.p2SHb7QX001580@bagheera.jungle.bt.co.uk> <20110329104819.GC20866@verdi> <20110329120835.GG20866@verdi> <005401cbee13$b5c384b0$214a8e10$@com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: conex@ietf.org Subject: Re: [conex] Discussion of new Use Cases pt 1 - Shaper Definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 14:57:26 -0000 On Tue, 29 Mar 2011, Toby Moncaster wrote: > "saving money" is actually fairly low on the list of aims for ConEx. > Much more significant are: giving users more control over their network > connections, allowing users to prioritise their own traffic (rather than > having priorities foisted on them), allowing operators to track sources > of congestion, allowing operators to make intelligent decisions about > traffic management, allowing operators to target upgrades most > effectively, ... For me, most (if not all) of these boil down to "save money". But I guess we can agree to disagree on this point. -- Mikael Abrahamsson email: swmike@swm.pp.se From toby@moncaster.com Tue Mar 29 08:05:37 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C75853A6940 for ; Tue, 29 Mar 2011 08:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvRHCmhiystu for ; Tue, 29 Mar 2011 08:05:28 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id EE91C3A6931 for ; Tue, 29 Mar 2011 08:05:27 -0700 (PDT) Received: from TobysHP (host86-149-183-12.range86-149.btcentralplus.com [86.149.183.12]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0La2eL-1Ph2s70AhR-00lddF; Tue, 29 Mar 2011 17:07:02 +0200 From: "Toby Moncaster" To: "'Bob Briscoe'" , "'Nandita Dukkipati'" References: <20110314230002.28547.97880.idtracker@localhost> <201103290031.p2T0V14I005082@bagheera.jungle.bt.co.uk> In-Reply-To: <201103290031.p2T0V14I005082@bagheera.jungle.bt.co.uk> Date: Tue, 29 Mar 2011 16:07:01 +0100 Message-ID: <006101cbee22$f531ee20$df95ca60$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0062_01CBEE2B.56F65620" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcvtqJy7Y0W5Ny2GQr6uwBIFkVougQAdt4mw Content-Language: en-gb X-Provags-ID: V02:K0:Vcg5ayzGKOfVDIF8V2iAj5exWgqfikmjuJxX86HK4oB thXRCECFsWnTRZ8kE0CiHaZGNpUGbk78MkAPHCY3elUQq9yZOh HF/pI7cqj6ydm8JogRw5keI5Z+khiKnG5zqCkqRmPEEewIXEd+ yg63b+RvwwpexaWPAVYUY6yfZ9uCLY6D56q3Dip1ARc/tBLp0y 44MgUH+XZIPwCRsXz8Gn2wuyTlZCwURIG+GLTbz/4c= Cc: conex@ietf.org Subject: Re: [conex] I-D ACTION:draft-ietf-conex-abstract-mech-01.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 15:05:37 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0062_01CBEE2B.56F65620 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Inline marked {TM} From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of Bob Briscoe Sent: 29 March 2011 01:31 To: Nandita Dukkipati Cc: conex@ietf.org Subject: Re: [conex] I-D ACTION:draft-ietf-conex-abstract-mech-01.txt Nandita, At 20:11 28/03/2011, Nandita Dukkipati wrote: My comments on this draft are as an individual contributor. First of, nice draft! Overall reads well and the points being made are clear. A couple of high level questions and a few minor ones. Mikael's comments make me realise though that we still have to be a lot clearer about what ConEx is not. Also, I've recently read RFC4301 Writing Protocol Models, which we ought to try to follow - it has good advice for writing protocol drafts, especially this abstract one ought to follow it. And I think it would help to put the policy function & audit function in a second figure that is otherwise similar to the first (which we do when presenting slides). 1) Of the three kinds of encoding schemes described (ECN based, independent bits, and codepoint), ultimately we have to go with one - which one would you recommend and why? What are the other factors external to this draft that the choice is dependent on? This is intended to remain open while encoding issues are discussed. I would say - independent bits is overkill - Codepoint is sufficient, and - ECN is last resort if we only have one bit. I guess we could say that (if Matt agrees). {TM} I would suggest that rather than specify this too precisely, give some commentary on what might influence the decision (e.g. trade-off between efficient use of bits and effective provision of ConEx functionality) 2) The use of credit to simplify audit is a nice concept. While it makes audit easier, it does push the onus onto the hosts to build up sufficient credit. Any thoughts on how a transport may know in advance on how to build up credit prior to receiving any ECN signals? It's out of scope for this draft, but the TCP modifications draft needs to address this. My thesis has loads of simulation expts on this. I plan to publish it by May'11 (I have to by Uni regulations). Mirja has also reported on her expts (first ConEx mtg I think). The idea is that it depends how well other parts of the code avoid overshoot at the end of slow-start. For instance, the latest Linux does packet-pair on each pair of packets released by each ack during slow-start, and gets a good estimate of where ssthresh should start this way. [Clarification qs] 3) Sec. 2 - "For congestion signaled by ECN, auditing is most accurate when located near the transport receiver. Within any flow or aggregate of flows, the volume of data tagged with ConEx Signals should never be less than the total volume of ECN marked data seen near the receiver." This statement doesn't necessarily hold true in the presence of reverse congestion when ACKs may get lost. Correct? If working with an unmodified recvr, I agree. However, the scheme for modifying TCP's ECN feedback (in re-ECN, which I believe Mirja is going to put in the ConEx TCP draft) maintains a correct count robust to ack loss (at least once you get an ack again after a loss). 4) Sec 3.3.2 Codepoint Encoding What's the purpose of ConEx-Not-Marked? Is there an equivalent of it with independent bits encoding? It means ConEx is supported, but nothing is being re-echoed. The need to distinguish ConEx from non-ConEx packets is motivated at the start. Relative to independent bits, it's equivalent to 'ConEx' with all the other flags off (Not-*). 5) Sec 4.3 Audit Is it fair to assume that Re-Echo-Loss signal is marked only on retransmitted packets? If not, what are the scenarios where non-retrans. packets can carry Re-Echo-Loss? If TCP or a reliable transport, former is correct. But ConEx is for any transport. In the detailed TCP spec, we will need to say what the sender does in response to a ConEx marked packet being dropped etc. (one of Georgios's points). 6) Sec. 1.1 Terminology What is the purpose of colors (Re-Echo-Loss aka Purple etc.)? I didn't see the use of them in rest of the draft. They tend to get used a lot when explaining ConEx, so we thought it best to put them in here, even though we don't use them ourselves. Black, Red, Green & Grey have fairly intuitive meanings (at least for me from a western culture) of Credit, debit, start and neutral. {TM} Although using green for start does give a possible connotation of red for stop... Purple was an attempt to find a colour that hadn't already been used and that was close to black. {TM} If the colours aren't going to be used in this document it may not be the best place to define them... HTH Bob -Nandita On Mon, Mar 14, 2011 at 4:00 PM, wrote: A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion Exposure Working Group of the IETF. Title : Congestion Exposure (ConEx) Concepts and Abstract Mechanism Author(s) : M. Mathis, et al Filename : draft-ietf-conex-abstract-mech-01.txt Pages : 18 Date : 2011-03-14 This document describes an abstract mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. Today, the network may signal congestion to the receiver by ECN markings or by dropping packets, and the receiver passes this information back to the sender in transport-layer feedback. The mechanism to be developed by the ConEx WG will enable the sender to also relay this congestion information back into the network in-band at the IP layer, such that the total level of congestion is visible to all IP devices along the path, from where it could, for example, provide input to traffic management. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-conex-abstract-mech-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design ------=_NextPart_000_0062_01CBEE2B.56F65620 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Inline marked {TM}

 

From:= = conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of = Bob Briscoe
Sent: 29 March 2011 01:31
To: = Nandita Dukkipati
Cc: conex@ietf.org
Subject: Re: = [conex] I-D = ACTION:draft-ietf-conex-abstract-mech-01.txt

<= /div>

 

Nandita,

At 20:11 28/03/2011, Nandita Dukkipati = wrote:

My comments on this = draft are as an individual contributor.

First of, nice draft! = Overall reads well and the points being made are clear. A couple of high = level questions and a few minor ones.


Mikael's comments make me realise though that we = still have to be a lot clearer about what ConEx is not.

Also, = I've recently read RFC4301 Writing Protocol Models, which we ought to = try to follow - it has good advice for writing protocol drafts, = especially this abstract one ought to follow it.

And I think it = would help to put the policy function & audit function in a second = figure that is otherwise similar to the first (which we do when = presenting slides).



1) Of the three kinds of encoding schemes described = (ECN based, independent bits, and codepoint), ultimately we have to go = with one - which one would you recommend and why? What are the other = factors external to this draft that the choice is dependent = on?


This is intended to remain = open while encoding issues are discussed.

I would say
- = independent bits is overkill
- Codepoint is sufficient, and
- ECN = is last resort if we only have one bit.
I guess we could say that (if = Matt agrees).

 

{TM} I would suggest that rather than specify this too precisely, = give some commentary on what might influence the decision (e.g. = trade-off between efficient use of bits and effective provision of ConEx = functionality)





2) = The use of credit to simplify audit is a nice concept. While it makes = audit easier, it does push the onus onto the hosts to build up = sufficient credit. Any thoughts on how a transport may know in advance = on how to build up credit prior to receiving any ECN signals? It's out = of scope for this draft, but the TCP modifications draft needs to = address this.


My thesis has loads = of simulation expts on this. I plan to publish it by May'11 (I have to = by Uni regulations). Mirja has also reported on her expts (first ConEx = mtg I think).

The idea is that it depends how well other parts of = the code avoid overshoot at the end of slow-start. For instance, the = latest Linux does packet-pair on each pair of packets released by each = ack during slow-start, and gets a good estimate of where ssthresh should = start this way.



[Clarification qs]
3) Sec. 2 - "For congestion = signaled by ECN, auditing is most accurate when located near the = transport receiver.  Within any flow or aggregate of flows, the = volume of data tagged with ConEx Signals should never be less than the = total volume of ECN marked data seen near the receiver."
This = statement doesn't necessarily hold true in the presence of reverse = congestion when ACKs may get lost. Correct?


If working with an unmodified recvr, I = agree.

However, the scheme for modifying TCP's ECN feedback (in = re-ECN, which I believe Mirja is going to put in the ConEx TCP draft) = maintains a correct count robust to ack loss (at least once you get an = ack again after a loss).



4) Sec 3.3.2 Codepoint Encoding
What's the purpose = of ConEx-Not-Marked? Is there an equivalent of it with independent bits = encoding?


It means ConEx is = supported, but nothing is being re-echoed. The need to distinguish ConEx = from non-ConEx packets is motivated at the start.

Relative to = independent bits, it's equivalent to 'ConEx' with all the other flags = off (Not-*).



5) Sec = 4.3 Audit
Is it fair to assume that Re-Echo-Loss signal is marked = only on retransmitted packets? If not, what are the scenarios where = non-retrans. packets can carry Re-Echo-Loss?


If TCP or a reliable transport, former is = correct.
But ConEx is for any transport.

In the detailed TCP = spec, we will need to say what the sender does in response to a ConEx = marked packet being dropped etc. (one of Georgios's = points).



6) Sec. 1.1 = Terminology
What is the purpose of colors (Re-Echo-Loss aka Purple = etc.)? I didn't see the use of them in rest of the = draft.


They tend to get used a = lot when explaining ConEx, so we thought it best to put them in here, = even though we don't use them ourselves.

Black, Red, Green & = Grey have fairly intuitive meanings (at least for me from a western = culture) of Credit, debit, start and neutral.

 

{TM} Although using green for start does give a possible connotation = of red for stop...



Purple was an attempt to find a colour that = hadn't already been used and that was close to black.

 

{TM} If the colours aren’t going to be used in this document it = may not be the best place to define them...



HTH


Bob



-Nandita

On Mon, Mar 14, 2011 at 4:00 PM, = <Internet-Drafts@ietf.org = > wrote:

A new Internet-Draft is available from the = on-line Internet-Drafts directories.

This draft is a work item of the Congestion Exposure = Working Group of the IETF.

   = Title         : Congestion = Exposure (ConEx) Concepts and Abstract Mechanism

   = Author(s)     : M. Mathis, et al

   = Filename      : = draft-ietf-conex-abstract-mech-01.txt

   = Pages         : = 18

   = Date          : = 2011-03-14

This document describes an abstract = mechanism by which senders inform

  the network about the congestion = encountered by packets earlier in

  the same flow.  Today, the = network may signal congestion to the

  receiver by ECN markings or by = dropping packets, and the receiver

  passes this information back to the = sender in transport-layer

  feedback.  The mechanism to be = developed by the ConEx WG will enable

  the sender to also relay this = congestion information back into the

  network in-band at the IP layer, = such that the total level of

  congestion is visible to all IP = devices along the path, from where it

  could, for example, provide input to traffic = management.


A URL for this Internet-Draft = is:

http://www.ietf.org/internet-drafts/draft-ietf-conex-abstract-m= ech-01.txt

Internet-Drafts are also available by = anonymous FTP at:

ftp://ftp.ietf.org/internet-= drafts/

Below is the data which will enable a MIME = compliant mail reader

implementation to automatically retrieve = the ASCII version of the

Internet-Draft.

____________________________________________= ___

conex mailing list

conex@ietf.org

https://www.ietf.org= /mailman/listinfo/conex

____________________________= ____________________________________
Bob = Briscoe,           = ;            =          BT Innovate & = Design

------=_NextPart_000_0062_01CBEE2B.56F65620-- From toby@moncaster.com Tue Mar 29 08:10:28 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 026D73A6984 for ; Tue, 29 Mar 2011 08:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nh3DtqcKJJy7 for ; Tue, 29 Mar 2011 08:10:27 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id 012AD3A6940 for ; Tue, 29 Mar 2011 08:10:27 -0700 (PDT) Received: from TobysHP (host86-149-183-12.range86-149.btcentralplus.com [86.149.183.12]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0Lk9Fq-1PY0ev1zNC-00cB15; Tue, 29 Mar 2011 17:12:04 +0200 From: "Toby Moncaster" To: "'Mikael Abrahamsson'" References: <201103281737.p2SHb7QX001580@bagheera.jungle.bt.co.uk> <20110329104819.GC20866@verdi> <20110329120835.GG20866@verdi> <005401cbee13$b5c384b0$214a8e10$@com> In-Reply-To: Date: Tue, 29 Mar 2011 16:12:02 +0100 Message-ID: <006c01cbee23$a972a500$fc57ef00$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcvuIdcUWCXRXZ2hQkKfOBayTexMbwAAY/UQ Content-Language: en-gb X-Provags-ID: V02:K0:5gWfZlGg+t2yPP/b6gTmUFzWtY0CM63ngXXOO/uOJqp ctF+1OBsM82hqgzzcSQGG6RIqatcteGQsvQParKpPhaJ/vlCkK JDBSAmwBsba3k8Uzia5a4rjhcQAenXmqBItyKlxQ28PfaaX5YP YCOTfPQWHexhzOZhyMwUskimyTe3WfqHGlkOT/JpY56VifUofM FG5uVcx541GgMHeERQKbrGFqZkOfwD8C+juXg3ayvs= Cc: conex@ietf.org Subject: Re: [conex] Discussion of new Use Cases pt 1 - Shaper Definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 15:10:28 -0000 I guess actually operators will be wanting to maximise revenue or maximise return on investment (subtly different from saving money)... > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > Sent: 29 March 2011 15:59 > To: Toby Moncaster > Cc: conex@ietf.org > Subject: Re: [conex] Discussion of new Use Cases pt 1 - Shaper > Definition > > On Tue, 29 Mar 2011, Toby Moncaster wrote: > > > "saving money" is actually fairly low on the list of aims for ConEx. > > Much more significant are: giving users more control over their > network > > connections, allowing users to prioritise their own traffic (rather > than > > having priorities foisted on them), allowing operators to track > sources > > of congestion, allowing operators to make intelligent decisions about > > traffic management, allowing operators to target upgrades most > > effectively, ... > > For me, most (if not all) of these boil down to "save money". > > But I guess we can agree to disagree on this point. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Tue Mar 29 23:23:21 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB3C13A6A87 for ; Tue, 29 Mar 2011 23:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTv9isB7FPdY for ; Tue, 29 Mar 2011 23:23:19 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id CC9143A6859 for ; Tue, 29 Mar 2011 23:23:18 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E2B0E9C; Wed, 30 Mar 2011 08:24:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DF0299A; Wed, 30 Mar 2011 08:24:56 +0200 (CEST) Date: Wed, 30 Mar 2011 08:24:56 +0200 (CEST) From: Mikael Abrahamsson To: Bob Briscoe In-Reply-To: <201103282210.p2SMAL0a003959@bagheera.jungle.bt.co.uk> Message-ID: References: <201103281737.p2SHb7QX001580@bagheera.jungle.bt.co.uk> <201103282210.p2SMAL0a003959@bagheera.jungle.bt.co.uk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 - Shaper Definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 06:23:21 -0000 On Mon, 28 Mar 2011, Bob Briscoe wrote: > However, it was written pre-ConEx. The big difference is that document only > focused on using ECN, not loss on the first of the three passes around the > feedback loop. ConEx now aims to work with either loss or ECN. Another way would be that instead of inventing something new, to use existing tech like DSCP marking. Today the Internet doesn't really support it, but that's a choice made by the ISPs. The general consensus in the ISP community is that DSCP bits are ok to reset to 0 for users not purchasing a "QoS service". If this opinion/implementation was changed, then ISPs facing congestion could act on TOS bits to prefer interactive flows (they'd have to be marked as such by the user), and they could also bill on the amount of volume a user sent that was marked interactive and had no ECN markings. If it had ECN marked, then the user would only be billed on the traffic that came back with ECN bit set (I guess this is somewhat what re-ECN tries to do). It would also mean that interactive flows would get ECN bit set whenever there was congestion on a link, but the interactive flow was prioritised and didn't really notice the congestion. This also means ECN bits would have different behaviour depending on what the TOS bits are. For interactive TOS marked packets it would mean "you're being billed", for non-interactive it would have the standard ECN behaviour of today, and TCP would have to be changed appropriately (if TOS = interactive, don't treat ECN bit as indication of need to back off). The advantage of not inventing new bits is that this scheme would work out of the box with IPv6 as well. Generally, any solution that doesn't require the device to understand state and "flow" is beneficial, that's what I'm trying to achieve. Increasing counters is easy, understanding if a "flow" (L4 tuple) is misbehaving and acting on it is a lot harder. I guess this is why I don't really "get" CONEX, because all my interpretations of text I'm reading seems to indicate need to keep state and understand flows. -- Mikael Abrahamsson email: swmike@swm.pp.se From philip.eardley@bt.com Wed Mar 30 04:31:04 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D74B28C165 for ; Wed, 30 Mar 2011 04:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.934 X-Spam-Level: X-Spam-Status: No, score=-101.934 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJ-uTlP-fuEM for ; Wed, 30 Mar 2011 04:31:03 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by core3.amsl.com (Postfix) with ESMTP id 1C4F128C0DB for ; Wed, 30 Mar 2011 04:31:03 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 30 Mar 2011 12:32:41 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.142]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Wed, 30 Mar 2011 12:32:40 +0100 From: To: Date: Wed, 30 Mar 2011 12:32:40 +0100 Thread-Topic: Comments on use cases doc Thread-Index: AQHL7s4tOArgn4J1GEqkmixtQaP0iw== Message-ID: <9510D26531EF184D9017DF24659BB87F327E900C66@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [conex] Comments on use cases doc X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 11:31:04 -0000 http://tools.ietf.org/html/draft-ietf-conex-concepts-uses-01 I think the use case doc could be improved. I found it quite hard to see th= e =91route=92 through the set of use cases: 5.1. ConEx as a basis for traffic management . . . . . . . . . 10 5.2. ConEx to incentivise scavenger transports . . . . . . . . 11 5.3. Accounting for Congestion Volume . . . . . . . . . . . . . 12 5.4. ConEx as a form of differential QoS . . . . . . . . . . . 12 5.5. Partial vs. Full Deployment . . . . . . . . . . . . . . . 13 Doesn=92t =93traffic management=94 include 2, 3 & 4? Is =93partial vs full = deployment=94 really a use case? I wonder if it would be worth distinguishing use cases on the timescale at = which they use conex information (I=92m thinking back to the Technical Plen= ary presentation (from Johari?), this talked about different timescales: mi= lliseconds-seconds; hours-days; months-years [if i remember right]):- =B7 Fast timescale: Operator limits the rate each user can generate= conex marks. It enables enduser controlled qos and thereby encourages ledb= at-style apps =B7 Medium timescale: operator limits the congestion volume each us= er generates; this might encourage users to shift some of their traffic to = a different time of day (back-ups in off-peak times). By an ISP monitoring = the conex marks from several downstream providers, the ISP might be better = able to select between them or include a conex-based parameter in its SLA? =B7 Long timescales: this might help an operator upgrade where cong= estion is high(?) (This is supposed to be a way of structuring and presenting use cases; if a= n actual example has been rejected earlier as a bad one, please substitute = something else) I think it would be better to present the use cases and separately discuss = how each compares with how you might achieve something similar /inferior to= day. For instance, comparing the first one above (operator limits the rate = each user can generate conex marks) with what might be done today (fair sha= ring and similar things) I think discussion of partial deployment would be better as a separate sect= ion that referred back explicitly to one or more of the use cases already d= iscussed and explained how they work (or don=92t) in a partial deployment s= cenario. The current text in the section doesn=92t really talk about the us= e cases (instead it is some discussion about deployment considerations). Sp= ecifically, our charter says =93However, the CONEX WG will initially focus = on one use case, where the end hosts and the network that contains the dest= ination end host are CONEX-enabled but other networks need not be.=94 =96 s= o some discussion should concentrate on this scenario. Couple of comments on terminology: In =93congestion-rate=94 definition you use the term =93instantaneous conge= stion=94 which is not defined (it seems to mean something much more specifi= c than the =93congestion=94 definition) =93ingress=94 and =93egress=94 definitions do not fit with their later use = (when they are specific for a network) Best wishes phil From bob.briscoe@bt.com Wed Mar 30 05:40:38 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F164A28C12F for ; Wed, 30 Mar 2011 05:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RKQaLtMUE+h for ; Wed, 30 Mar 2011 05:40:37 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id DF8AA3A67CC for ; Wed, 30 Mar 2011 05:40:36 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Mar 2011 13:42:14 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Mar 2011 13:42:14 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1301488932773; Wed, 30 Mar 2011 13:42:12 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.3.11]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p2UCgB9p019141; Wed, 30 Mar 2011 13:42:11 +0100 Message-Id: <201103301242.p2UCgB9p019141@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 30 Mar 2011 13:42:09 +0100 To: Toby Moncaster From: Bob Briscoe In-Reply-To: <006101cbee22$f531ee20$df95ca60$@com> References: <20110314230002.28547.97880.idtracker@localhost> <201103290031.p2T0V14I005082@bagheera.jungle.bt.co.uk> <006101cbee22$f531ee20$df95ca60$@com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 30 Mar 2011 12:42:14.0093 (UTC) FILETIME=[E53387D0:01CBEED7] Cc: conex@ietf.org Subject: Re: [conex] I-D ACTION:draft-ietf-conex-abstract-mech-01.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 12:40:38 -0000 Toby, At 16:07 29/03/2011, Toby Moncaster wrote: >Inline marked {TM} snip >1) Of the three kinds of encoding schemes described (ECN based, >independent bits, and codepoint), ultimately we have to go with one >- which one would you recommend and why? What are the other factors >external to this draft that the choice is dependent on? > >This is intended to remain open while encoding issues are discussed. > >I would say >- independent bits is overkill >- Codepoint is sufficient, and >- ECN is last resort if we only have one bit. >I guess we could say that (if Matt agrees). > >{TM} I would suggest that rather than specify this too precisely, >give some commentary on what might influence the decision (e.g. >trade-off between efficient use of bits and effective provision of >ConEx functionality) Sounds reasonable. >6) Sec. 1.1 Terminology >Purple was an attempt to find a colour that hadn't already been used >and that was close to black. > >{TM} If the colours aren't going to be used in this document it may >not be the best place to define them... On balance we thought it best to include them here - I think we should actually use them in this doc, which would make your objection go away. Cheers Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From toby@moncaster.com Wed Mar 30 05:58:27 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE3673A6ABA for ; Wed, 30 Mar 2011 05:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEC4NXRCwzwj for ; Wed, 30 Mar 2011 05:58:27 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by core3.amsl.com (Postfix) with ESMTP id B67EE3A6A1C for ; Wed, 30 Mar 2011 05:58:26 -0700 (PDT) Received: from TobysHP (host86-149-183-12.range86-149.btcentralplus.com [86.149.183.12]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0LeS5t-1PdGEG2IdJ-00q09K; Wed, 30 Mar 2011 15:00:02 +0200 From: "Toby Moncaster" To: "'Bob Briscoe'" References: <20110314230002.28547.97880.idtracker@localhost> <201103290031.p2T0V14I005082@bagheera.jungle.bt.co.uk> <006101cbee22$f531ee20$df95ca60$@com> <201103301242.p2UCgB9p019141@bagheera.jungle.bt.co.uk> In-Reply-To: <201103301242.p2UCgB9p019141@bagheera.jungle.bt.co.uk> Date: Wed, 30 Mar 2011 13:59:59 +0100 Message-ID: <001501cbeeda$60eda7a0$22c8f6e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acvu1+UlEV8kSoJMRG+/7ZOYyIOQXgAAjg7g Content-Language: en-gb X-Provags-ID: V02:K0:CaGuFPeLLSj+loVH2bHFpRCS+avjDTa11HJ8VmwpuQZ D6tEMMNzYy1JLL9MbV4m0OtwEhJYs7CFpIpPeWgDVWsvwT3zaP P2jn8vcobPGBCFoj+MsDY2gXM80NnoQVrlSTfBTqhJoV1bFMqx ag+0F1kKyEkceHxhD15NHQzOkQwv8UZVzTejL7ZeksJbertx6S qgk+fesDrw7zo2EKnSTI3JkNCnaN/iFl+ig0N7X1l4= Cc: conex@ietf.org Subject: Re: [conex] I-D ACTION:draft-ietf-conex-abstract-mech-01.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 12:58:27 -0000 > -----Original Message----- > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > Sent: 30 March 2011 13:42 > To: Toby Moncaster > Cc: 'Nandita Dukkipati'; conex@ietf.org > Subject: RE: [conex] I-D ACTION:draft-ietf-conex-abstract-mech-01.txt > > Toby, > > At 16:07 29/03/2011, Toby Moncaster wrote: > >Inline marked {TM} > > snip > > >6) Sec. 1.1 Terminology > >Purple was an attempt to find a colour that hadn't already been used > >and that was close to black. > > > >{TM} If the colours aren't going to be used in this document it may > >not be the best place to define them... > > On balance we thought it best to include them here - I think we > should actually use them in this doc, which would make your objection > go away. Indeed it would... And as experience suggests many people find the colours helpful, perhaps it would be wise to use them in the document. Toby > > Cheers > > > Bob > > > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design From toby@moncaster.com Wed Mar 30 06:05:48 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED75F3A67DB for ; Wed, 30 Mar 2011 06:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cc9mu2AY+nko for ; Wed, 30 Mar 2011 06:05:47 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id 3AD563A67CC for ; Wed, 30 Mar 2011 06:05:47 -0700 (PDT) Received: from TobysHP (host86-149-183-12.range86-149.btcentralplus.com [86.149.183.12]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0Lg6v5-1Pbbea0es7-00pSqZ; Wed, 30 Mar 2011 15:07:23 +0200 From: "Toby Moncaster" To: , References: <9510D26531EF184D9017DF24659BB87F327E900C66@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F327E900C66@EMV65-UKRD.domain1.systemhost.net> Date: Wed, 30 Mar 2011 14:07:21 +0100 Message-ID: <001601cbeedb$68197b20$384c7160$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AQHL7s4tOArgn4J1GEqkmixtQaP0i5RF1zPw Content-Language: en-gb X-Provags-ID: V02:K0:2YhLnzCYpEwuJzQ+YNO3MpMUEoWDvSNUVmMv0Ne+WT5 tyldWKtO8koaSKjW8PF8KO6qpmOl6OVo6e/dKeh8iK6Lbgmeb3 wl6N7MvjnXlGUfsME+iA8OrxGRfnLgCXBRJ4/ebyLdWZAOWvI/ lcQWR9upthtOQwzSv5dN2ln3N0TapmkCAz+xBfCmdQtcfFFAoi OHVgSe/VR6rqqDN191s1505EeI6qsIjA/UB6Oz5/fc= Subject: Re: [conex] Comments on use cases doc X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 13:05:49 -0000 Hi Phil, Thanks for your comments. I had already started to wonder about imposing some structure like the one you mention. In particular I feel it may be a way to better integrate Dave's long timescales section into the rest of the document. inline > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of philip.eardley@bt.com > Sent: 30 March 2011 12:33 > To: conex@ietf.org > Subject: [conex] Comments on use cases doc > > http://tools.ietf.org/html/draft-ietf-conex-concepts-uses-01 > I think the use case doc could be improved. I found it quite hard to > see the 'route' through the set of use cases: > 5.1. ConEx as a basis for traffic management . . . . . . . . . 10 > 5.2. ConEx to incentivise scavenger transports . . . . . . . . > 11 > 5.3. Accounting for Congestion Volume . . . . . . . . . . . . . > 12 > 5.4. ConEx as a form of differential QoS . . . . . . . . . . . > 12 > 5.5. Partial vs. Full Deployment . . . . . . . . . . . . . . . > 13 > > Doesn't "traffic management" include 2, 3 & 4? Is "partial vs full > deployment" really a use case? > > I wonder if it would be worth distinguishing use cases on the timescale > at which they use conex information (I'm thinking back to the Technical > Plenary presentation (from Johari?), this talked about different > timescales: milliseconds-seconds; hours-days; months-years [if i > remember right]):- > > . Fast timescale: Operator limits the rate each user can > generate conex marks. It enables enduser controlled qos and thereby > encourages ledbat-style apps > > . Medium timescale: operator limits the congestion volume each > user generates; this might encourage users to shift some of their > traffic to a different time of day (back-ups in off-peak times). By an > ISP monitoring the conex marks from several downstream providers, the > ISP might be better able to select between them or include a conex- > based parameter in its SLA? > > . Long timescales: this might help an operator upgrade where > congestion is high(?) Can also include some stuff from Dave's section > > (This is supposed to be a way of structuring and presenting use cases; > if an actual example has been rejected earlier as a bad one, please > substitute something else) > > I think it would be better to present the use cases and separately > discuss how each compares with how you might achieve something similar > /inferior today. For instance, comparing the first one above (operator > limits the rate each user can generate conex marks) with what might be > done today (fair sharing and similar things) We certainly need to make it clearer why ConEx is better than today's technology. > > I think discussion of partial deployment would be better as a separate > section that referred back explicitly to one or more of the use cases > already discussed and explained how they work (or don't) in a partial > deployment scenario. O This is already on the todo list. >The current text in the section doesn't really > talk about the use cases (instead it is some discussion about > deployment considerations). Specifically, our charter says "However, > the CONEX WG will initially focus on one use case, where the end hosts > and the network that contains the destination end host are CONEX- > enabled but other networks need not be." - so some discussion should > concentrate on this scenario. I am starting to think we need to narrow our focus within this document. It is clear that by trying to include too wide a range of use cases we are actually risking alienating some people. Clearly we need to show that ConEx is applicable more widely than the narrow scope of the charter, but we equally need to show that within that narrow scope ConEx has some applicability (otherwise we'll never answer our critics who ask what is the point of ConEx). > > > > Couple of comments on terminology: > In "congestion-rate" definition you use the term "instantaneous > congestion" which is not defined (it seems to mean something much more > specific than the "congestion" definition) Thanks. I'll check and either improve the definition or add one for instantaneous congestion. > "ingress" and "egress" definitions do not fit with their later use > (when they are specific for a network) OK, I'll check and clarify either the definition or the usage. The chances are that the definition got left behind when we removed the section on mechanism from an earlier draft... Toby > > Best wishes > phil > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From john@jlc.net Wed Mar 30 21:56:21 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5B603A6C03 for ; Wed, 30 Mar 2011 21:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.496 X-Spam-Level: X-Spam-Status: No, score=-106.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDPe5LbXF48s for ; Wed, 30 Mar 2011 21:56:20 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 5FACC3A6837 for ; Wed, 30 Mar 2011 21:56:20 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 2479E33C25; Thu, 31 Mar 2011 00:57:59 -0400 (EDT) Date: Thu, 31 Mar 2011 00:57:59 -0400 From: John Leslie To: Mikael Abrahamsson Message-ID: <20110331045759.GA33467@verdi> References: <201103281737.p2SHb7QX001580@bagheera.jungle.bt.co.uk> <201103282210.p2SMAL0a003959@bagheera.jungle.bt.co.uk> 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.org Subject: Re: [conex] Discussion of new Use Cases pt 1 - Shaper Definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 31 Mar 2011 04:56:22 -0000 Mikael Abrahamsson wrote: > > Another way would be that instead of inventing something new, to use > existing tech like DSCP marking. Actually, it's likely ConEx may define one or more DSCP codes. > Today the Internet doesn't really support it, but that's a choice made > by the ISPs. The general consensus in the ISP community is that DSCP > bits are ok to reset to 0 for users not purchasing a "QoS service". Very sad... But please recall, we're working in IPv6, not IPv4. Zeroing DSCP in IPv6 is going to be considered "damage". > If this opinion/implementation was changed, then ISPs facing congestion > could act on TOS bits to prefer interactive flows (they'd have to be > marked as such by the user), and they could also bill on the amount of > volume a user sent that was marked interactive and had no ECN markings. That's a rather biggish flag-day... Nonetheless, it is something specifically _permissible_ in ConEx (though not recommended). > If it had ECN marked, then the user would only be billed on the traffic > that came back with ECN bit set (I guess this is somewhat what re-ECN > tries to do). Actually, ConEx would be more likely to recommend no charge for traffic with their DSCP codepoint _unless_ it has a congestion-expected mark. (Of course, saying what we'll actually recommend is way premature.) (I don't know what you mean by "came back with ECN bit set"; and I'm not going to guess -- but if you mean anything like keeping flow-state, it sounds like a really-bad idea.) > It would also mean that interactive flows would get ECN bit set whenever > there was congestion on a link, but the interactive flow was prioritised > and didn't really notice the congestion. If there is actual charging for congestion-expected marking, that's obviously reasonable. We tend to expect the contractual arrangement to be an "allowance" instead of a per-mark charge, and we argue this is also reasonable. (For this to work, pretty much every "interactive" flow would have to start with what we call "building a ConEx credit"; but that's an issue between end-user and ISP, not a "protocol" issue.) > This also means ECN bits would have different behaviour depending on > what the TOS bits are. Not necessarily... > For interactive TOS marked packets it would mean "you're being billed", > for non-interactive it would have the standard ECN behaviour of > today, and TCP would have to be changed appropriately (if TOS = > interactive, don't treat ECN bit as indication of need to back off). "No need to back off" is a non-starter. "Back-off", of course, is up to the sender. Already, not all senders _do_ back off; but ConEx isn't intended to say it's OK to not back off: instead it encourages you to say, "I expect this much congestion." _One_ possible implementation at full deployment is that the ISP has a contractual arrangement to accept a larger number of congestion-expected packets and pay settlements to ensure preferential delivery. But we're a long way from specifying any such thing: we're not even looking at a "sufficiently-full" deployment to do that. > The advantage of not inventing new bits is that this scheme would work > out of the box with IPv6 as well. Please! We're talking IPv6-only in ConEx. IPv4 is entirely outside our charter. > Generally, any solution that doesn't require the device to understand > state and "flow" is beneficial, that's what I'm trying to achieve. > Increasing counters is easy, understanding if a "flow" (L4 tuple) is > misbehaving and acting on it is a lot harder. I guess this is why I > don't really "get" CONEX, because all my interpretations of text I'm > reading seems to indicate need to keep state and understand flows. I'd appreciate you pointing out anything in use-cases that leads you to think that. It is definitely not what the authors intend. -- John Leslie From swmike@swm.pp.se Wed Mar 30 22:13:20 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0381A28C104 for ; Wed, 30 Mar 2011 22:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5yRlhPcOZOb for ; Wed, 30 Mar 2011 22:13:18 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 6EC873A69B4 for ; Wed, 30 Mar 2011 22:13:18 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E6A319C; Thu, 31 Mar 2011 07:14:55 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E1DDD9A; Thu, 31 Mar 2011 07:14:55 +0200 (CEST) Date: Thu, 31 Mar 2011 07:14:55 +0200 (CEST) From: Mikael Abrahamsson To: John Leslie In-Reply-To: <20110331045759.GA33467@verdi> Message-ID: References: <201103281737.p2SHb7QX001580@bagheera.jungle.bt.co.uk> <201103282210.p2SMAL0a003959@bagheera.jungle.bt.co.uk> <20110331045759.GA33467@verdi> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: conex@ietf.org Subject: Re: [conex] Discussion of new Use Cases pt 1 - Shaper Definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 31 Mar 2011 05:13:20 -0000 On Thu, 31 Mar 2011, John Leslie wrote: > But please recall, we're working in IPv6, not IPv4. Zeroing DSCP in > IPv6 is going to be considered "damage". Please elaborate. This is the first I have heard of this and I would bet I'm no the only one in the ISP community. > (I don't know what you mean by "came back with ECN bit set"; and I'm > not going to guess -- but if you mean anything like keeping flow-state, > it sounds like a really-bad idea.) How does the receiver signal to the sender that he received an ECN marked packet which had the ECN "would have dropped bit" set? Anyhow, it's this congestion signal I meant. > Please! We're talking IPv6-only in ConEx. IPv4 is entirely outside our > charter. I wasn't aware of this. I thought I saw some IPv4 discussion here, but I might have it mixed up with members active in here being active in other WGs talking about using new IPv4 header bits. > I'd appreciate you pointing out anything in use-cases that leads you > to think that. It is definitely not what the authors intend. I re-read the use-case and it seems I must be misremembering (or got the idea from another text), because as it stands right now, it seems fairly clear that there is no per-flow action going on. Perhaps the use-case could explicitly refer to itself and CONEX being about IPv6 only btw, I couldn't find any reference to neither IPv4 or IPv6. -- Mikael Abrahamsson email: swmike@swm.pp.se From john@jlc.net Wed Mar 30 23:17:28 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A684528C217 for ; Wed, 30 Mar 2011 23:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJvyRPxCSvBF for ; Wed, 30 Mar 2011 23:17:27 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 59E4C28C216 for ; Wed, 30 Mar 2011 23:17:27 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id E0B2C33C25; Thu, 31 Mar 2011 02:19:05 -0400 (EDT) Date: Thu, 31 Mar 2011 02:19:05 -0400 From: John Leslie To: Mikael Abrahamsson Message-ID: <20110331061905.GD99488@verdi> References: <201103281737.p2SHb7QX001580@bagheera.jungle.bt.co.uk> <201103282210.p2SMAL0a003959@bagheera.jungle.bt.co.uk> <20110331045759.GA33467@verdi> 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.org Subject: Re: [conex] Discussion of new Use Cases pt 1 - Shaper Definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 31 Mar 2011 06:17:28 -0000 Mikael Abrahamsson wrote: > On Thu, 31 Mar 2011, John Leslie wrote: > >> But please recall, we're working in IPv6, not IPv4. Zeroing DSCP in >> IPv6 is going to be considered "damage". > > Please elaborate. Not sure what I can say without starting a flame-war. :^( Basically, the baggage of actually _doing_ something based on those bits is no longer there in IPv6; and they're the only thing available for introducing new features. > This is the first I have heard of this and I would bet I'm no the only > one in the ISP community. I'm sure you're right about that! >> (I don't know what you mean by "came back with ECN bit set"; and I'm >> not going to guess -- but if you mean anything like keeping flow-state, >> it sounds like a really-bad idea.) > > How does the receiver signal to the sender that he received an ECN marked > packet which had the ECN "would have dropped bit" set? Anyhow, it's this > congestion signal I meant. That signalling path is transport-dependent. For TCP I recommend http://en.wikipedia.org/wiki/Explicit_Congestion_Notification >> Please! We're talking IPv6-only in ConEx. IPv4 is entirely outside our >> charter. > > I wasn't aware of this. I thought I saw some IPv4 discussion here, but I > might have it mixed up with members active in here being active in other > WGs talking about using new IPv4 header bits. Most of Bob Briscoe's leading up to ConEx was written for IPv4 originally: thus it's easy to think IPv4 when reading it... >> I'd appreciate you pointing out anything in use-cases that leads you >> to think that. It is definitely not what the authors intend. > > I re-read the use-case and it seems I must be misremembering (or got the > idea from another text), because as it stands right now, it seems fairly > clear that there is no per-flow action going on. > > Perhaps the use-case could explicitly refer to itself and CONEX being > about IPv6 only btw, I couldn't find any reference to neither IPv4 or > IPv6. Good point! -- John Leslie From carlberg@g11.org.uk Thu Mar 31 00:21:39 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA96828C226 for ; Thu, 31 Mar 2011 00:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6-oS4+mc0sg for ; Thu, 31 Mar 2011 00:21:38 -0700 (PDT) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 7076A28C234 for ; Thu, 31 Mar 2011 00:21:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=g11.org.uk; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=bljeAbCJeaCCh/UwheKrZrb52O5HBkGNkKBGCXRb3re37YQBULLTciztKIBeyzC8ak3jwn8u1krH64AfpnaEJNa2YwY5ua8YpYSMW87lCMY/YyJT0hI9P1Fr+NViuMXp; Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:59969 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from ) id 1Q5CDn-0003yM-LV; Thu, 31 Mar 2011 07:23:11 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: <20110331045759.GA33467@verdi> Date: Thu, 31 Mar 2011 03:23:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201103281737.p2SHb7QX001580@bagheera.jungle.bt.co.uk> <201103282210.p2SMAL0a003959@bagheera.jungle.bt.co.uk> <20110331045759.GA33467@verdi> To: John Leslie X-Mailer: Apple Mail (2.1082) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Cc: conex@ietf.org Subject: Re: [conex] Discussion of new Use Cases pt 1 - Shaper Definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 31 Mar 2011 07:21:39 -0000 On Mar 31, 2011, at 12:57 AM, John Leslie wrote: >> Another way would be that instead of inventing something new, to use=20= >> existing tech like DSCP marking. >=20 > Actually, it's likely ConEx may define one or more DSCP codes. >=20 >> Today the Internet doesn't really support it, but that's a choice = made >> by the ISPs. The general consensus in the ISP community is that DSCP >> bits are ok to reset to 0 for users not purchasing a "QoS service". >=20 > Very sad... actually, this falls un the category of Your Mileage May Vary. an = intern in my office did a series of pings with different ToS byte values = (both ECN and diff-serv fields) and found that the majority of ISPs left = the entire byte "as is", ie, didn't zero out the entire byte. some = zero'ed the byte, and a smaller subset just zero'ed out just the old = Precedence set of bits. I'll caveat the statement that the testing = wasn't fully exhaustive, so this is just food for thought. -ken From swmike@swm.pp.se Thu Mar 31 00:24:44 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D4203A6A46 for ; Thu, 31 Mar 2011 00:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.259 X-Spam-Level: X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4f8AD94msPlh for ; Thu, 31 Mar 2011 00:24:43 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 03B083A680E for ; Thu, 31 Mar 2011 00:24:42 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 38A279C; Thu, 31 Mar 2011 09:26:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3215B9A; Thu, 31 Mar 2011 09:26:21 +0200 (CEST) Date: Thu, 31 Mar 2011 09:26:21 +0200 (CEST) From: Mikael Abrahamsson To: ken carlberg In-Reply-To: Message-ID: References: <201103281737.p2SHb7QX001580@bagheera.jungle.bt.co.uk> <201103282210.p2SMAL0a003959@bagheera.jungle.bt.co.uk> <20110331045759.GA33467@verdi> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: conex@ietf.org Subject: Re: [conex] Discussion of new Use Cases pt 1 - Shaper Definition X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 31 Mar 2011 07:24:44 -0000 On Thu, 31 Mar 2011, ken carlberg wrote: > actually, this falls un the category of Your Mileage May Vary. an > intern in my office did a series of pings with different ToS byte values > (both ECN and diff-serv fields) and found that the majority of ISPs left > the entire byte "as is", ie, didn't zero out the entire byte. some > zero'ed the byte, and a smaller subset just zero'ed out just the old > Precedence set of bits. I'll caveat the statement that the testing > wasn't fully exhaustive, so this is just food for thought. Yes, that is my experience as well. YMMV. My point was not "all ISPs zero", but "it's ok to zero if you want to". I brought this up on nanog-l and I felt the consensus was as I described above. -- Mikael Abrahamsson email: swmike@swm.pp.se From nanditad@google.com Thu Mar 31 03:20:13 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 661353A6AF3 for ; Thu, 31 Mar 2011 03:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKv85MewByl9 for ; Thu, 31 Mar 2011 03:20:12 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 953183A6A4D for ; Thu, 31 Mar 2011 03:20:11 -0700 (PDT) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id p2VALn92027225 for ; Thu, 31 Mar 2011 03:21:49 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301566910; bh=FwIB0c8ZunLHastnq9DFJ8cApG0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=BXMwQW889tt2sSJR94r6AeMwKtQ1DzXZMlCCSdL/Xe1NJkEr2Asjevn0VI4CBpKBl wmPzUv96rLoVJeFxTRp6Q== Received: from ywj3 (ywj3.prod.google.com [10.192.10.3]) by kpbe16.cbf.corp.google.com with ESMTP id p2VALKiX026583 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 31 Mar 2011 03:21:48 -0700 Received: by ywj3 with SMTP id 3so903626ywj.19 for ; Thu, 31 Mar 2011 03:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cmHPaOervJII2ZogP0OgvFPDM6qiqzXAXBwtc303T0s=; b=WoMam4iQlX0ZzpTFi5B9FdOuXx7onOs3H6VNy0vMIyz4mfSNmziXpgYbgPrGuojuuf pFdO8nQfdboq7SU1n0qQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=I+1iMAgnlfrj/kDsIZfZQXyRiv6BD2ns67OPq0C0adIcgODB/1D9Qb3bI5MTTRlmU5 m9OyOPGPELwqLq+vQQSQ== MIME-Version: 1.0 Received: by 10.90.183.18 with SMTP id g18mr2805288agf.73.1301566907921; Thu, 31 Mar 2011 03:21:47 -0700 (PDT) Received: by 10.91.219.10 with HTTP; Thu, 31 Mar 2011 03:21:47 -0700 (PDT) In-Reply-To: <201103301242.p2UCgB9p019141@bagheera.jungle.bt.co.uk> References: <20110314230002.28547.97880.idtracker@localhost> <201103290031.p2T0V14I005082@bagheera.jungle.bt.co.uk> <006101cbee22$f531ee20$df95ca60$@com> <201103301242.p2UCgB9p019141@bagheera.jungle.bt.co.uk> Date: Thu, 31 Mar 2011 12:21:47 +0200 Message-ID: From: Nandita Dukkipati To: Bob Briscoe Content-Type: multipart/alternative; boundary=00163630f10332b6de049fc4a94a X-System-Of-Record: true Cc: conex@ietf.org Subject: Re: [conex] I-D ACTION:draft-ietf-conex-abstract-mech-01.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 31 Mar 2011 10:20:13 -0000 --00163630f10332b6de049fc4a94a Content-Type: text/plain; charset=ISO-8859-1 1) Of the three kinds of encoding schemes described (ECN based, independent >> bits, and codepoint), ultimately we have to go with one - which one would >> you recommend and why? What are the other factors external to this draft >> that the choice is dependent on? >> >> This is intended to remain open while encoding issues are discussed. >> >> I would say >> - independent bits is overkill >> - Codepoint is sufficient, and >> - ECN is last resort if we only have one bit. >> I guess we could say that (if Matt agrees). >> >> {TM} I would suggest that rather than specify this too precisely, give >> some commentary on what might influence the decision (e.g. trade-off between >> efficient use of bits and effective provision of ConEx functionality) >> > > Sounds reasonable. > I like the comment made by Toby - to discuss the tradeoffs with various encoding schemes. That way we know precisely the pros/cons of each one when it comes to the point of choosing one. --00163630f10332b6de049fc4a94a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

1) Of the three kinds of encoding schemes described (ECN based, independent= bits, and codepoint), ultimately we have to go with one - which one would = you recommend and why? What are the other factors external to this draft th= at the choice is dependent on?

This is intended to remain open while encoding issues are discussed.

I would say
- independent bits is overkill
- Codepoint is sufficient, and
- ECN is last resort if we only have one bit.
I guess we could say that (if Matt agrees).

{TM} I would suggest that rather than specify this too precisely, give some= commentary on what might influence the decision (e.g. trade-off between ef= ficient use of bits and effective provision of ConEx functionality)

Sounds reasonable.

I like the comment m= ade by Toby - to discuss the tradeoffs with various encoding schemes. That = way we know precisely the pros/cons of each one=A0when it comes to the poin= t of choosing one.
--00163630f10332b6de049fc4a94a--