From rs@netapp.com Tue Sep 14 23:38:31 2010 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 3B87D3A68DC for ; Tue, 14 Sep 2010 23:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 hQh9RStIX6F3 for ; Tue, 14 Sep 2010 23:38:29 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 863B33A6AA9 for ; Tue, 14 Sep 2010 23:38:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,369,1280732400"; d="scan'208";a="203398997" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 14 Sep 2010 23:38:50 -0700 Received: from ldcrsexc1-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o8F6b6aJ020249; Tue, 14 Sep 2010 23:38:14 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Sep 2010 07:38:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Sep 2010 07:38:03 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0A5CB754@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <563C162F43D1B14E9FD2BC0A776C1E9127EFCA5F29@WNEXMBX01.telecom.tcnz.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] comments on draft-moncaster-conex-concepts-uses-01.txt Thread-Index: ActCf2/aeQ3QhIotQGuZPi+ARPABkwAypTmgBEYyi8A= References: <20100812123814.GF16820@verdi><001b01cb3a2b$80f47420$82dd5c60$@com><563C162F43D1B14E9FD2BC0A776C1E9127EF2857D3@WNEXMBX01.telecom.tcnz.net><563C162F43D1B14E9FD2BC0A776C1E9127EF3A66C7@WNEXMBX01.telecom.tcnz.net><001201cb3eb8$9992cb30$ccb86190$@com><563C162F43D1B14E9FD2BC0A776C1E9127EF929B5E@WNEXMBX01.telecom.tcnz.net><20100823045529.GZ16820@verdi> <563C162F43D1B14E9FD2BC0A776C1E9127EFCA5F29@WNEXMBX01.telecom.tcnz.net> From: "Scheffenegger, Richard" To: "Kevin Mason" , "John Leslie" , "Christopher Morrow" X-OriginalArrivalTime: 15 Sep 2010 06:38:03.0850 (UTC) FILETIME=[8C7A0AA0:01CB54A0] Cc: conex@ietf.org Subject: Re: [conex] comments on draft-moncaster-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: Wed, 15 Sep 2010 06:38:31 -0000 > From: Kevin Mason [mailto:Kevin.Mason@telecom.co.nz]=20 > Sent: Mittwoch, 25. August 2010 01:30 > > ConEx clearly can be useful for distinguishing "less=20 > > than best effort" flows from "interactive" flows, and > > using that information to target efforts at bandwidth > > upgrades. LBE flows don't call for bandwidth=20 > > upgrades; interactive flows do. >=20 > I don't see how this can be done by CONEX, traffic class=20 > (priority) is not conveyed by CONEX.=20 If an ingress router (BRAS) checks the average ConEx Predicted Congestion marking of a single flow, and compares that against the average marking rate of that user/port, wouldn't that implicitly convey information about the traffic class a end user wishes its traffic to be in? Ie. LBE would probably have lower-than-average Conex markings, while interactive flows a higher marking. If the end user wouldn't want that traffic to cause congestion somewhere in the network, s/he wouldn't mark them at a higher-than-average rate, but instead throttle the bandwidth until the marking would be close to average... Or is that just wishful thinking :) Richard Scheffenegger From john@jlc.net Wed Sep 15 02:48:36 2010 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 835F73A6B6C for ; Wed, 15 Sep 2010 02:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.945 X-Spam-Level: X-Spam-Status: No, score=-105.945 tagged_above=-999 required=5 tests=[AWL=0.654, 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 EUW0Ywgl+c+y for ; Wed, 15 Sep 2010 02:48:35 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 7EEF93A6B1C for ; Wed, 15 Sep 2010 02:48:35 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 0400233C44; Wed, 15 Sep 2010 05:49:01 -0400 (EDT) Date: Wed, 15 Sep 2010 05:49:00 -0400 From: John Leslie To: "Scheffenegger, Richard" Message-ID: <20100915094900.GK58335@verdi> References: <563C162F43D1B14E9FD2BC0A776C1E9127EFCA5F29@WNEXMBX01.telecom.tcnz.net> <5FDC413D5FA246468C200652D63E627A0A5CB754@LDCMVEXC1-PRD.hq.netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5FDC413D5FA246468C200652D63E627A0A5CB754@LDCMVEXC1-PRD.hq.netapp.com> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] comments on draft-moncaster-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: Wed, 15 Sep 2010 09:48:36 -0000 Scheffenegger, Richard wrote: > > If an ingress router (BRAS) checks the average ConEx Predicted > Congestion marking of a single flow, and compares that against the > average marking rate of that user/port, wouldn't that implicitly convey > information about the traffic class a end user wishes its traffic to be > in? Yes. > Ie. LBE would probably have lower-than-average Conex markings, while > interactive flows a higher marking. Clearly, a LBE flow will simply not send when expected congestion exceeds some percentage. I would expect a LBE flow to also estimate low when starting a flow (before actual congestion feedback has been received), but we shouldn't depend on that. > If the end user wouldn't want that traffic to cause congestion somewhere > in the network, s/he wouldn't mark them at a higher-than-average rate, > but instead throttle the bandwidth until the marking would be close to > average... "Higher-than-average rate" may not be quite the right algorithm, since it's really hard to compute a meaningful "average". I would expect LBE traffic to set an upper bound of what fraction of congestion it's willing to estimate on traffic it sends -- absolute, not as-compared-to- average. So your ingress router would probably see a lower marking rate for LBE traffic, but the real sign is that such traffic disappears when the marking rate gets high enough. The point, after all, is to have a reliable signal of when upgrading bandwidth is called for. -- John Leslie From rs@netapp.com Wed Sep 15 04:55:04 2010 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 722DE3A6BA8 for ; Wed, 15 Sep 2010 04:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.455 X-Spam-Level: X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 v1NUBzJvYrLz for ; Wed, 15 Sep 2010 04:54:59 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id 264CF3A6950 for ; Wed, 15 Sep 2010 04:54:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,371,1280732400"; d="scan'208";a="214770199" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 15 Sep 2010 04:55:23 -0700 Received: from amsrsexc1-prd.hq.netapp.com (webmail.europe.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o8FBp7lZ007719; Wed, 15 Sep 2010 04:55:07 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Sep 2010 13:48:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Sep 2010 12:48:55 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0A6D5169@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <20100915094900.GK58335@verdi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] comments on draft-moncaster-conex-concepts-uses-01.txt Thread-Index: ActUu0hVI3ZeGmeNRu+w0hpn/zXydwADxh5g References: <563C162F43D1B14E9FD2BC0A776C1E9127EFCA5F29@WNEXMBX01.telecom.tcnz.net> <5FDC413D5FA246468C200652D63E627A0A5CB754@LDCMVEXC1-PRD.hq.netapp.com> <20100915094900.GK58335@verdi> From: "Scheffenegger, Richard" To: "John Leslie" X-OriginalArrivalTime: 15 Sep 2010 11:48:57.0526 (UTC) FILETIME=[FAEF1D60:01CB54CB] Cc: conex@ietf.org Subject: Re: [conex] comments on draft-moncaster-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: Wed, 15 Sep 2010 11:55:04 -0000 Hi John, The issue I see with some absolute limits is that you can not really know what absolute level that might be. After all, tuning RED parameters is still a black art, and even if you can not (as admin) tune RED, each vendor likely has different implementations which align best with the specific hardware... I do understand that standard ECN TCP will react to any number of CE marks per cwnd as non-ECN TCP would. However, prescribing a fixed, say, 2% maximum marking rate, would again make further evolution of (ECN) TCP (and other protocols, near impossible. Just as an example, from my understanding, DCTCP may require much higher marking rates (up to 100%) for some RTTs to run properly. One can now argue, that such enhancements might only work in enclosed environments, but again I think that's against the spirt of TCP.... In summary, I'm against fixed absolute values to denote LBE or other implicit service levels... Unless, there is a ridig set of RED parameters which have to go with it too...(? Need to think about that, though) Richard > -----Original Message----- > From: John Leslie [mailto:john@jlc.net]=20 > > > If the end user wouldn't want that traffic to cause congestion=20 > > somewhere in the network, s/he wouldn't mark them at a=20 > > higher-than-average rate, but instead throttle the=20 > bandwidth until the=20 > > marking would be close to average... >=20 > "Higher-than-average rate" may not be quite the right=20 > algorithm, since it's really hard to compute a meaningful=20 > "average". I would expect LBE traffic to set an upper bound=20 > of what fraction of congestion it's willing to estimate on=20 > traffic it sends -- absolute, not as-compared-to- average. >=20 > So your ingress router would probably see a lower marking=20 > rate for LBE traffic, but the real sign is that such traffic=20 > disappears when the marking rate gets high enough. >=20 > The point, after all, is to have a reliable signal of when=20 > upgrading bandwidth is called for. >=20 > -- > John Leslie >=20 From christopher.morrow@gmail.com Wed Sep 15 06:31:36 2010 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 364853A6A3D for ; Wed, 15 Sep 2010 06:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.095 X-Spam-Level: X-Spam-Status: No, score=-102.095 tagged_above=-999 required=5 tests=[AWL=0.504, 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 76c6MU8RDejm for ; Wed, 15 Sep 2010 06:31:35 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 367A33A6832 for ; Wed, 15 Sep 2010 06:31:35 -0700 (PDT) Received: by gxk20 with SMTP id 20so90379gxk.31 for ; Wed, 15 Sep 2010 06:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=8gchrC2gNohMbQSOU9DowzjFV9TPkjjJDE0Ect0P5xs=; b=B6HuAcXWakXKdB4RZ9uJYdcSKg6xSe65GT3WTLkLuMcAICxWZfhjvxHSedjmLuhaUO tVFU8/k18tEhd7Txt1JzpiZfvoK32AZfJAupzfAD4bt/OYx2VLgIhrfAaqAlmMGG9PuF vtOgueBXAMWaMFcZCDvfzTi9J2e0fsJQklgL0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=RlqMbA3kZTN/Cfh57XB3jYnNBOewkbojV27WTidxZFp7gIxzuJcPdHEEevQlmChYUC F3Eh09Cr8UHh/ShUC7j7v1BOMKBAES+36LnMqbU56QvpPAWNv+oRrPcwX1YneIQpsUo9 6vBjkNfuctLMkZUw8j34nu/bXiEONIZx+lBgw= MIME-Version: 1.0 Received: by 10.90.55.4 with SMTP id d4mr1134791aga.70.1284557511481; Wed, 15 Sep 2010 06:31:51 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.117.155 with HTTP; Wed, 15 Sep 2010 06:31:50 -0700 (PDT) In-Reply-To: <5FDC413D5FA246468C200652D63E627A0A5CB754@LDCMVEXC1-PRD.hq.netapp.com> References: <20100812123814.GF16820@verdi> <001b01cb3a2b$80f47420$82dd5c60$@com> <563C162F43D1B14E9FD2BC0A776C1E9127EF2857D3@WNEXMBX01.telecom.tcnz.net> <563C162F43D1B14E9FD2BC0A776C1E9127EF3A66C7@WNEXMBX01.telecom.tcnz.net> <001201cb3eb8$9992cb30$ccb86190$@com> <563C162F43D1B14E9FD2BC0A776C1E9127EF929B5E@WNEXMBX01.telecom.tcnz.net> <20100823045529.GZ16820@verdi> <563C162F43D1B14E9FD2BC0A776C1E9127EFCA5F29@WNEXMBX01.telecom.tcnz.net> <5FDC413D5FA246468C200652D63E627A0A5CB754@LDCMVEXC1-PRD.hq.netapp.com> Date: Wed, 15 Sep 2010 09:31:50 -0400 X-Google-Sender-Auth: aetGHsgiFnB-3TNVh9BGF0oMrO8 Message-ID: From: Christopher Morrow To: "Scheffenegger, Richard" Content-Type: text/plain; charset=ISO-8859-1 Cc: Kevin Mason , conex@ietf.org Subject: Re: [conex] comments on draft-moncaster-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: Wed, 15 Sep 2010 13:31:36 -0000 On Wed, Sep 15, 2010 at 2:38 AM, Scheffenegger, Richard wrote: > Ie. LBE would probably have lower-than-average Conex markings, while > interactive flows a higher marking. If the end user wouldn't want that > traffic to cause congestion somewhere in the network, s/he wouldn't mark it's highly unlikely that the end-user understands 'cause congestion somewhere in the network', it's also highly unlikely that 'somewhere in the network' is a helpful measure for the end user. I think you mean: "cause their internet experience (for this application, ie: yahoomail/gmail/vonage/quake) to degrade at this time" -chris From john@jlc.net Wed Sep 15 07:20:47 2010 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 8B3B93A6832 for ; Wed, 15 Sep 2010 07:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.962 X-Spam-Level: X-Spam-Status: No, score=-105.962 tagged_above=-999 required=5 tests=[AWL=0.637, 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 zFMuDyoFD3L9 for ; Wed, 15 Sep 2010 07:20:46 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 1F4533A6888 for ; Wed, 15 Sep 2010 07:20:46 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 74CB733C60; Wed, 15 Sep 2010 10:21:11 -0400 (EDT) Date: Wed, 15 Sep 2010 10:21:11 -0400 From: John Leslie To: "Scheffenegger, Richard" Message-ID: <20100915142111.GL58335@verdi> References: <563C162F43D1B14E9FD2BC0A776C1E9127EFCA5F29@WNEXMBX01.telecom.tcnz.net> <5FDC413D5FA246468C200652D63E627A0A5CB754@LDCMVEXC1-PRD.hq.netapp.com> <20100915094900.GK58335@verdi> <5FDC413D5FA246468C200652D63E627A0A6D5169@LDCMVEXC1-PRD.hq.netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5FDC413D5FA246468C200652D63E627A0A6D5169@LDCMVEXC1-PRD.hq.netapp.com> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] comments on draft-moncaster-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: Wed, 15 Sep 2010 14:20:47 -0000 Scheffenegger, Richard wrote: > > The issue I see with some absolute limits is that you can not really > know what absolute level that might be. This is quite true, actually... (We know what level of packet-drop will seriously impede TCP-reno traffic of a particular rate for a particular RTT; but we know neither the desired flow nor the RTT for all competing traffic, for example.) Nonetheless, I expect LBE algorithms to converge towards a fairly conservative "congestion probability", and I expect that to be stated as an absolute packet-drop probability, not as a relative percentage of "average" packet-drop probability (whatever that means). > After all, tuning RED parameters is still a black art, and even if > you can not (as admin) tune RED, each vendor likely has different > implementations which align best with the specific hardware... I believe we're distancing ConEx from ECN, though it's still early to say whether the ConEx mechanism might build on ECN. (I've been toying with a possible ConEx mechanism quite separate from ECN...) If we do adopt a ConEx mechanism which depends on ECN, I agree we won't be able to depend upon many details of the RED algorithm driving the ECN marks. But I believe regardless of the model, along a path _I_ consider "completely uncongested" there should be no "congestion experienced" marked; so a lower-bound of 0% is quite possible. If LBE protocols were to base their trigger on "average congestion probability", I still wouldn't expect them to use an instantaneous "average." An "off-hours average" would be more reasonable; but that would have to come from some database... > I do understand that standard ECN TCP will react to any number of CE > marks per cwnd as non-ECN TCP would. However, prescribing a fixed, > say, 2% maximum marking rate, would again make further evolution of > (ECN) TCP (and other protocols), near impossible. I would be _very_ disturbed if any LBE algorithm intentionally allowed 2% packet drop to be "normal"! > Just as an example, from my understanding, DCTCP may require much > higher marking rates (up to 100%) for some RTTs to run properly. Now we're on a different topic... ECN marking, in fact, is often too coarse, in addition to being too loosely defined. I'm quite agreeable to designing the ConEx mechanism to have marking which is less coarse -- in other words, marking which signals packet-drop-probability much less than 100%. (Indeed, I see benefit in being able to signal packet-drop probability of less than 0.01%.) IMHO, ECN isn't the right tool for that, but I can easily envision a ConEx mechanism which would signal such low percentages. > One can now argue, that such enhancements might only work in enclosed > environments, I wouldn't agree with that. > but again I think that's against the spirit of TCP.... Hmm... are we going to get into a flamewar _here_ about what the "Internet Founders Actually Anticipated"... ;^) > In summary, I'm against fixed absolute values to denote LBE or other > implicit service levels... I don't believe it is in-charter to prescribe any such thing. > Unless, there is a rigid set of RED parameters which have to go > with it too...(? Need to think about that, though) I'm quite sure rigid RED parameters are out-of-scope for ConEx. -- John Leslie From toby@moncaster.com Thu Sep 16 10:13:42 2010 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 34A6D3A699F for ; Thu, 16 Sep 2010 10:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.100, 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 4IrDS51IHwSn for ; Thu, 16 Sep 2010 10:13:30 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by core3.amsl.com (Postfix) with ESMTP id D9B6E3A6810 for ; Thu, 16 Sep 2010 10:13:28 -0700 (PDT) Received: from TobysHP (host86-170-51-199.range86-170.btcentralplus.com [86.170.51.199]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MKuxg-1OwI1p0Pdg-0003NA; Thu, 16 Sep 2010 19:13:45 +0200 From: "Toby Moncaster" To: "'Christopher Morrow'" , "'Scheffenegger, Richard'" References: <20100812123814.GF16820@verdi> <001b01cb3a2b$80f47420$82dd5c60$@com> <563C162F43D1B14E9FD2BC0A776C1E9127EF2857D3@WNEXMBX01.telecom.tcnz.net> <563C162F43D1B14E9FD2BC0A776C1E9127EF3A66C7@WNEXMBX01.telecom.tcnz.net> <001201cb3eb8$9992cb30$ccb86190$@com> <563C162F43D1B14E9FD2BC0A776C1E9127EF929B5E@WNEXMBX01.telecom.tcnz.net> <20100823045529.GZ16820@verdi> <563C162F43D1B14E9FD2BC0A776C1E9127EFCA5F29@WNEXMBX01.telecom.tcnz.net> <5FDC413D5FA246468C200652D63E627A0A5CB754@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: Date: Thu, 16 Sep 2010 18:13:41 +0100 Message-ID: <001201cb55c2$83416af0$89c440d0$@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: ActU2mS+60tmRdueSou/W7fZIzzZ6QA59YNg Content-Language: en-gb X-Provags-ID: V02:K0:ssJdah2vEiY9EH2ad+/XUOJIR0dc8WCiS9MDuTge+1k y7xJwXvSrhMpB+FvQGOrTV3ecsX9/uuW1I3PcWKfiK1OcZZtOH MU+9J5zQRD/9jgjozHBNi3MowzdEzTwTl9OgQlyHV6zlgqPnyV I+opeLLhZUpfTn2YkCyL4RdeDmyxY1je8MVJsKlyIamgAYXAca xGjwtU1aU2Z5b59EAGSqBbkl+yS/loXiCEn74KuFO0= Cc: 'Kevin Mason' , conex@ietf.org Subject: Re: [conex] comments on draft-moncaster-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: Thu, 16 Sep 2010 17:13:42 -0000 > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Christopher Morrow > Sent: 15 September 2010 14:32 > To: Scheffenegger, Richard > Cc: Kevin Mason; conex@ietf.org > Subject: Re: [conex] comments on draft-moncaster-conex-concepts-uses- > 01.txt > > On Wed, Sep 15, 2010 at 2:38 AM, Scheffenegger, Richard > wrote: > > > Ie. LBE would probably have lower-than-average Conex markings, while > > interactive flows a higher marking. If the end user wouldn't want > that > > traffic to cause congestion somewhere in the network, s/he wouldn't > mark > > it's highly unlikely that the end-user understands 'cause congestion > somewhere in the network', it's also highly unlikely that 'somewhere > in the network' is a helpful measure for the end user. Indeed (unless the user is an IETF geek...) > > I think you mean: "cause their internet experience (for this > application, ie: yahoomail/gmail/vonage/quake) to degrade at this > time" Yep... And that is why we would hope that application developers would provide users with "meaningful" interfaces to do this for them. > > -chris > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex