Re: [re-ECN] Charter Question
Bob Briscoe <rbriscoe@jungle.bt.co.uk> Mon, 17 May 2010 16:35 UTC
Return-Path: <rbriscoe@jungle.bt.co.uk>
X-Original-To: re-ecn@core3.amsl.com
Delivered-To: re-ecn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7B3C3A6D72 for <re-ecn@core3.amsl.com>; Mon, 17 May 2010 09:35:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.077
X-Spam-Level:
X-Spam-Status: No, score=0.077 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_50=0.001, DNS_FROM_RFC_BOGUSMX=1.482, 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 8YRb10aFKnPe for <re-ecn@core3.amsl.com>; Mon, 17 May 2010 09:35:09 -0700 (PDT)
Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id DF5963A689F for <re-ecn@ietf.org>; Mon, 17 May 2010 09:30:46 -0700 (PDT)
Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 May 2010 17:30:38 +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, 17 May 2010 17:30:37 +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 1274113835603; Mon, 17 May 2010 17:30:35 +0100
Received: from MUT.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o4HGUYqX000979; Mon, 17 May 2010 17:30:34 +0100
Message-Id: <201005171630.o4HGUYqX000979@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 17 May 2010 17:30:36 +0100
To: David Harrington <ietfdbh@comcast.net>
From: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
In-Reply-To: <01b401caf5bd$07acce30$0600a8c0@china.huawei.com>
References: <EE00404438E9444D90AEA84210DC4067079B53@pacdcexcmb05.cable.comcast.com> <4BE4F8F3.7000709@cisco.com> <201005171056.o4HAu2pt029111@bagheera.jungle.bt.co.uk> <01b401caf5bd$07acce30$0600a8c0@china.huawei.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: 17 May 2010 16:30:37.0354 (UTC) FILETIME=[480878A0:01CAF5DE]
Cc: bmanning@vacation.karoshi.com, "'Woundy, Richard'" <Richard_Woundy@cable.comcast.com>, re-ecn@ietf.org
Subject: Re: [re-ECN] Charter Question
X-BeenThere: re-ecn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: re-inserted explicit congestion notification <re-ecn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/re-ecn>, <mailto:re-ecn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/re-ecn>
List-Post: <mailto:re-ecn@ietf.org>
List-Help: <mailto:re-ecn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/re-ecn>, <mailto:re-ecn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 May 2010 16:35:18 -0000
David, Allow me to talk in terms of the only concrete proposal we have (re-ECN): 1/ Whole path congestion marking Re-ECN starts with the end systems telling all networks on the path what the e2e congestion is. They use an e2e marking that the end-systems can cover with e2e authentication. If a network scrubbed re-ECN markings, it would/could break e2e authentication - probably worse than sending TCP resets ;) Just re-ECN on its own, without ECN, has a number of interesting uses. I didn't think much about re-ECN with drop (not ECN) when I designed re-ECN, but Matt Mathis convinced me. The incentive for senders to declare re-ECN markings is strongest for the large majority of systems that are *not* the main contributors to congestion. They are saying "It's not me". OS and/or app developers have an incentive to implement this for the majority of their customers. E.g. BitTorrent has an incentive to make LEDBAT traffic prove that "It's not me". 2/ ECN marking Your question is, however, most relevant to whether an operator will turn on ECN, because that's the protocol that reveals whether the congestion is upstream or downstream of a point, when combined with ConEx info. Yes, of course an operator doesn't have to turn on ECN; so why would it?... Once ConEx is deployed in a major OS or app, there is an incentive for well-provisioned operators (the majority) to turn on ECN, again to say "It's not me"... Here's why: Imagine e2e ConEx markings are revealing a high level of congestion in the traffic passing between networks A&B - somewhere on their e2e paths in A or B. If you are network A and your network is not to blame, you can prove this to B by turning on ECN. Alternatively, if network B is not to blame, it can accuse A of being responsible for the whole path congestion, unless A turns on ECN to prove how much of the congestion is in B. 3/ Congestion as a business secret? Networks already cannot help but reveal to end-systems that there is congestion somewhere on the path. ConEx allows end-systems to reveal this info back to networks. That would be a result for the IETF if it took off, even if ECN was still not deployed. I've given plausible scenarios for how ConEx then ECN might get deployed. But ultimately I cannot say whether or not networks that have something to hide will predominate. If so, we might get ConEx but not ECN. If not, we might get both ConEx and ECN. But this issue is beyond the IESG's remit to judge - it should surely "let the market decide" on this point. Let's get moving. Bob At 13:32 17/05/2010, David Harrington wrote: >Hi, > >Do we already have protocols that could help solve this problem >intra-domain, such as ipfix and psamp? > >One of the concerns that has been raised is whether domains will be >willing to share this potentially-sensitive information across >domains. >As a vendor, if I supported a re-ecn, I would think I would be >motivated to allow the operator to decide not to share the info, and I >would implement a scrubbing mechanism (allow border routers to clear >the conex markers in traffic exiting a domain). The IETF cannot >dictate that deployments reveal this sensitive information, any more >than it could dictate that SNMP traps must be allowed cross-domain. > >So maybe we should approach the problem in two steps: > >1) determining how well existing standard protocols can be used to >effectively address the intra-domain congestion problem, and whether >specific enhancements, such as congestion-specific ipfix IEs, are >needed. This would give us forward progress on standard approaches for >monitoring congestion that might be deployed fairly quickly. > >2) how to share information across domains. Since the major question >here seems to be whether domains would be motivated to share, maybe an >effort akin to INCH is needed for this piece. After we solve the first >problem, we can try to extend it to cross-domain, or use a different >mechanism for cross-domain reporting. > >dbh > > > -----Original Message----- > > From: re-ecn-bounces@ietf.org > > [mailto:re-ecn-bounces@ietf.org] On Behalf Of Bob Briscoe > > Sent: Monday, May 17, 2010 6:56 AM > > To: stbryant@cisco.com > > Cc: bmanning@vacation.karoshi.com; Woundy,Richard; re-ecn@ietf.org > > Subject: Re: [re-ECN] Charter Question > > > > Stewart, > > > > At 06:38 08/05/2010, Stewart Bryant wrote: > > >On 08/05/2010 01:19, Woundy, Richard wrote: > > >>So now let's add Conex marking, in which the end hosts add >markings > > >>to send feedback about end-to-end congestion into the network. Now > > > >>the CMTS has a new data point -- information about whether there >is > > >>upstream (ECN) or downstream (Conex) congestion > > >>experienced/expected for a particular packet flow. The CMTS can > > >>count 'total bytes' as well as 'congestion bytes' on a per modem > > >>basis. As a result, the backend system can make a much better > > >>determination about whether a subscriber's overall traffic is > > >>dominated by LEDBAT or non-LEDBAT applications, without resorting > > >>to DPI and other such schemes. And the CMTS only maintains another > > > >>set of packet counters, without disrupting its primary job of > > >>packet forwarding. > > >> > > >>-- Rich > > >This sounds like a relatively slow process - i.e. over a few >packets > > >the host tell anyone who wishes to listen that it is seeing > > >congestion on a flow. That sounds like it could be addressed by > > >having the host send an OAM packet from time to time over the path > > >rather than including the information in every packet. > > > > > >Stewart > > > > An OAM based solution would be in scope as a solution to the ConEx > > problem statement. However, we would need someone to write up a > > protocol spec in detail, including inter-domain, then prove it is > > resistant to cheating, etc etc. If this happens (unlikely) the w-g > > can choose between candidate solutions. > > > > Anyway, granular isn't necessarily bad. For instance, operators > > generally use data volume on slow timescales, but a volume counter > > still has to accumulate packet by packet. Congestion-volume is no > > different - except you just count the volume of packets that are > > congestion marked. > > > > We should be open to any solution, whether granular or coarse, as > > long as it solves the problem ConEx aims to address: that network > > operators currently have no reliable way (fast or slow) to measure > > which users contribute how much to congestion - at least not in >cases > > where the congestion is occurring at a different point to where it >is > > being measured and controlled - whether the two points are within > > your own network, as in Rich's example, or in different networks. > > > > > > > > Bob > > > > PS. sorry for late reply. > > > > PPS. The only feasible OAM-based system I am aware of is Katerina > > Argyraki's (ref below). I'm sure the IESG would not want this level > > > of complexity in the Internet. Also it only solves one side of > > congestion accountability: network to users, whereas re-ECN aims to > > make networks accountable to users *and* users accountable to > > networks. > > > > Argyraki, K., Maniatis, P., Irzak, O., Ashish, S. & Shenker, S., > > "Loss and Delay Accountability for the Internet," In: Proc. IEEE > > International Conference on Network Protocols IEEE (October > > 2007) URL: > > http://www-dsg.stanford.edu/papers/astra/astra-hotnets04-paper.pdf > > > > > > > > ________________________________________________________________ > > Bob Briscoe, BT Innovate & Design > > > > _______________________________________________ > > re-ECN mailing list > > re-ECN@ietf.org > > https://www.ietf.org/mailman/listinfo/re-ecn > > ________________________________________________________________ Bob Briscoe, BT Innovate & Design
- [re-ECN] Charter Question Ron Bonica
- Re: [re-ECN] Charter Question Ron Bonica
- Re: [re-ECN] Charter Question John Leslie
- Re: [re-ECN] Charter Question bmanning
- Re: [re-ECN] Charter Question John Leslie
- Re: [re-ECN] Charter Question bmanning
- Re: [re-ECN] Charter Question John Leslie
- Re: [re-ECN] Charter Question Woundy, Richard
- Re: [re-ECN] Charter Question Stewart Bryant
- Re: [re-ECN] Charter Question Ron Bonica
- Re: [re-ECN] Charter Question John Leslie
- Re: [re-ECN] Charter Question Woundy, Richard
- Re: [re-ECN] Charter Question Ron Bonica
- Re: [re-ECN] Charter Question bmanning
- Re: [re-ECN] Charter Question John Leslie
- Re: [re-ECN] Charter Question John Leslie
- Re: [re-ECN] Charter Question Bob Briscoe
- Re: [re-ECN] Charter Question David Harrington
- Re: [re-ECN] Charter Question John Leslie
- Re: [re-ECN] Charter Question McCann Peter-A001034
- [re-ECN] Preferential Dropping John Leslie
- Re: [re-ECN] Charter Question Bob Briscoe
- Re: [re-ECN] Preferential Dropping McCann Peter-A001034
- Re: [re-ECN] Preferential Dropping John Leslie
- Re: [re-ECN] Preferential Dropping Bob Briscoe
- Re: [re-ECN] Preferential Dropping McCann Peter-A001034
- Re: [re-ECN] Preferential Dropping Bob Briscoe
- Re: [re-ECN] Preferential Dropping McCann Peter-A001034