| ConEx | B. Briscoe, Ed. |
| Internet-Draft | BT |
| Intended status: Informational | R. Woundy, Ed. |
| Expires: January 13, 2012 | Comcast |
| July 12, 2011 |
ConEx Concepts and Use Cases
draft-ietf-conex-concepts-uses-02
This document provides the entry point to the set of documentation on a new Congestion Exposure (ConEx) protocol. It motivates a new ConEx field at the IP layer, focusing on the 'why' rather than the 'how'. In the absence of such a protocol, traffic is subjected to numerous traffic management checks and limits as it crosses the Internet. The purpose of this protocol is to expose congestion to network operators, so that they have no need to intervene at all when there is no congestion, and so they have exactly the right information when there is congestion. Then it will at least be possible for traffic management to be application-neutral, openly transparent and free of unnecessary restraints. Although traffic management is the focus of this document, it also briefly introduces a number of other important potential uses for ConEx, demonstrating its role as a generative technology and justifying its placement in the IP layer.
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 January 13, 2012.
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 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.
The power of Internet technology comes from multiplexing shared capacity with packets rather than circuits. Network operators usually provide sufficient shared capacity, but whenever too much packet load meets too little shared capacity, congestion results. Congestion appears as either increased delay, missing packets or packets explicitly marked with ECN [RFC3168]. Referring to 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 meant to reduce its rate in response.
This document provides the entry point to the set of documentation on Congestion Exposure (ConEx). It motivates a new ConEx field at the IP layer, focusing on the 'why' rather than the 'how'. A companion document about the ConEx protocol mechanism gives the 'how' [ConEx-Abstract-Mech]. 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). Certain IP layer devices can then use this new information, for example as input to traffic management.
,---------. ,---------. |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-------->| | | | | | / | | | |_____________| |_______________ / | | | | | | |/ | | `---------' `-----------' ' `---------'
Current traffic management solutions limit traffic based on either bit-rate or volume. For instance, weighted fair queuing (based on [RFC0970]) shares out bit-rate when a link is congested. However it fails to consider how much of the time a consumer keeps the link busy, which is the main factor that determines everyone else's bit-rate. To try to address this issue, many network operators have introduced volume limits. However, these tend to be either not strict enough during congested periods, or unnecessarily strict when traffic is light.
Because each solution only partially addresses the problem, operators keep adding more solutions. So a data path across the Internet often encounters numerous blockages and throttles in each network it crosses. This clutter is actually a symptom of a deeper underlying problem: neither bit-rate nor volume is the right metric.
Traffic management would be so much better (and simpler) if congestion were visible in packets. Then, whenever congestion was not present, all restraints could be removed, leaving the full capacity available to everyone. But if some excessive users were causing a lot of congestion, the traffic management function would know and be able to directly limit their traffic, in order to protect the service of other users sharing the same capacity.
ConEx exposes exactly the right information for this, in the IP layer. It reveals a consumer's overall contribution to congestion, which is a direct measure of how much one user affects others. ConEx makes this easy to measure—as easy as counting straight volume, except you only count the volume of packets with ConEx markings. With the right metric visible, traffic management would only have to be done once on a path because it would be done well.
In the absence of the right metric, some operators have deployed deep packet inspection (DPI) equipment; not just in the public Internet but also in enterprise and campus networks. Their main aim has been to identify and limit specific types of application that they associate with heavy usage.
With ConEx, a network operator can manage traffic without dipping into the higher layers, because ConEx makes the relevant bulk congestion information accessible at the IP layer. This solves two problems that have made DPI controversial: traffic management can be application-neutral and compatible with IPsec encryption.
Also, because ConEx information is added explicitly at the IP layer, it is visible to provider and consumer alike. Therefore traffic contracts or acceptable use policies can be based on a quantifiable metric that is open and transparent to both parties, so that it will be sufficient to manage traffic without extra non-transparent wriggle-room and caveats.
To summarise so far, ConEx is designed to make it simple to do traffic management that is transparent, neutral and free of unnecessary restraints. Although it is not our place to make a network provider meet these requirements, ConEx is designed to make this the simplest service to provide.
{ToDo: review this para when done and shorten} This introduction has focused on traffic management as the main use for ConEx. However, ConEx is intended as a generative technology, with a wider range of potential uses. The document structure reflects this. Section 3 overviews existing approaches to traffic management and Section 4 explains why exposing congestion would address their limitations. Section 5 introduces the main use-cases for ConEx: traffic management, incentivising scavenger transports and intra-class quality of service as well as briefly mentioning others. Then Section 6 presents how how the above use-cases might drive deployment of ConEx. Finally, Section 7 discusses a number of potential issues (and non-issues) that are often raised about ConEx, before the usual tailpiece sections in conclusion.
But before all this, Section 2 introduces the basic concepts necessary to understand ConEx, as well as dispelling a number of common misconceptions.
Despite its central role in network control and management, congestion is a remarkably hard concept to define. [Bauer09] provides a good academic background. For the purposes of ConEx, the definition below focuses on how congestion would be measured, rather than precisely what it is. Our definition of congestion is then equivalent to the loss probability (or the marking probability if ECN is used).
ConEx is essentially about accountability for congestion (or blame in crude language). The blame for congestion lies equally between too little capacity and too much traffic. On the capacity side, congestion itself measures how badly the network provider is to blame. On the traffic side, in a shared network, the blame is split among all the users. Congestion-volume measures how much of each user's traffic is to blame for the congestion. Note that congestion-volume is a property of traffic, whereas congestion is a property of a link or a path.
Congestion-volume is a relatively newly defined metric that is central to ConEx. To grasp an intuitive feel for what congestion-volume measures, some network operators give you an allowance and only count data volume during the peak period against it. This is equivalent to counting your congestion-volume by assuming that congestion is 100% during the peak period and 0% otherwise.
The congestion-volume metric is more refined but broadly equivalent to the above time-of-day volume example and still as simple to measure. Imagine Alice sends 1GB while the loss-probability is a constant 0.2%. Then her contribution to congestion (or congestion-volume) is 1GB x 0.2% = 2MB. If she then sends 3GB while congestion is 0.1%, this adds 3MB to her congestion-volume. Her total contribution to congestion is then 2MB+3MB = 5MB.
To measure Alice's congestion-volume no-one has to do all these multiplications and additions. It is simply a matter of counting the total volume of Alice's traffic that was discarded (a queue with a percentage loss involves multiplication inherently).
Finally, there is yet another way to cut the blame for congestion. Recall that the level of congestion itself measures the provider's blame. However, in an internetwork there are multiple providers. If a data centre network with zero congestion is connected to an access network and sends traffic over a link with 0.4% loss probability, then clearly all the blame for congestion lies with the access network. However, at another time, there might be 0.1% congestion across the data centre and 0.7% across the access, making 0.8% end-to-end congestion across the path.
In order to apportion blame accordingly, ConEx information is placed in the IP layer so that a simple border meter can see how much of the congestion is on one side or other, termed upstream and downstream congestion.
If A and B are connected within a chain of more than two networks, A attributes all congestion beyond B to B, and vice versa. As far as A is concerned, B chooses who to route to, so B takes responsibility for its choices.
[ConEx-Abstract-Mech] gives further definitions for aspects of ConEx to do with protocol mechanisms.
Congestion exposure is about the transport sender exposing congestion to the network, not the other way round. That would not make sense given by design the transport endpoints handle congestion in the TCP/IP protocol suite.
Nonetheless, it is a non-goal for IP layer devices to use this ConEx information to do fine-grained congestion control. That is still best done at the transport sender. There is also no expectation that the information will be used by every IP router and forwarding device. More likely, specific ConEx-based functions like traffic management will be added to edge routers. This in turn should incentivize end-system transports to be more careful about congesting others.
Note that good behaviour at individual flow granularity is the intended outcome, not the forcing function—it is the end, not the means. Enforcing per-flow compliance to the TCP congestion response (or any per-flow rate enforcement) is a non-goal:
Therefore, network enforcement of per-flow fairness is not only a non-goal, it would be a harmful goal in many respects.
Capacity provisioning is another area of confusion in relation to ConEx. Congestion-based traffic management is not an alternative to good capacity provisioning. Either or both can be good practice depending on the situation, and ConEx can provide a useful metric for both (see Section 5.4).
Any network that is persistently highly congested is inefficient. However, the total absence of congestion from all parts of a network is equally inefficient. If an end-to-end transport protocol cannot go fast enough to find a bottleneck somewhere along the path—typically in an access network—it is probably broken. The long-standing aim of congestion control has been to find the healthy point of balance with a low level of congestion somewhere on the path. Just to be clear though, zero congestion somewhere else (e.g. the core) is also perfectly healthy.
Since 1988 congestion management has been the responsibility of the end-systems in the Internet architecture. The network signals congestion to the receiver, the receiver feeds this back to the sender and the sender is expected to reduce the traffic it sends.
Nonetheless, since at least when Nagle proposed fair queuing in 1985 [RFC0970], it has been recognised that end-systems alone cannot be entrusted with sharing out capacity between themselves.
Since then capacity has been shared by a mix of traffic management approaches, partly network-based (weighted round-robin scheduling, weighted fair queuing, etc) and partly host-based (TCP). However, in recent years, network operators became concerned that a relatively small number of end-machines were consuming a disproportionately high share of network resources. This is actually because both TCP and all the traditional network-based approaches only share out a bottleneck at each instant. They fail to take account of how much of the time a consumer is keeping the link busy, which is the main factor that determines everyone else's bit-rate.
As a result, some network operators introduced additional limits based on data volume transferred over time. These also were generally too blunt an instrument, because they counted volume whether or not it was sent at a congested time that would limit other users. Some operators have therefore tried to address this perceived problem by introducing further traffic management boxes that artificially starve certain types of traffic that they associate with heavy usage.
Beyond this brief history, the authors have chosen not to exhaustively list current approaches to traffic management. Broadly they can be divided into those that happen at Layer 3 of the OSI model and those that use information gathered from higher layers. In general these approaches attempt to find a "proxy" measure for congestion. Layer 3 approaches include:
Higher layer approaches include:
All of these current approaches suffer from some general limitations. First, they introduce 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 connection is being altered or degraded based on how the network operator is attempting to manage congestion.
Second, none of the approaches is able to make use of what may be the most important factor in managing congestion: the amount that a given endpoint contributes to congestion on the network. This information simply is not available to network nodes, and neither volume nor rate nor application usage is an adequate proxy for congestion-volume, because none of these metrics measures a consumer's or network's actual contribution to congestion on the network.
Finally, none of these solutions accounts for inter-network congestion. Mechanisms may exist that allow an operator to identify and mitigate congestion in their own network, but the design of the Internet means that only the end-hosts have full visibility of congestion information along the whole path. ConEx allows this information to be visible to everyone on the path and thus allows operators to make better-informed decisions about controlling traffic.
We argue that current traffic-control mechanisms seek to control the wrong quantity. What matters in the network is neither the volume of traffic nor the rate of traffic: it is the contribution to congestion over time — congestion means that your traffic impacts other users, and conversely that their traffic impacts you. So if there is no congestion there need not be any restriction on the amount a user can send; restrictions only need to apply when others are sending traffic such that there is congestion.
For example, an application intending to transfer large amounts of data could use a congestion control mechanism like [LEDBAT] (Low Extra Delay BAckground Transport) to reduce its transmission rate before any competing TCP flows do, by detecting an increase in end-to-end delay (as a measure of impending congestion). Currently, such techniques rely on voluntary, altruistic action by end users and their application providers. Operators cannot encourage their use, and worse, they penalize such applications for the large amount of volume they send rather than rewarding them for carefully avoiding congestion while sending it.
The Internet was designed so that end-hosts detect and control congestion. We argue that congestion needs to be visible to network nodes as well, not just to the end hosts. More specifically, a network needs to be able to measure how much congestion any particular traffic expects to cause between the monitoring point in the network and the destination ("rest-of-path congestion"). This would be a new capability. Today a network can use Explicit Congestion Notification (ECN) [RFC3168] to detect how much congestion the traffic has suffered between the source and a monitoring point ("upstream congestion"), but not beyond. This new capability would enable an ISP to give incentives for the use of LEDBAT-like applications that seek to minimise congestion in the network whilst also being able to determine if excessive use of traditional UDP or even TCP applications was contributing excessively to congestion.
So we propose a new approach which we call Congestion Exposure. We propose that congestion information should be made visible at the IP layer, so that any network node can measure the contribution to congestion of an aggregate of traffic as easily as straight volume can be measured today. Once the information is exposed in this way, it is then possible to use it to measure the true impact of any traffic on the network.
In general, congestion exposure gives operators a principled way to hold their customers accountable for the impact on others of their network usage and reward them for choosing congestion-sensitive applications.
Explicit Congestion Notification [RFC3168] allows routers to explicitly tell end-hosts that they are approaching the point of congestion. ECN builds on Active Queue Mechanisms such as random early detection (RED) [RFC2309] by allowing the router to mark a packet with a Congestion Experienced (CE) codepoint, rather than dropping it. The probability of a packet being marked increases with the length of the queue and thus the rate of CE marks is a guide to the level of congestion at that queue. This CE codepoint travels forward through the network to the receiver which then informs the sender that it has seen congestion. The sender is then required to respond as if it had experienced a packet loss. Because the CE codepoint is visible in the IP layer, this approach reveals the upstream congestion level for a packet.
Alas, this is not enough - ECN gives a network node an idea of the congestion experienced on the path up to that node. If this network node were near a receiver, it could help hold that receiver accountable for the congestion caused by incoming traffic. But a receiver can only indirectly influence incoming congestion, by politely asking the sender to control it. A receiver cannot make a sender install an adaptive codec, or install LEDBAT instead of TCP congestion-control. And a receiver cannot cause an attacker to stop flooding it with traffic.
What is needed is knowledge of the downstream congestion level relative to the node in the network that is measuring it. That is, the congestion expected from that point along the rest of the path to the receiver. This requires additional information that is still concealed from the network, but which ConEx is designed to reveal.
This section sets out some of the potentially most important use cases for ConEx. These use cases rely on some of the components described in [ConEx-Abstract-Mech]. The authors don't claim this is an exhaustive list of use cases, nor that they have equal merit. But these use cases represent a consensus among people that have been working on this approach for some years.
Currently many operators impose some form of traffic management. They consider this as an economic necessity particularly at peak hours— the only reason their networks work as a commercial concern is that they can rely on statistical multiplexing to share their expensive network between large numbers of customers. In order to ensure all customers get decent performance from the network, they subject the "heaviest" customers to some form of traffic management (see Existing Approaches to Traffic Management in Section 3.1). Often multiple approaches are added on top of each other, including resorting to expensive flow aware devices such as DPI boxes or flow-aware routers. This is probably a sign that none of the approaches are really addressing the problem properly.
ConEx offers a better approach that will actually target the traffic from consumers that contribute most to any congestion, and otherwise stand aside without intervening. By using Ingress or Egress Policers, an operator can identify which consumers are causing the greatest congestion-volume throughout the network. This can then be used as the basis for traffic management decisions. The Ingress Policer described in [Policing-freedom] is one interesting approach that gives the consumer a congestion-volume allowance as the fill-rate of a token-bucket, but where the tokens give the right to cause bits of congestion-volume, rather than to send bits of data-volume. So long as consumers stay within their limit, then their traffic is unaffected. Once they exceed that limit then their traffic will be slowed temporarily.
Recent work proposes a new approach for QoS where traffic is provided with a less than best effort or "scavenger" quality of service. The idea is that low priority but high volume traffic such as OS updates, P2P file transfers and view-later TV programs should be allowed to use any spare network capacity, but should rapidly get out of the way if a higher priority or interactive application starts up. To a degree, this facility can be provided in the network. Low Extra Delay BAckground Transport [LEDBAT] is an example of a new type of solution being actively explored which proposes that hosts can provide this scavenger service for themselves using a new congestion control algorithm. LEDBAT yields when seeking out bandwidth if it detects that delay is rising, and other similar protocols share capacity less aggressively when competing with protocols like TCP.
At present most operators assume a strong correlation between the volume of a flow and the impact that flow causes in the network. This assumption can fail badly for protocols like LEDBAT that transfer large volumes of data but yield if congestion approaches. At the other extreme, this assumption is eroded by unresponsive interactive streaming which is unresponsive to congestion (inelastic) and hence can cause high congestion at relatively low data volumes. LEDBAT-like transports can transfer large volumes of data and may reach high transfer speeds if the network is uncongested. Therefore network operators who use volume or bit-rate to judge the impact of traffic on their network give these protocols no encouragement, when they ought to welcome them. Consequently the only current incentive for LEDBAT is that it can reduce self-congestion effects (see Section 7.2).
If the network operator has deployed a ConEx-aware Ingress Policer then they are able to incentivise the use of LEDBAT because a user will be policed according to the overall congestion-volume their traffic generates, not the rate or data volume. If all background file transfers are only generating a low level of congestion, then the sender has more "congestion budget" to "spend" on their interactive applications. It can be shown [Kelly] that this approach improves social welfare—in other words if you limit the congestion that all users can generate then everyone benefits from a better service.
Most QoS approaches require the active participation of routers to control the delay and loss characteristics for the traffic. For real-time interactive traffic it is clear that low delay (and predictable jitter) are critical, and thus these probably always need different treatment at a router. However if low loss is the issue then ConEx offers an alternative approach.
Assuming the ingress ISP has deployed a ConEx Ingress Policer, then the only control on a user's traffic is dependent on the congestion that user has caused. Likewise, if they are receiving traffic through a ConEx Egress Policer then their ISP will impose traffic controls (prioritisation, rate limiting, etc) based on the congestion they have caused. If an end-user (be they the receiver or sender) wants to prioritise some traffic over other traffic then they can allow that traffic to generate or cause more congestion. The price they will pay will be to reduce the congestion that their other traffic causes.
Streaming video content-delivery is a good candidate for such ConEx-mediated QoS. Such traffic can tolerate moderately high delays, but there are strong economic pressures to maintain a high enough data rate (as that will directly influence the Quality of Experience the end-user receives. This approach removes the need for bandwidth brokers to establish QoS sessions, by removing the need to coordinate requests from multiple sources to pre-allocate bandwidth, as well as to coordinate which allocations to revoke when bandwidth predictions turn out to be wrong. There is also no need to "rate-police" at the boundaries on a per-flow basis, removing the need to keep per-flow state (which in turn makes this approach more scalable).
This document is about concepts and use-cases, not mechanism. However, in order to describe how the above use-cases would be deployed, a high-level understanding of ConEx mechanism is first given below.
The ConEx mechanism document [ConEx-Abstract-Mech] goes to great lengths to design for incremental deployment in all the respects below. It should be referred to for precise details on each of these points:
Network deployment-related definitions:
Each network can unilaterally choose to use any ConEx information given by those sources using ConEx, independently of whether other networks use it.
Typically, a network will use ConEx information by deploying a policy function at the ingress edge of its network to monitor arriving traffic and to act in some way on the congestion information in those packets that are ConEx-enabled. Actions might include policing, altering the class of service, or re-routing. Alternatively, less direct actions via a management system might include triggering capacity upgrades, triggering penalty clauses in contracts or levying charges between networks based on ConEx measurements.
{ToDO: I need to sleep, so I'll resort to bullets for the rest...}
Audit: what it is (checks ConEx info is never less than actual congestion so far on the path). If ConEx protocol is adhered to, there should be no place in a network where this is not true, so audit can be placed wherever most convenient. But most useful placement is after the likely congestion locations, ideally as close to the egress as possible.
Typically, a network using ConEx info will deploy a ConEx policy function near the ingress edge and a ConEx audit function near the egress edge. The segment of the path between a ConEx policy function and a ConEx audit function can be considered to be a ConEx-protected segment of the path. And assuming a network covers all its ingresses and egresses with policy functions and audit functions respectively, the network within this ring will be a ConEx-protected network.
Of course, because each edge device usually serves as both an ingress and an egress, the two functions are both likely to be present in each edge device.
[Plan view diagram of a ConEx-protected segment and ConEx-protected network here?]
[We might have to explain the concept of non-negativity of congestion earlier in the doc, so we can use it here. Could also require one of those staircase diags I used in re-ECN, but that assume ECN and ConEx - I'd rather focus on drop-only cases.]
Sources can choose not to send ConEx-enabled packets. Networks are expected to make it in senders' interests to expose congestion information in packets by treating ConEx-enabled packets better (in some sense) than non-ConEx packets.
Prior to ConEx, networks have generally place constraints on incoming traffic to reduce the chances of it causing congestion. For ConEx-enabled traffic, networks can remove these pessimistic constraints and solely apply constraints when the ConEx information indicates traffic is contributing to congestion.
Charter scenario [Description, picture and some deployment incentive text]
Focusing on first step: why OS developers of senders would implement and why users would send ConEx. Then, once info is there, why network would use it.
Network operators have long viewed the congestion levels in their network as a business secret. In some ways this harks back to the days of fixed-line telecommunications where congestion manifested as failed connections or dropped calls. But even in modern data-centric packet networks congestion is viewed as a secret not to be shared with competitors. It can be debated whether this view is sensible, but it may make operators uneasy about deploying ConEx. The following two examples highlight some of the arguments used:
Of course some might say that the idea of keeping congestion secret is silly. After all, end-hosts already have knowledge of the congestion throughout the network, albeit only along specific paths, and operators can work out that there is persistent congestion as their customers will be suffering degraded network performance.
{ToDo: The following para has been moved here from the Introduction. Re-phrase as an issue}
Congestion takes two distinct forms. The first results from the interaction of traffic from one set of users with traffic from other users, causing in a reduction in service (a cost) for all of them. the second, often referred to as "self-congestion", occurs when an increase in traffic from a single user causes that user to suffer a worse service (for instance because their traffic is being "shaped" by their ISP, or because they have an excessively large buffer in their home router). ConEx is principally interested in the first form of congestion since it involves informing those other users of the impact you expect to have on them.
This document proposes a mechanism tagging onto Explicit Congestion Notification [RFC3168], and inherits the security issues listed therein. The additional issues from ConEx markings relate to the degree of trust each forwarding point places in the ConEx markings it receives, which is a business decision mostly orthogonal to the markings themselves.
One expected use of exposed congestion information is to hold the end-to-end transport and the network accountable to each other. The network cannot be relied on to report information to the receiver against its interest, and the same applies for the information the receiver feeds back to the sender, and that the sender reports back to the network. Looking at each in turn:
In addition there are potential problems from source spoofing. A malicious sender can pretend to be another user by spoofing the source address. Congestion Exposure allows for "Policers" and "Traffic Shapers" so as to be robust against injection of false congestion information into the forward path.
make a source believe it has seen more congestion than it has
hijack a user's identity and make it appear they are dishonest at an egress policer
clear or otherwise tamper with the ConEx markings
...
{ToDo} Write these up properly...
This document does not require actions by IANA.
{ToDo}
Bob Briscoe is 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, João Taveira Araújo, Marcelo Bagnulo Braun, Steve Bauer, Caitlin Bestler, Steven Blake, Louise Burness, Ken Carlberg, Alissa Cooper, Nandita Dukkipati, Philip Eardley, Wes Eddy, Matthew Ford, Ingemar Johansson, Georgios Karagiannis, Mirja Kuehlewind, Dirk Kutscher, Zhu Lei, Kevin Mason, Matt Mathis, David McDysan, Michael Menth, Chris Morrow, Tim Shepard, Hannes Tschofenig and Stuart Venters. Please accept our apologies if your name has been missed off this list.
The following co-edited this document through most of its life:
Toby Moncaster Moncaster Internet Consulting Dukes Layer Marney Colchester CO5 9UZ UK EMail: toby@moncaster.com John Leslie JLC.net 10 Souhegan Street Milford, NH 03055 US EMail: john@jlc.net