From internet-drafts@ietf.org Wed Feb 1 14:56:47 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE34A21F8875; Wed, 1 Feb 2012 14:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9thDSGT2M9T; Wed, 1 Feb 2012 14:56:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4078E21F8871; Wed, 1 Feb 2012 14:56:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120201225647.22307.76083.idtracker@ietfa.amsl.com> Date: Wed, 01 Feb 2012 14:56:47 -0800 Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-tcp-modifications-00.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 22:56:47 -0000 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 IETF. Title : TCP modifications for Congestion Exposure Author(s) : Mirja Kuehlewind Richard Scheffenegger Filename : draft-ietf-conex-tcp-modifications-00.txt Pages : 12 Date : 2011-12-21 Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by previous packets on the same flow. This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-conex-tcp-modifications-00.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-conex-tcp-modifications-00.txt From acooper@cdt.org Thu Feb 2 14:08:12 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C0421F862D for ; Thu, 2 Feb 2012 14:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.945 X-Spam-Level: X-Spam-Status: No, score=-99.945 tagged_above=-999 required=5 tests=[AWL=-2.246, BAYES_50=0.001, MANGLED_TOOL=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49OpIAJ0oZcN for ; Thu, 2 Feb 2012 14:08:10 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 8825321F85FC for ; Thu, 2 Feb 2012 14:08:09 -0800 (PST) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for conex@ietf.org; Thu, 2 Feb 2012 17:08:01 -0500 From: Alissa Cooper Content-Type: multipart/mixed; boundary=Apple-Mail-12--126554765 Date: Thu, 2 Feb 2012 17:07:59 -0500 Message-Id: <3ECA5CDD-0A98-4ABC-8B55-445BE4A81C64@cdt.org> To: ConEx IETF list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [conex] Resolution of WGLC comments on draft-ietf-conex-concepts-uses-03 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 22:08:12 -0000 --Apple-Mail-12--126554765 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, I've gone through the comments received before, during, and after WGLC = for draft-ietf-conex-concepts-uses-03. You can see their status at = . They are all in = trac except for some of the ones that Mirja sent after WGLC, which I = will address in a separate email. There is one outstanding that Bob has = the token for, but otherwise they have all been addressed. For the ones that have been fixed, if I did anything other than what the = commenter suggested, I explained the change in the comment attached to = the ticket. I've also attached the updated document for those who want = to look at the diff. I think this should wrap up the WGLC process pending the one outstanding = comment. Alissa --Apple-Mail-12--126554765 Content-Disposition: attachment; filename=draft-ietf-conex-concepts-uses-04.txt Content-Type: text/plain; name="draft-ietf-conex-concepts-uses-04.txt" Content-Transfer-Encoding: quoted-printable ConEx B. Briscoe, Ed. Internet-Draft BT Intended status: Informational R. Woundy, Ed. Expires: April 24, 2012 Comcast A. Cooper, Ed. CDT October 22, 2011 ConEx Concepts and Use Cases draft-ietf-conex-concepts-uses-04 Abstract This document provides the entry point to the set of documentation about the Congestion Exposure (ConEx) protocol. It explains the motivation for including a ConEx marking at the IP layer: to expose information about congestion to network nodes. Although such information may have a number of uses, this document focuses on how the information communicated by the ConEx marking can serve as the basis for significantly more efficient and effective traffic management than what exists on the Internet today. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 24, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Briscoe, et al. Expires April 24, 2012 [Page 1] =0C Internet-Draft ConEx Concepts & Use Cases October 2011 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Congestion . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Congestion-Volume . . . . . . . . . . . . . . . . . . . . 5 2.3. Rest-of-Path Congestion . . . . . . . . . . . . . . . . . 5 2.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 3. Core Use Case: Informing Traffic Management . . . . . . . . . 7 3.1. Use Case Description . . . . . . . . . . . . . . . . . . . 7 3.2. Additional Benefits . . . . . . . . . . . . . . . . . . . 8 3.3. Comparison with Existing Approaches . . . . . . . . . . . 8 4. Other Use Cases . . . . . . . . . . . . . . . . . . . . . . . 10 5. Deployment Arrangements . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Contributors . . . . . . . . . . . . . . . . . . . . . . . 12 9. Informative References . . . . . . . . . . . . . . . . . . . . 13 Appendix A. Changes from previous drafts (to be removed by the RFC Editor) . . . . . . . . . . . . . . . . . . . 14 Briscoe, et al. Expires April 24, 2012 [Page 2] =0C Internet-Draft ConEx Concepts & Use Cases October 2011 1. Introduction The power of Internet technology comes from multiplexing shared capacity with packets rather than circuits. Network operators aim to provide sufficient shared capacity, but when too much packet load meets too little shared capacity, congestion results. Congestion appears as either increased delay, dropped packets or packets explicitly marked with Explicit Congestion Notification (ECN) markings [RFC3168]. As described in Figure 1, congestion control currently relies on the transport receiver detecting these 'Congestion Signals' and informing the transport sender in 'Congestion Feedback Signals.' The sender is then expected to reduce its rate in response. This document provides the entry point to the set of documentation about the Congestion Exposure (ConEx) protocol. It focuses on the motivation for including a ConEx marking at the IP layer. (A companion document, [ConEx-Abstract-Mech], focuses on the mechanics of the protocol.) Briefly, the idea is for the sender to continually signal expected congestion in the headers of any data it sends. To a first approximation, the sender does this by relaying the 'Congestion Feedback Signals' back into the IP layer. They then travel unchanged across the network to the receiver (shown as 'IP-Layer-ConEx-Signals' in Figure 1). This enables IP layer devices on the path to see information about the whole path congestion. ,---------. ,---------. |Transport| |Transport| | Sender | . |Receiver | | | /|___________________________________________| | | ,-<---------------Congestion-Feedback-Signals--<--------. | | | |/ | | | | | |\ Transport Layer Feedback Flow | | | | | | \ ___________________________________________| | | | | | \| | | | | | | ' ,-----------. . | | | | | |_____________| |_______________|\ | | | | | | IP Layer | | Data Flow \ | | | | | | |(Congested)| \ | | | | | | | Network |--Congestion-Signals--->-' | | | | | Device | \| | | | | | | /| | | `----------->--(new)-IP-Layer-ConEx-Signals-------->| | | | | | / | | | |_____________| |_______________ / | | | | | | |/ | | `---------' `-----------' ' `---------' Briscoe, et al. Expires April 24, 2012 [Page 3] =0C Internet-Draft ConEx Concepts & Use Cases October 2011 Figure 1: The ConEx Protocol in the Internet Architecture One of the key benefits of exposing this congestion information at the IP layer is that it makes the information available to network operators for use as input into their traffic management procedures. As shown in Figure 1, a ConEx-enabled sender signals whole path congestion, which is (approximately) the congestion one round trip time earlier as reported by the receiver to the sender. The ConEx signal is a mark in the IP header that is easy for any IP device to read. Therefore a node performing traffic management can count congestion as easily as it might count data volume today by simply counting the volume of packets with ConEx markings. ConEx-based traffic management can make highly efficient use of capacity. In times of no congestion, all traffic management restraints can be removed, leaving the network's full capacity available to all its users. If some users on the network cause disproportionate congestion, the traffic management function can learn about this and directly limit those users' traffic in order to protect the service of other users sharing the same capacity. ConEx- based traffic management thus presents a step change in terms of the options available to network operators for managing traffic on their networks. The remainder of this document explains the concepts behind ConEx and how exposing congestion can significantly improve Internet traffic management, among other benefits. Section 2 introduces a number of concepts that are fundamental to understanding how ConEx-based traffic management works. Section 3 shows how ConEx can be used for traffic management, discusses additional benefits from such usage, and compares ConEx-based traffic management to existing traffic management approaches. Section 4 discusses other related use cases. Section 5 briefly discusses deployment arrangements. The final sections are standard RFC back matter. 2. Concepts ConEx relies on a precise definition of congestion and a number of newer concepts that are introduced and defined in this section. 2.1. Congestion Despite its central role in network control and management, congestion is a remarkably difficult concept to define. Experts in different disciplines and with different perspectives define congestion in a variety of ways [Bauer09]. The definition used for the purposes of ConEx is expressed as the Briscoe, et al. Expires April 24, 2012 [Page 4] =0C Internet-Draft ConEx Concepts & Use Cases October 2011 probability of packet loss (or the probability of packet marking if ECN is in use). This definition focuses on how congestion is measured, rather than describing congestion as a condition or state. 2.2. Congestion-Volume The metric that ConEx exposes is congestion-volume: the volume of bytes dropped or ECN-marked in a given period of time. Counting congestion-volume allows each user to be held responsible for his or her contribution to causing congestion. Congestion-volume is a property of traffic, whereas congestion describes a link or a path. To understand congestion-volume, consider a simple example. Imagine Alice sends 1GB while the loss-probability is a constant 0.2%. Her contribution to congestion -- her congestion-volume -- is 1GB x 0.2% =3D 2MB. If she then sends 3GB while the loss-probability is 0.1%, this adds 3MB to her congestion-volume. Her total contribution to congestion is then 2MB+3MB =3D 5MB. Fortunately, measuring Alice's congestion-volume on a real network does not require the kind of arithmetic shown above because congestion-volume can be directly measured by counting the total volume of Alice's traffic that gets discarded or ECN-marked. (A queue with a percentage loss involves multiplication inherently.) 2.3. Rest-of-Path Congestion At a particular measurement point within a network, "rest-of-path congestion" (also known as "downstream congestion") is the level of congestion that a traffic flow is expected to experience between the measurement point and its final destination. "Upstream congestion" is the congestion experienced up to the measurement point. Measurement points that only observe ECN marks are capable of measuring upstream congestion, whereas measurement points that observe ConEx marks in addition to ECN marks can use both kinds of marks to calculate rest-of-path congestion. When ECN signals are monitored in the middle of a network, they indicate the congestion experienced so far on the path (upstream congestion). In contrast, the ConEx signals inserted into IP headers as shown in Figure 1 indicate the congestion along a whole path from source to destination. Therefore if a measurement point detects both of these signals, it can subtract the level of ECN (upstream congestion) from the level of ConEx (whole path) to derive a measure of the congestion that packets are likely to experience between the monitoring point and their destination (rest-of-path congestion). [ConEx-Abstract-Mech] has further discussion of the constraints Briscoe, et al. Expires April 24, 2012 [Page 5] =0C Internet-Draft ConEx Concepts & Use Cases October 2011 around the network's ability to measure rest-of-path congestion. 2.4. Definitions Congestion: In general, congestion occurs when any user's traffic suffers loss, ECN marking, or increased delay as a result of one or more network resources becoming overloaded. For the purposes of ConEx, congestion is measured using the concrete signals provided by loss and ECN markings (delay is not considered). Congestion is measured as the probability of loss or the probability of ECN marking, usually expressed as a dimensionless percentage. Congestion-volume: For any granularity of traffic (packet, flow, aggregate, link, etc.), the volume of bytes dropped or ECN-marked in a given period of time. Conceptually, data volume multiplied by the congestion each packet of the volume experienced. Usually expressed in bytes (or MB or GB). Congestion policer: A logical entity that allows a network operator to monitor each user's congestion-volume and enforce congestion- volume limits (discussed in Section 3.1). Rest-of-path congestion (or downstream congestion): The congestion a flow of traffic is expected to experience on the remainder of its path. In other words, at a measurement point in the network the rest-of-path congestion is the congestion the traffic flow has yet to experience as it travels from that point to the receiver. Upstream congestion: The accumulated congestion experienced by a traffic flow thus far, relative to a point along its path. In other words, at a measurement point in the network the upstream congestion is the accumulated congestion the traffic flow has experienced as it travels from the sender to that point. At the receiver this is equivalent to the end-to-end congestion level that (usually) is reported back to the sender. Network operators (or providers): Operator of a residential, commercial, enterprise, campus or other network. User: The contractual entity that represents an individual, household, business, or institution that uses the service of a network operator. There is no implication that the contract has to be commercial; for instance, the users of a university or enterprise network service could be students or employees who do not pay for access but may be required to comply with some form of contract or acceptable use policy. There is also no implication that every user is an end user. Where two networks form a Briscoe, et al. Expires April 24, 2012 [Page 6] =0C Internet-Draft ConEx Concepts & Use Cases October 2011 customer-provider relationship, the term user applies to the customer network. [ConEx-Abstract-Mech] gives further definitions for aspects of ConEx related to protocol mechanisms. 3. Core Use Case: Informing Traffic Management This section explains how ConEx could be used as the basis for traffic management, highlights additional benefits derived from having ConEx-aware nodes on the network, and compares ConEx-based traffic management to existing approaches. 3.1. Use Case Description One of the key benefits that ConEx can deliver is in helping network operators to improve how they manage traffic on their networks. Consider the common case of a commercial broadband network where a relatively small number of users place disproportionate demand on network resources, at times resulting in congestion. The network operator seeks a way to manage traffic such that the traffic that contributes more to congestion bears more of the brunt of the management. Assuming ConEx signals are visible at the IP layer, the network operator can accomplish this by placing a congestion policer at an enforcement point within the network and configuring it with a traffic management policy that monitors each user's contribution to congestion. As described in [ConEx-Abstract-Mech] and elaborated in [CongPol], one way to implement a congestion policer is in a similar way to a bit-rate policer, except that it monitors and polices congestion-volume rather than bit-rate. When implemented as a token bucket, the tokens provide users with the right to cause bits of congestion-volume, rather than to send bits of data volume. The fill rate represents each user's congestion-volume quota. The congestion policer monitors the ConEx signals of the traffic entering the network. As long as the network remains uncongested and users stay within their quotas, no action is taken. When the network becomes congested and a user exhausts his quota, some action is taken against the traffic that breached the quota in accordance with the network operator's traffic management policy. For example, the traffic may be dropped, delayed, or marked with a lower QoS class. In this way, traffic is managed according to its contribution to congestion -- not some application- or flow-specific policy -- and is not managed at all during times of no congestion. As an example of how a network operator might employ a ConEx-based Briscoe, et al. Expires April 24, 2012 [Page 7] =0C Internet-Draft ConEx Concepts & Use Cases October 2011 traffic management system, consider a typical DSL network architecture (as elaborated in [TR-059] and [TR-101]). Traffic is routed from regional and global IP networks to an operator-controlled IP node, the Broadband Remote Access Server (BRAS). =46rom the BRAS, traffic is delivered to access nodes. The BRAS carries enhanced functionality including IP QoS and traffic management capabilities. Based on typical network designs and current traffic patterns, the BRAS is located at a point in the network where congestion may be most likely to occur. As a consequence, the BRAS is a logical choice of location for deploying traffic management functionality. By deploying a congestion policer at the BRAS location, the network operator can measure the congestion-volume created by users within the access nodes. The policer would be provisioned with a traffic management policy, perhaps directing the BRAS to drop packets from users that exceed their congestion-volume quotas during times of congestion. Those users would be likely to react in the typical way to drops, backing off (assuming use of standard TCP), and thereby lowering their congestion-volumes back within the quota limits. 3.2. Additional Benefits The ConEx-based approach to traffic management has a number of benefits in addition to efficient management of traffic. It provides incentives for users to make use of scavenger transport protocols, such as [LEDBAT], that provide ways for bulk-transfer applications to rapidly yield when interactive applications require capacity. With a congestion policer in place as described in Section 3.1, users of these protocols will be less likely to run afoul of the network operator's traffic management policy than those whose bulk-transfer applications generate the same volume of traffic without being sensitive to congestion. ConEx-based traffic management also makes it possible for a user to control the relative performance among its own traffic flows. If a user wants some flows to have more bandwidth than others, it can allow the higher bandwidth traffic to generate more congestion signals, leaving less congestion "budget" for the user to "spend" on other traffic. This approach is most relevant if congestion is signalled by ECN, because no impairment due to loss is involved and delay can remain low. 3.3. Comparison with Existing Approaches A variety of approaches already exist for network operators to manage congestion, traffic, and the disproportionate usage of scarce capacity by a small number of users. Common approaches can be categorized as rate-based, volume-based, or application-based. Briscoe, et al. Expires April 24, 2012 [Page 8] =0C Internet-Draft ConEx Concepts & Use Cases October 2011 Rate-based approaches constrain the traffic rate per user or per network. A user's peak and average (or "committed") rate may be limited. These approaches have the potential to either over- or under-constrain the network, suppressing rates even when the network is uncongested or not suppressing them enough during heavy usage periods. Round-robin scheduling and fair queuing were developed to address these problems. They equalize relative rates between active users (or flows) at a known bottleneck. The bit-rate allocated to any one user depends on the number of active users at each instant. The drawback of these approaches is that they favor heavy users over light users over time, because they do not have any memory of usage. Heavy users will be active at every instant whereas light users will only occupy their share of the link occassionally, but bit-rate is shared instant by instant. Volume-based approaches measure the overall volume of traffic a user sends (and/or receives) over time. Users may be subject to an absolute volume cap (for example, 10GB per month) or the "heaviest" users may be sanctioned in some other manner. Many providers use monthly volume limits and count volume regardless of whether the network is congested or not, creating the potential for over- or under-constraining problems, as with the original rate-based approaches. ConEx-based approaches, by comparison, only react during times of congestion and in proportion to each user's congestion contribution, making more efficient use of capacity and more proportionate management decisions. Unlike ConEx-based approaches, neither rate-based nor volume-based approaches provide incentives for applications to use scavenger transports. They may even penalize users of applications that employ scavenger services for the large amount of volume they send, rather than rewarding them for carefully avoiding congestion while sending it. While the volume-based approach described in Comcast's Protocol- Agnostic Congestion Management System [RFC6057] aims to overcome the over/under-constraining problem by only measuring volume and triggering traffic management action during periods of high utilization, it still does not provide incentives to use scavenger transports because congestion-causing volume cannot be distinguished from volume overall. ConEx provides this ability. Application-based approaches use deep packet inspection or other techniques to determine what application a given traffic flow is associated with. Network operators may then use this information to rate-limit or otherwise sanction certain applications, in some cases Briscoe, et al. Expires April 24, 2012 [Page 9] =0C Internet-Draft ConEx Concepts & Use Cases October 2011 only during peak hours. These approaches suffer from being at odds with IPSec and some application-layer encryption, and they may raise additional policy concerns. In contrast, ConEx offers an application-agnostic metric to serve as the basis for traffic management decisions. The existing types of approaches share a further limitation that ConEx can help to overcome: performance uncertainty. Flat-rate pricing plans are popular because users appreciate the certainty of having their monthly bill amount remain the same for each billing period, allowing them to plan their costs accordingly. But while flat-rate pricing avoids billing uncertainty, it creates performance uncertainty: users cannot know whether the performance of their connections is being altered or degraded based on how the network operator is attempting to manage congestion. By exposing congestion information at the IP layer, ConEx instead provides a metric that can serve as an open, transparent basis for traffic management policies that both providers and their customers can measure and verify. It can be used to reduce the performance uncertainty that some users currently experience. 4. Other Use Cases ConEx information can be put to a number of uses other than informing traffic management. These include: Informing inter-operator contracts: ConEx information is made visible to every IP node, including border nodes between networks. Network operators can use this information to measure how much traffic from each network contributes to congestion in the other. As such, congestion-volume could be included as a metric in inter- operator contracts, just as volume or bit-rate are included today. Enabling more efficient capacity provisioning: Network operators currently provision capacity based on observations of a number of network characteristics, including averaged utilization and congestion. Without ConEx, a user may have little incentive to back off during times of congestion, even if the reduction in performance resulting from backing off certain applications (bulk transfer, for example) would go largely unnoticed by the user. Using ConEx to ration congestion-volume directly creates incentives where appropriate for users and applications to switch to scavenger transports, resulting in traffic demand that more accurately reflects the actual capacity needed for the mix of applications on the network to perform well. This enables capacity to be provisioned more efficiently because traffic more closely tracks users' real capacity needs. Briscoe, et al. Expires April 24, 2012 [Page 10] =0C Internet-Draft ConEx Concepts & Use Cases October 2011 5. Deployment Arrangements ConEx is designed so that it can be incrementally deployed in the Internet and still be valuable for early adopters. As long as some senders are ConEx-enabled, a network on the path can unilaterally use ConEx-aware policy devices for traffic management; no changes to network forwarding elements are needed and ConEx still works if there are other networks on the path that are unaware of ConEx marks. The above two steps seem to represent a stand-off where neither step is useful until the other has made the first move: i) some sending hosts must be modifed to give information to the network and ii) a network must deploy policy devices to monitor this information and act on it. Nonetheless, the developer of a scavenger transport protocol like LEDBAT does stand to benefit from deploying ConEx. In this case the developer makes the first move, expecting it will prompt at least some networks to move in response, using the ConEx information to reward users of the scavenger protocol. On the host side, we have already shown (Figure Figure 1) how the sender piggy-backs ConEx signals on normal data packets to re-insert feedback about packet drops (and/or ECN) back into the IP layer. In the case of TCP, [I-D.conex-tcp-mods] proposes the required sender modifications. ConEx works with any TCP receiver as long as it uses SACK, which most do. There is a receiver optimisation [I-D.conex-accurate-ecn] that improves ConEx precision when using ECN, but ConEx can still use ECN without it. On the network side the provider solely needs to place ConEx congestion policers at each ingress to its network, in a similar arrangement to the edge-policed architecture of Diffserv [RFC2475]. A sender can choose whether to send ConEx or Not-ConEx packets. ConEx packets bring information to the policer about congestion expected on the rest of the path beyond the policer. Not-ConEx packets bring no such information. Therefore the network will tend to rate-limit not-ConEx packets conservatively in order to manage the unknown risk of congestion. In contrast, a network doesn't normally need to rate-limit ConEx-enabled packets unless they reveal a persistently high contribution to congestion. This natural tendency for networks to favour senders that provide ConEx information reinforces ConEx deployment. The above gives only the most salient aspects of ConEx deployment. For further detail, [ConEx-Abstract-Mech] describes the incremental deployment features of the ConEx protocol and the components that need to be deployed for ConEx to work. Then [I-D.conex-init-deploy] gives concrete examples of feasible initial deployment scenarios. Briscoe, et al. Expires April 24, 2012 [Page 11] =0C Internet-Draft ConEx Concepts & Use Cases October 2011 6. Security Considerations This document does not specify a mechanism, it merely motivates congestion exposure at the IP layer. Therefore security considerations are described in the companion document that gives an abstract description of the ConEx protocol and the components that would use it [ConEx-Abstract-Mech]. 7. IANA Considerations This document does not require actions by IANA. 8. Acknowledgments Bob Briscoe was partly funded by Trilogy, a research project (ICT- 216372) supported by the European Community under its Seventh Framework Programme. The views expressed here are those of the author only. The authors would like to thank the many people that have commented on this document: Bernard Aboba, Mikael Abrahamsson, Joao Taveira Araujo, Marcelo Bagnulo Braun, Steve Bauer, Caitlin Bestler, Steven Blake, Louise Burness, Ken Carlberg, Nandita Dukkipati, Dave McDysan, Wes Eddy, Matthew Ford, Ingemar Johansson, Georgios Karagiannis, Mirja Kuehlewind, Dirk Kutscher, Zhu Lei, Kevin Mason, Matt Mathis, Michael Menth, Chris Morrow, Tim Shepard, Hannes Tschofenig and Stuart Venters. Please accept our apologies if your name has been missed off this list. 8.1. Contributors Philip Eardley and Andrea Soppera made helpful text contributions to this document. The following co-edited this document through most of its life: Briscoe, et al. Expires April 24, 2012 [Page 12] =0C Internet-Draft ConEx Concepts & Use Cases October 2011 Toby Moncaster Computer Laboratory William Gates Building JJ Thomson Avenue Cambridge, CB3 0FD UK EMail: toby.moncaster@cl.cam.ac.uk John Leslie JLC.net 10 Souhegan Street Milford, NH 03055 US EMail: john@jlc.net 9. Informative References [Bauer09] Bauer, S., Clark, D., and W. Lehr, "The Evolution of Internet Congestion", 2009. [ConEx-Abstract-Mech] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) Concepts and Abstract Mechanism", draft-ietf-conex-abstract-mech-02 (work in progress), July 2011. [CongPol] Briscoe, B., Jacquet, A., and T. Moncaster, "Policing Freedom to Use the Internet Resource Pool", RE-Arch 2008 hosted at the 2008 CoNEXT conference , December 2008. [I-D.conex-accurate-ecn] Kuehlewind, M. and R. Scheffenegger, "Accurate ECN Feedback in TCP", draft-kuehlewind-conex-accurate-ecn-00 (work in progress), July 2011. [I-D.conex-init-deploy] Briscoe, B., "Initial Congestion Exposure (ConEx) Deployment Examples", draft-briscoe-conex-initial-deploy-00 (work in progress), October 2011. [I-D.conex-tcp-mods] Kuehlewind, M. and R. Scheffenegger, "TCP modifications for Congestion Exposure", draft-kuehlewind-conex-tcp-modifications-00 (work in progress), July 2011. [LEDBAT] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Briscoe, et al. Expires April 24, 2012 [Page 13] =0C Internet-Draft ConEx Concepts & Use Cases October 2011 Transport (LEDBAT)", draft-ietf-ledbat-congestion-08 (work in progress), May 2011. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC6057] Bastian, C., Klieber, T., Livingood, J., Mills, J., and R. Woundy, "Comcast's Protocol-Agnostic Congestion Management System", RFC 6057, December 2010. [TR-059] Anschutz, T., Ed., "DSL Forum Technical Report TR-059: Requirements for the Support of QoS-Enabled IP Services", September 2003. [TR-101] Cohen, A., Ed. and E. Schrum, Ed., "DSL Forum Technical Report TR-101: Migration to Ethernet-Based DSL Aggregation", April 2006. Appendix A. Changes from previous drafts (to be removed by the RFC Editor) =46rom draft-ietf-conex-concepts-uses-02 to -03: Reorganization and re-write of most sections. =46rom draft-ietf-conex-concepts-uses-01 to -02: New Abstract & Introduction. Concepts and Misconceptions sections added around definitions. Minor clarifications to Existing Traffic Management and Use-Cases sections, with Other use Cases Added. Deployment Arrangements Section added. =46rom draft-ietf-conex-concepts-uses-00 to -01: Added section on timescales: Section 6 Briscoe, et al. Expires April 24, 2012 [Page 14] =0C Internet-Draft ConEx Concepts & Use Cases October 2011 Revised introduction to clarify congestion definitions Changed source for congestion definition in Section 2 Other minor changes =46rom draft-moncaster-conex-concepts-uses-02 to draft-ietf-conex-concepts-uses-00 (per decisions of working group): Removed section on DDoS mitigation use case. Removed appendix on ConEx Architectural Elements. PLEASE NOTE: Alignment of terminology with the Abstract Mechanism draft has been deferred to the next version. =46rom draft-moncaster-conex-concepts-uses-01 to draft-moncaster-conex-concepts-uses-02: Updated document to take account of the new Abstract Mechanism draft [ConEx-Abstract-Mech]. Updated the definitions section. Removed sections on Requirements and Mechanism. Moved section on ConEx Architectural Elements to appendix. Minor changes throughout. =46rom draft-moncaster-conex-concepts-uses-00 to draft-moncaster-conex-concepts-uses-01: Changed end of Abstract to better reflect new title Created new section describing the architectural elements of ConEx. Added Edge Monitors and Border Monitors (other elements are Ingress, Egress and Border Policers). Extensive re-write of use cases partly in response to suggestions from Dirk Kutscher Improved layout of Section 2 and added definitions of Whole Path Congestion, ConEx-Enabled and ECN-Enabled. Re-wrote definition of Congestion Volume. Renamed Ingress and Egress Router to Ingress and Egress Node as these nodes may not actually be routers. Briscoe, et al. Expires April 24, 2012 [Page 15] =0C Internet-Draft ConEx Concepts & Use Cases October 2011 Improved document structure. Merged sections on Exposing Congestion and ECN. Added new section on ConEx requirements with a ConEx Issues subsection. Text for these came from the start of the old ConEx Use Cases section Added a sub-section on Partial vs Full Deployment (Section 5.5) Added a discussion on ConEx as a Business Secret =46rom draft-conex-mechanism-00 to draft-moncaster-conex-concepts-uses-00: Changed filename to draft-moncaster-conex-concepts-uses. Changed title to ConEx Concepts and Use Cases. Chose uniform capitalization of ConEx. Moved definition of Congestion Volume to list of definitions. Clarified mechanism section. Changed section title. Modified text relating to conex-aware policing and policers (which are NOT defined terms). Re-worded bullet on distinguishing ConEx and non-ConEx traffic in use cases section. Authors' Addresses Bob Briscoe (editor) BT B54/77, Adastral Park Martlesham Heath Ipswich IP5 3RE UK Phone: +44 1473 645196 EMail: bob.briscoe@bt.com URI: http://bobbriscoe.net/ Briscoe, et al. Expires April 24, 2012 [Page 16] =0C Internet-Draft ConEx Concepts & Use Cases October 2011 Richard Woundy (editor) Comcast 1701 John F Kennedy Boulevard Philadelphia, PA 19103 US EMail: richard_woundy@cable.comcast.com URI: http://www.comcast.com Alissa Cooper (editor) CDT 1634 Eye St. NW, Suite 1100 Washington, DC 20006 US EMail: acooper@cdt.org Briscoe, et al. Expires April 24, 2012 [Page 17] =0C --Apple-Mail-12--126554765-- From acooper@cdt.org Thu Feb 2 14:11:47 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0F321F869A for ; Thu, 2 Feb 2012 14:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.058 X-Spam-Level: X-Spam-Status: No, score=-102.058 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UT8GT2ab-TG for ; Thu, 2 Feb 2012 14:11:47 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id B219421F8686 for ; Thu, 2 Feb 2012 14:11:46 -0800 (PST) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Thu, 2 Feb 2012 17:11:43 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Alissa Cooper In-Reply-To: <201201101436.37128.mkuehle@ikr.uni-stuttgart.de> Date: Thu, 2 Feb 2012 17:11:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EC4690C.2060707@it.uc3m.es> <201201101436.37128.mkuehle@ikr.uni-stuttgart.de> To: =?iso-8859-1?Q?Mirja_K=FChlewind?= X-Mailer: Apple Mail (2.1084) Cc: Bob Briscoe , ConEx IETF list Subject: Re: [conex] WGLC for draft-ietf-conex-concepts-uses-03.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 22:11:47 -0000 Hi Mirja, Thanks for your comments. Some replies below. On Jan 10, 2012, at 8:36 AM, Mirja K=FChlewind wrote: > Hi, >=20 > sorry, I'm very late with my comments on the doc mentioned below but = there are=20 > only a few comments: >=20 > The example in "2.2. Congestion-Volume" says the loss propability is = 0,2% and=20 > the congestion volume 2MB. Maybe it's helpful to says more explicit = that 1)=20 > the loss propability is the measurement of the network congestion = (level) and=20 > 2) this is in percent, while the congestion volume depends on the = actual=20 > amount of traffic send by the user and thus is in MB. I'm not really sure what you're asking for here since we say both (1) = and (2) directly prior to the example -- last para of 2.1 explains loss = probability and first para of 2.2 explains that congestion-volume is = measured in bytes. >=20 > Section '2.3. Rest-of-Path Congestion' talks only about ECN as a = congestion=20 > signal and ignores loss. This is by design since rest-of-path congestion cannot be reliably = measured if congestion is signaled with loss (as abstract-mech says). >=20 > In "2.4. Definitions" in the definition of congestion-volume the = following=20 > sentence does not seem to be entirely correct or I don't get it right: > "data volume multiplied by the congestion each packet of the volume=20 > experienced" -> maybe "... multiplied by the mean congestion during = the=20 > measurement time period..."? I think the idea of the second sentence is to provide another way to = conceptualize congestion-volume other than the straight definition in = the first sentence. So the first sentence talks about congestion = measured over a period of time and the second sentence explains the = concept the same way the example does in 2.2.=20 >=20 > Upstream congestion:=20 > s/by a traffic flow thus far/by a traffic flow so far/ ?? Not sure what you mean by this -- to my ear "so far" is a colloquial way = of saying "thus far." >=20 > In 3.1. Use Case Description > "Those users would be expected to react in the typical way to drops, > backing off (assuming use of standard TCP), and thereby lowering > their congestion-volumes back within the quota limits." > If those users would use standard TCP, they would have reacted already = on the=20 > original congestion signal (before a policer can drop anything based = on=20 > ConEx). I though the point is that this mechanism is helpful when a = users=20 > does e.g. not back off on congestion. I think the point is that it can be helpful in either situation, and = this example implicitly assumes that the behavior that triggers policing = is, e.g., a user with many open flows but using standard TCP. In the = scenario described, indeed the users whose packets get dropped by the = policer will have backed off in response to congestion, but the point is = to get them to back off more, because they have more flows and are = therefore congesting the link more than others. Since this is just an example, I don't think we need to exhaustively = list all the effects of the policer. I suggest the following edit to the = sentence above to make the text a little more clear: s/expected/likely/ > And additionally I believe there is a=20 > second important point: a (misbehaving) user can be policed at the = ingress =20 > before the traffic will disturb other users further. >=20 Here is my suggestion: OLD: By deploying a congestion policer at the BRAS location, the network = operator can measure the congestion-volume created by users within the access nodes. NEW: By deploying a congestion policer at the BRAS location, the operator can measure the congestion-volume created by users within the access nodes and police misbehaving users before their traffic affects = others on the access network. > The last paragraph in "3.3. Comparison with Existing Approaches" is = not=20 > entirely clear to me. This sounds like ConEx proposes to use a = per-congestion=20 > pricing. Do we need to talk about flat-rate pricing at all? It mentions pricing, but the point is actually about how ConEx creates = transparency around performance for anyone (user or operator) who cares = to look. I've added a sentence at the end in response to one of Phil's = wglc comments, so perhaps that helps: By exposing congestion information at the IP layer, ConEx instead provides a metric = that can serve as an open, transparent basis for traffic management = policies that both providers and their customers can measure and verify. = It can be used to reduce the performance uncertainty that some users = currently experience. Alissa >=20 > Mirja >=20 >=20 > On Thursday 17 November 2011 02:53:16 marcelo bagnulo braun wrote: >> This note issues the WGLC for draft-ietf-conex-concepts-uses-03.txt. >> (http://www.ietf.org/id/draft-ietf-conex-concepts-uses-03.txt) >>=20 >> Please review the document and send comments before the 5th december. >>=20 >> Thanks, marcelo >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex >=20 >=20 >=20 From john@jlc.net Thu Feb 2 17:14:34 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1CD21F8697 for ; Thu, 2 Feb 2012 17:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.327 X-Spam-Level: X-Spam-Status: No, score=-106.327 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id war+bIp8+mUt for ; Thu, 2 Feb 2012 17:14:33 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id AA33621F867C for ; Thu, 2 Feb 2012 17:14:33 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 840A133C20; Thu, 2 Feb 2012 20:14:33 -0500 (EST) Date: Thu, 2 Feb 2012 20:14:33 -0500 From: John Leslie To: conex@ietf.org Message-ID: <20120203011433.GJ46701@verdi> References: <20120201225647.22307.76083.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120201225647.22307.76083.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.4.1i Subject: [conex] draft-ietf-conex-tcp-modifications-00.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 01:14:34 -0000 internet-drafts@ietf.org wrote: > > Title : TCP modifications for Congestion Exposure > Author(s) : Mirja Kuehlewind > Richard Scheffenegger > Filename : draft-ietf-conex-tcp-modifications-00.txt > Pages : 12 > Date : 2011-12-21 I'd like to concentrate on Section 3. ] 3. Accounting congestion ] ] A TCP sender MUST account congestion byte-wise (and not packet-wise) ] based the congestion information received by ECN or loss detection ] provided by TCP. I am unmoved in my belief this is a bad idea, though I remain willing to make byte-counting vs. packet-counting part of the experiment. ] For this purpose a TCP sender will maintain two different counters for ] number outstanding bytes that need to be ConEx marked either with the ] E bit or the L Bit. Regardless, let's follow this proposal... ] The outstanding bytes accounted based on ECN feedback information are ] maintained in the congestion exposure gauge (CEG). The accounting of ] these bytes from the ECN feedback is explained in more detail next. ] ] The outstanding bytes for congestion indications based on loss are ] maintained in the loss exposure gauge (LEG) and the accounting is ] explained in subsequent to the CEG accounting. ] ] The subtraction of bytes which have been ConEx marked from both ] counters is explained in the next section. (Just so I don't get accused of selective quoting.) ] Usually all byte of an IP packet must be accounted. This invites interoperability questions. What _are_ "all the bytes"? One could guess it includes every last byte of every IPv6 header but none of the Ethernet (or other encapsultion) bytes. But guessing is a really-bad thing here. ] If we assume equal sized packets or at least equally distributed ] packet sizes the sender MAY only account the TCP payload bytes, ] as the ConEx marked packets as well as the original packets causing ] the congestion will both contain about the same number of headers. I don't believe that necessarily follows. Even if it did, it would amount to guess-work. :^( ] Otherwise the sender MUST take the headers into account. That could be a problem. The needed TCP modifications will get implemented in different parts of the system; and in some cases the modified code will have no way to know all the headers that may appear in the packet. But even worse, there are middleboxes that _do_ add headers; and if routing headers are involved, they are liable to be removed partway through the packet's progress. ] A sender which sends different sized packets with unequally ] distributed packet sizes I'm not sure what "unequally distributed packet sizes" means. :^( ] should know about reason to do so and thus may be able to reconstruct ] the exact number of headers based on this information. I don't understand. Assuming the authors meant "exact number of header bytes", I still don't see how this could be more than a guess. ] Otherwise if no additional information is available the worse case ] number of headers SHOULD be estimated in a conservative way based on ] a minimum packet size (of all packets sent in the last RTT). That could get _dreadfully_ conservative. I don't know at exactly what point gross overestimates of congestion volume might become a problem, but it seems at first glance this could run afoul of ISP limits on ConEx marking for a particular class of service. (The rest of Section 3 goes into detail of inferring packet loss which I'd prefer not to go into at this time.) We cannot reasonably require counting bytes unless we define exactly how to count them, and have some reason to believe that two observers along the path will agree on the count. IMHO we're not there yet. Counting packets is _so_ much easier; and I'd _really_ like this WG to discuss the benefits we expect to ensue from counting bytes instead of packets. So far, I don't see sufficient benefits. -- John Leslie From mirja.kuehlewind@ikr.uni-stuttgart.de Fri Feb 3 00:58:06 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F73121F853B for ; Fri, 3 Feb 2012 00:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=0.950, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6oUqs9qjLoJ for ; Fri, 3 Feb 2012 00:58:05 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 83F3321F84C3 for ; Fri, 3 Feb 2012 00:58:05 -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 48D9A633B4; Fri, 3 Feb 2012 09:58:03 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 219C659A8A; Fri, 3 Feb 2012 09:58:03 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: conex@ietf.org Date: Fri, 3 Feb 2012 09:58:01 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <20120201225647.22307.76083.idtracker@ietfa.amsl.com> <20120203011433.GJ46701@verdi> In-Reply-To: <20120203011433.GJ46701@verdi> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201202030958.02017.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: Re: [conex] draft-ietf-conex-tcp-modifications-00.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 08:58:06 -0000 Hi John, just a quick comment for now: I will rework this section and probably relax= =20 some of the MUSTs to SHOULDs as, yes, it is guess-work. But counting packets is guess-work as well. You only now the number of loss= =20 payload bytes at the TCP layer. To estimate how much packets that have been= =20 is as much guessing.... Mirja On Friday 03 February 2012 02:14:33 John Leslie wrote: > internet-drafts@ietf.org wrote: > > Title : TCP modifications for Congestion Exposure > > Author(s) : Mirja Kuehlewind > > Richard Scheffenegger > > Filename : draft-ietf-conex-tcp-modifications-00.txt > > Pages : 12 > > Date : 2011-12-21 > > I'd like to concentrate on Section 3. > > ] 3. Accounting congestion > ] > ] A TCP sender MUST account congestion byte-wise (and not packet-wise) > ] based the congestion information received by ECN or loss detection > ] provided by TCP. > > I am unmoved in my belief this is a bad idea, though I remain willing > to make byte-counting vs. packet-counting part of the experiment. > > ] For this purpose a TCP sender will maintain two different counters for > ] number outstanding bytes that need to be ConEx marked either with the > ] E bit or the L Bit. > > Regardless, let's follow this proposal... > > ] The outstanding bytes accounted based on ECN feedback information are > ] maintained in the congestion exposure gauge (CEG). The accounting of > ] these bytes from the ECN feedback is explained in more detail next. > ] > ] The outstanding bytes for congestion indications based on loss are > ] maintained in the loss exposure gauge (LEG) and the accounting is > ] explained in subsequent to the CEG accounting. > ] > ] The subtraction of bytes which have been ConEx marked from both > ] counters is explained in the next section. > > (Just so I don't get accused of selective quoting.) > > ] Usually all byte of an IP packet must be accounted. > > This invites interoperability questions. What _are_ "all the bytes"? > One could guess it includes every last byte of every IPv6 header but > none of the Ethernet (or other encapsultion) bytes. But guessing is a > really-bad thing here. > > ] If we assume equal sized packets or at least equally distributed > ] packet sizes the sender MAY only account the TCP payload bytes, > ] as the ConEx marked packets as well as the original packets causing > ] the congestion will both contain about the same number of headers. > > I don't believe that necessarily follows. Even if it did, it would > amount to guess-work. :^( > > ] Otherwise the sender MUST take the headers into account. > > That could be a problem. The needed TCP modifications will get > implemented in different parts of the system; and in some cases the > modified code will have no way to know all the headers that may > appear in the packet. > > But even worse, there are middleboxes that _do_ add headers; and > if routing headers are involved, they are liable to be removed partway > through the packet's progress. > > ] A sender which sends different sized packets with unequally > ] distributed packet sizes > > I'm not sure what "unequally distributed packet sizes" means. :^( > > ] should know about reason to do so and thus may be able to reconstruct > ] the exact number of headers based on this information. > > I don't understand. Assuming the authors meant "exact number of > header bytes", I still don't see how this could be more than a guess. > > ] Otherwise if no additional information is available the worse case > ] number of headers SHOULD be estimated in a conservative way based on > ] a minimum packet size (of all packets sent in the last RTT). > > That could get _dreadfully_ conservative. > > I don't know at exactly what point gross overestimates of congestion > volume might become a problem, but it seems at first glance this could > run afoul of ISP limits on ConEx marking for a particular class of > service. > > (The rest of Section 3 goes into detail of inferring packet loss > which I'd prefer not to go into at this time.) > > We cannot reasonably require counting bytes unless we define exactly > how to count them, and have some reason to believe that two observers > along the path will agree on the count. IMHO we're not there yet. > > Counting packets is _so_ much easier; and I'd _really_ like this > WG to discuss the benefits we expect to ensue from counting bytes > instead of packets. So far, I don't see sufficient benefits. > > -- > John Leslie > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From tm444@hermes.cam.ac.uk Fri Feb 3 02:18:49 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058A621F85D1 for ; Fri, 3 Feb 2012 02:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZqIFEP701hx for ; Fri, 3 Feb 2012 02:18:48 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id C625F21F8595 for ; Fri, 3 Feb 2012 02:18:47 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ravage.cl.cam.ac.uk ([128.232.1.17]:58573) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpsa (PLAIN:tm444) (TLSv1:AES128-SHA:128) id 1RtGEA-00037W-Wf (Exim 4.72) (return-path ); Fri, 03 Feb 2012 10:18:46 +0000 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Toby Moncaster In-Reply-To: <201202030958.02017.mirja.kuehlewind@ikr.uni-stuttgart.de> Date: Fri, 3 Feb 2012 10:18:43 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120201225647.22307.76083.idtracker@ietfa.amsl.com> <20120203011433.GJ46701@verdi> <201202030958.02017.mirja.kuehlewind@ikr.uni-stuttgart.de> To: Mirja Kuehlewind X-Mailer: Apple Mail (2.1251.1) Sender: "T. Moncaster" Cc: conex@ietf.org Subject: Re: [conex] draft-ietf-conex-tcp-modifications-00.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 10:18:49 -0000 On 3 Feb 2012, at 08:58, Mirja Kuehlewind wrote: > Hi John, >=20 > just a quick comment for now: I will rework this section and probably = relax=20 > some of the MUSTs to SHOULDs as, yes, it is guess-work. >=20 > But counting packets is guess-work as well. You only now the number of = loss=20 > payload bytes at the TCP layer. To estimate how much packets that have = been=20 > is as much guessing=85. And in fact you only know the number of packets the TCP sender /thinks/ = are lost.=20 In actual fact though, TCP IS a byte stream, not a packet stream so to = say accounting should be done byte wise is arguably in the spirit of = TCP. I would be interested to hear the views of someone in TCPM (I used = to be, but not for 3 years or so). Toby PS I personally feel packets is correct from a purely pragmatic = engineering perspective (in other words, in the IETF spirit rather than = the IRTF spirit) >=20 > Mirja >=20 >=20 > On Friday 03 February 2012 02:14:33 John Leslie wrote: >> internet-drafts@ietf.org wrote: >>> Title : TCP modifications for Congestion Exposure >>> Author(s) : Mirja Kuehlewind >>> Richard Scheffenegger >>> Filename : draft-ietf-conex-tcp-modifications-00.txt >>> Pages : 12 >>> Date : 2011-12-21 >>=20 >> I'd like to concentrate on Section 3. >>=20 >> ] 3. Accounting congestion >> ] >> ] A TCP sender MUST account congestion byte-wise (and not = packet-wise) >> ] based the congestion information received by ECN or loss detection >> ] provided by TCP. >>=20 >> I am unmoved in my belief this is a bad idea, though I remain = willing >> to make byte-counting vs. packet-counting part of the experiment. >>=20 >> ] For this purpose a TCP sender will maintain two different counters = for >> ] number outstanding bytes that need to be ConEx marked either with = the >> ] E bit or the L Bit. >>=20 >> Regardless, let's follow this proposal... >>=20 >> ] The outstanding bytes accounted based on ECN feedback information = are >> ] maintained in the congestion exposure gauge (CEG). The accounting = of >> ] these bytes from the ECN feedback is explained in more detail next. >> ] >> ] The outstanding bytes for congestion indications based on loss are >> ] maintained in the loss exposure gauge (LEG) and the accounting is >> ] explained in subsequent to the CEG accounting. >> ] >> ] The subtraction of bytes which have been ConEx marked from both >> ] counters is explained in the next section. >>=20 >> (Just so I don't get accused of selective quoting.) >>=20 >> ] Usually all byte of an IP packet must be accounted. >>=20 >> This invites interoperability questions. What _are_ "all the = bytes"? >> One could guess it includes every last byte of every IPv6 header but >> none of the Ethernet (or other encapsultion) bytes. But guessing is a >> really-bad thing here. >>=20 >> ] If we assume equal sized packets or at least equally distributed >> ] packet sizes the sender MAY only account the TCP payload bytes, >> ] as the ConEx marked packets as well as the original packets causing >> ] the congestion will both contain about the same number of headers. >>=20 >> I don't believe that necessarily follows. Even if it did, it would >> amount to guess-work. :^( >>=20 >> ] Otherwise the sender MUST take the headers into account. >>=20 >> That could be a problem. The needed TCP modifications will get >> implemented in different parts of the system; and in some cases the >> modified code will have no way to know all the headers that may >> appear in the packet. >>=20 >> But even worse, there are middleboxes that _do_ add headers; and >> if routing headers are involved, they are liable to be removed = partway >> through the packet's progress. >>=20 >> ] A sender which sends different sized packets with unequally >> ] distributed packet sizes >>=20 >> I'm not sure what "unequally distributed packet sizes" means. :^( >>=20 >> ] should know about reason to do so and thus may be able to = reconstruct >> ] the exact number of headers based on this information. >>=20 >> I don't understand. Assuming the authors meant "exact number of >> header bytes", I still don't see how this could be more than a guess. >>=20 >> ] Otherwise if no additional information is available the worse case >> ] number of headers SHOULD be estimated in a conservative way based = on >> ] a minimum packet size (of all packets sent in the last RTT). >>=20 >> That could get _dreadfully_ conservative. >>=20 >> I don't know at exactly what point gross overestimates of = congestion >> volume might become a problem, but it seems at first glance this = could >> run afoul of ISP limits on ConEx marking for a particular class of >> service. >>=20 >> (The rest of Section 3 goes into detail of inferring packet loss >> which I'd prefer not to go into at this time.) >>=20 >> We cannot reasonably require counting bytes unless we define = exactly >> how to count them, and have some reason to believe that two observers >> along the path will agree on the count. IMHO we're not there yet. >>=20 >> Counting packets is _so_ much easier; and I'd _really_ like this >> WG to discuss the benefits we expect to ensue from counting bytes >> instead of packets. So far, I don't see sufficient benefits. >>=20 >> -- >> John Leslie >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex >=20 >=20 >=20 > --=20 > ------------------------------------------------------------------- > Dipl.-Ing. Mirja K=FChlewind > Institute of Communication Networks and Computer Engineering (IKR) > University of Stuttgart, Germany > Pfaffenwaldring 47, D-70569 Stuttgart >=20 > 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 john@jlc.net Fri Feb 3 06:18:50 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE20A21F8540 for ; Fri, 3 Feb 2012 06:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.339 X-Spam-Level: X-Spam-Status: No, score=-106.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oCU-KvCqM1V for ; Fri, 3 Feb 2012 06:18:50 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id C057121F852B for ; Fri, 3 Feb 2012 06:18:49 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 11C5433C23; Fri, 3 Feb 2012 09:18:49 -0500 (EST) Date: Fri, 3 Feb 2012 09:18:49 -0500 From: John Leslie To: Toby Moncaster Message-ID: <20120203141848.GL46701@verdi> References: <20120201225647.22307.76083.idtracker@ietfa.amsl.com> <20120203011433.GJ46701@verdi> <201202030958.02017.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] draft-ietf-conex-tcp-modifications-00.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 14:18:50 -0000 Toby Moncaster wrote: > On 3 Feb 2012, at 08:58, Mirja Kuehlewind wrote: > >> just a quick comment for now: I will rework this section and probably >> relax some of the MUSTs to SHOULDs as, yes, it is guess-work. >> >> But counting packets is guess-work as well. You only know the number >> of loss payload bytes at the TCP layer. To estimate how much packets >> that have been is as much guessing?. Thank you! This is a good basis for discussion. TCP indeed "thinks" strictly in bytes in interfacing to upper layers, and acknowledgments from the receiver are denominated in bytes. Thus viewing congestion in bytes is reasonable. > And in fact you only know the number of packets the TCP sender /thinks/ > are lost. Emphasis on the "lost"... Let us not forget the assumption in TCP congestion-control that the losses indicate congestion -- while in fact we know there are other reasons packets get lost. > In actual fact though, TCP IS a byte stream, not a packet stream so > to say accounting should be done byte wise is arguably in the spirit > of TCP. Of course, TCP "is" a byte stream to upper layers, and a packet stream to lower layers... But yes, accounting in terms of bytes probably _is_ "in the spirit of TCP". However, IMHO, we shouldn't be aiming for the spirit of TCP -- rather we should aim for the spirit of IP. After all, we want our work to be useful for transports other than TCP eventually. To the ISP (which is where I'm coming from), congestion is a matter of packets, not bytes: there's no significant difference between big packets and small packets in the congestion they may encounter. I would like to see something akin to back-pressure telling me that traffic to a particular destination is congested (not merely showing packet loss which may be due to excessive noise instead of congestion). Will I ever see that -- perhaps not, but I can still wish for it. I'm definitely glad we're proposing to notate loss separately from ECN marking in ConEx marking. Probably Mirja and others enjoy figuring out how to infer congestion in the absence of ECN or other explicit congestion signals -- to me, this is uninteresting and possibly mis-directed. (But I'm glad someone is working on that!) > I would be interested to hear the views of someone in TCPM (I used to > be, but not for 3 years or so). We could work on how to ask them, but someone actually active there should pose the question. Perhaps something to the effect of " " The folks in ConEx are working on how to account for congestion along " the path from sender to receiver, in a manner visible to all nodes. " There is discussion about whether it's better to count bytes or " packets. Do any of you want to chime in on that? > PS I personally feel packets is correct from a purely pragmatic > engineering perspective (in other words, in the IETF spirit rather > than the IRTF spirit) Of course I agree -- and I'd argue that this is an IETF WG, not an IRTF RG... -- John Leslie From marcelo@it.uc3m.es Thu Feb 23 23:28:13 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E9021E8020 for ; Thu, 23 Feb 2012 23:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jno7MlnGniQ for ; Thu, 23 Feb 2012 23:28:12 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 753D521E800C for ; Thu, 23 Feb 2012 23:28:11 -0800 (PST) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 96FF39C63A3 for ; Fri, 24 Feb 2012 08:28:10 +0100 (CET) Message-ID: <4F473C0A.6000206@it.uc3m.es> Date: Fri, 24 Feb 2012 08:28:10 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: 'ConEx IETF list' References: <20120223205740.16792.69130.idtracker@ietfa.amsl.com> In-Reply-To: <20120223205740.16792.69130.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120223205740.16792.69130.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18730.003 Subject: [conex] Fwd: conex - Requested session has been scheduled for IETF 83 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 07:28:13 -0000 fyi -------- Mensaje original -------- Asunto: conex - Requested session has been scheduled for IETF 83 Fecha: Thu, 23 Feb 2012 12:57:40 -0800 De: "IETF Secretariat" Para: marcelo@it.uc3m.es CC: conex-ads@tools.ietf.org, conex-chairs@tools.ietf.org, wlo@amsl.com Dear Marcelo Bagnulo, The sessions that you have requested have been scheduled. Below is the scheduled session information followed by the original request. conex Session 1 (2 hours) Thursday, Afternoon Session III 1740-1940 Room Name: 253 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Congestion Exposure Area Name: Transport Area Session Requester: Wanda Lo Number of Sessions: 1 Length of Session(s): 2 hours Number of Attendees: 200 Conflicts to Avoid: First Priority: savi mptcp tcpm homenet Second Priority: grow idr pcn tsvwg tsvarea BOF or IRTF Session: ICCRG, Complexity RG Special Requests: We can live with 2 slots of one hour if that facilitates the scheduling ---------------------------------------------------------