One document matched: draft-briscoe-tsvwg-re-ecn-tcp-00.txt
Transport Area Working Group B. Briscoe
Internet-Draft BT & UCL
Expires: April 20, 2006 A. Jacquet
A. Salvatori
BT
October 17, 2005
Re-ECN: Adding Accountability for Causing Congestion to TCP/IP
draft-briscoe-tsvwg-re-ecn-tcp-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 20, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document introduces a new feedback protocol for explicit
congestion notification (ECN), termed re-ECN. It arranges the ECN
field of each packet so that, as it arrives at each router, the
relative rates of each codepoint will give a truthful prediction of
congestion on the remainder of the path. It also outlines mechanisms
at the network edge that ensure the dominant selfish strategy of both
Briscoe, et al. Expires April 20, 2006 [Page 1]
Internet-Draft Re-ECN: Adding Accountability to TCP/IP October 2005
network domains and end-points will be to set these codepoints
honestly and to respond correctly to path congestion, despite
conflicting interests. Although these mechanisms influence
incentives, they use engineering mechanisms like throttling and
dropping, rather than requiring changes to end-user pricing. The
protocol can be deployed incrementally around unmodified routers
without requiring changes to IP.
Authors' Statement: Status
This document is posted as an initial Internet-Draft with the intent
(at least that of the authors) to eventually progress to standards
track.
However, it proposes using the ECN codepoints currently set aside for
the experimental ECN nonce. The protocol proposed here aims to allow
networks to be able to police cheating senders and receivers and to
police neighbouring networks. On the other hand, the ECN nonce aims
to allow senders to detect cheating receivers.
Although the proposed scheme addresses a much more pressing problem,
compromises in its strength have had to be introduced in order to
make it incrementally deployable. We therefore seek the opinion of
the Internet Community on whether the resulting strength is
sufficient to warrant standards action.
Briscoe, et al. Expires April 20, 2006 [Page 2]
Internet-Draft Re-ECN: Adding Accountability to TCP/IP October 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Imprecise Protocol Overview . . . . . . . . . . . . . . . 8
3.2. Precise Protocol Overview . . . . . . . . . . . . . . . . 9
4. Transport Layers . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. Re-ECT mode: Full re-ECN capabable transport . . . . . 13
4.1.2. Re-ECT-Compat mode: Re-ECT Sender with a Vanilla
or Nonce ECT Receiver . . . . . . . . . . . . . . . . 15
4.1.3. Capability Negotiation . . . . . . . . . . . . . . . . 16
4.1.4. Flow Start . . . . . . . . . . . . . . . . . . . . . . 17
4.2. Other Transports . . . . . . . . . . . . . . . . . . . . . 18
4.2.1. Guidelines for Adding Re-feedback to Other
Transports . . . . . . . . . . . . . . . . . . . . . . 18
5. Network Layer . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Non-Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Policing Per-Flow Congestion Response . . . . . . . . . . 20
7.1.1. Incentive Framework . . . . . . . . . . . . . . . . . 21
7.1.2. Dropper . . . . . . . . . . . . . . . . . . . . . . . 21
7.1.3. Per-flow Policer . . . . . . . . . . . . . . . . . . . 21
7.1.4. Inter-domain Policing . . . . . . . . . . . . . . . . 21
7.1.5. Limitations . . . . . . . . . . . . . . . . . . . . . 21
7.1.6. Other Applications . . . . . . . . . . . . . . . . . . 22
8. Incremental Deployment . . . . . . . . . . . . . . . . . . . . 22
9. Architectural Rationale {ToDo:} . . . . . . . . . . . . . . . 23
10. Simulations . . . . . . . . . . . . . . . . . . . . . . . . . 23
11. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 23
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
13. Security Considerations . . . . . . . . . . . . . . . . . . . 23
14. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 23
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
16.1. Normative References . . . . . . . . . . . . . . . . . . . 24
16.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 27
Briscoe, et al. Expires April 20, 2006 [Page 3]
Internet-Draft Re-ECN: Adding Accountability to TCP/IP October 2005
1. Introduction
The current Internet architecture trusts hosts to respond voluntarily
to congestion. Limited evidence shows that the large majority of
end-points on the Internet comply with a TCP-friendly response to
congestion. But telephony (and increasingly video) services over the
best efforts Internet are attracting the interest of major commercial
operations. Most of these applications do not respond to congestion
at all. Those that can switch to lower rate codecs, still have a
lower bound below which they become unresponsive.
Even TCP-friendly applications can cause a disproportionate amount of
congestion, simply by using multiple flows or by transferring data
continuously. Also, of course, the Internet Architecture has few
defences against denial of service attacks that combine both
problems: unresponsiveness to congestion and flooding with multiple
flows.
Applications that need (or choose) to be unresponsive to congestion
can effectively steal whatever share of bottleneck resources they
want from responsive flows. Whether or not such free-riding is
common, inability to prevent it increases the risk of poor returns
for investors in network infrastructure, leading to under-investment.
An increasing proportion of unresponsive, free-riding demand coupled
with persistent under-supply is a broken economic cycle. Therefore,
if the current, largely co-operative consensus continues to erode,
congestion collapse could become more common in various parts of the
Internet [RFC3714].
The problem is architectural because the information needed for
policing is at the other end of the Internet from the point where
control is needed. Policing is only truly effective at the first
ingress into an internetwork, but path congestion is only visible at
the last egress. We believe non-architectural approaches (see
Section 11) to this problem are unlikely to offer more than partial
solutions.
This document proposes a simple realignment of the Internet's
feedback architecture, termed 're-feedback' [Re-fb]. The word is
short for either receiver-aligned or re-inserted feedback.
Changing the Internet's feedback architecture seems to imply
considerable upheaval. But, this document proposes changes that
could be deployed incrementally at the transport layer (we focus on
TCP), around unmodified routers using the existing fields in IP (v4
or v6). However, we stress that the limited space in the IP header
heavily reduces the responsiveness of the scheme for dealing with
deliberate dynamic attacks (see Section 7.1.5 for this and other
Briscoe, et al. Expires April 20, 2006 [Page 4]
Internet-Draft Re-ECN: Adding Accountability to TCP/IP October 2005
limitations).
Conceptually, the solution could hardly be simpler. Packet header
fields accumulate path information as data traverses the path, just
as can already be done with time to live (TTL) or explicit congestion
notification (ECN) [RFC3168] (this document focuses only on ECN).
The ECN marking rate currently always starts at the datum of zero at
the sender. Instead we expect the sender to try to make packets
arrive at the destination with a marking rate averaging around an
agreed datum. We define one of the ECT codepoints as negative so
that we can set this datum to zero. As each receiver feeds back
congestion marking arriving in packets, the sender continuously
adjusts subsequent packets in order to continue to hit the zero
target on average.
For flows from transports using re-feedback each packet arrives at
each network element carrying a view of its own downstream path,
albeit a round trip ago and averaged over multiple packets. Most
usefully, full path congestion becomes visible at the first ingress.
"Accountability for congestion" implies being able to identify who is
responsible. But congestion is a link/network/transport layer
issue---not appropriate layers for adding individual or
organisational identity. The approach we take simply relocates
information about path congestion from the egress to the ingress.
Then congestion can be associated with the interface that is directly
and ultimately responsible for causing the congestion (whether
intentionally or not). Identifying the ingress interface is a
sufficient hook for tracing the (ir)responsible party if required.
More usefully, it is the exactly the place to police or throttle in
order to directly mitigate congestion, rather than having to trace
the (ir)responsible party.
Importantly, the scheme is recursive: a whole network harbouring
users causing congestion in downstream networks can be held
responsible or policed. But the scheme correctly discounts
congestion in networks upstream of the inter-domain interface, which
is their own problem.
That is all well and good, but we still don't seem to have solved the
problem. It seems naive to hold the sender accountable by trusting
fields that depend on the honesty of both the sender and receiver---
those with most to gain from lying. However, having re-aligned the
congestion marking datum to the receiver, we show how the egress
operator can ensure that end users will lose more than they gain by
being dishonest, so the dominant strategy will be honesty.
Operators can deploy 'droppers' (Section 7.1.2) at their egress
Briscoe, et al. Expires April 20, 2006 [Page 5]
Internet-Draft Re-ECN: Adding Accountability to TCP/IP October 2005
interfaces to their end-customers to check whether traffic leaving
the internetwork is hitting the zero target. Flows persistently
below the target at the destination must come from a source that is
deliberately understating path congestion. The dropper can apply
sanctions to these flows---to ensure they lose more than they gain.
Further, in Section 7.1.1 we explain in outline why re-aligning
feedback allows us to arrange for honesty to be everyone's dominant
strategy---not only end-users, but also networks.
Building on the resulting trustworthiness of downstream path
congestion metrics at the ingress, it is possible to build a rate
equation policer (or other types of congestion-based policers
depending on what the network operator wants to achieve). The
details are outside the scope of this document, but we describe the
general principles in Section 7.1.3 using TCP as a concrete example.
We also describe an example passive bulk policer for inter-domain
boundaries.
The structure of the rest of this document is as follows. First we
provide an overview of how the re-ECN protocol works as a whole using
TCP/IP as an example (Section 3). Then we describe the network layer
functions generic to all transports (Section 5) before describing the
changes necessary in TCP and guidelines on adding the re-feedback
capability to other transports (Section 4). We complete the protocol
engineering sections of the document by clarifying why some issues
such as encryption and tunnels are actually non-issues by deliberate
design (Section 6).
The rest of the document starts by describing accountability
applications that can be built over the protocol, such as the dropper
and policer already outlined, but also briefly outlines other
possibilities like DoS mitigation and using congestion accountability
to achieve end-to-end differentiated QoS (Section 7). Then
deployment issues discussed throughout the document are brought
together in Section 8, which leads in to a brief section explaining
the somewhat subtle rationale for the design, from an architectural
perspective (Section 9). We end by referring to various simulations
(Section 10), describing related work (Section 11), listing security
considerations (Section 13) and finally drawing conclusions
(Section 14).
2. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Briscoe, et al. Expires April 20, 2006 [Page 6]
Internet-Draft Re-ECN: Adding Accountability to TCP/IP October 2005
3. Protocol Overview
First we briefly recap the essentials of the ECN protocol [RFC3168].
Two bits in the IP protocol (v4 or v6) are assigned to the ECN field.
The sender clears the field to "00" (Not-ECT) if either end-point
transport is not ECN-capable. Otherwise it indicates an ECN-capable
transport (ECT) using either of the two code-points "10" or "01"
(ECT(0) and ECT(1) resp.). Routers probabilistically set "11" if
congestion is experienced (CE). The choice of two ECT code-points
permitted future flexibility, optionally allowing the sender to
encode the experimental ECN nonce [RFC3168] in the packet stream.
The ECN nonce is an elegant scheme that allows the sender to detect
if a receiver tries to claim no congestion was experienced when it
fact it was (whether drop or ECN marking). The sender chooses
between the two ECT codepoints in a pseudo-random sequence. Then,
whenever the network marks a packet with CE, the receiver has to
guess which ECT codepoint was overwritten, with only a 50:50 chance
of being correct each time.
We use the flexibility of the two ECT codepoints originally provided
for the ECN nonce, in a scheme we call re-ECN. However, the re-ECN
protocol addresses a much wider range of cheating problems, which
includes the one addressed by the ECN nonce.
The assumption behind the ECN nonce is that a sender will want to
detect whether a receiver is suppressing congestion feedback. This
is only true if the sender's interests are aligned with the
network's, or with the community of users as a whole. This may be
true for certain large senders, who are under close scrutiny and have
a reputation to maintain. But we have to deal with a more hostile
world, where traffic may be dominated by peer-to-peer transfers,
rather than downloads from a few popular sites. Often the 'natural'
self-interest of a sender is not aligned with the interests of other
users. It wishes to transfer data quickly to the receiver as much as
the receiver wants the data quickly.
The re-ECN protocol enables policing of an agreed rate-response to
congestion (eg TCP-friendliness) at the sender's interface with the
internetwork. It also ensures downstream networks can police their
upstream neighbours, to encourage them to police their users in turn.
But most importantly, it requires the sender to declare path
congestion to the network and it can remove traffic at the egress if
this declaration is dishonest. So it can police correctly,
irrespective of whether the receiver tries to suppress congestion
feedback or whether the sender ignores genuine congestion feedback.
Here we only discuss TCP/IP, not other IP transports. No changes to
Briscoe, et al. Expires April 20, 2006 [Page 7]
Internet-Draft Re-ECN: Adding Accountability to TCP/IP October 2005
the IP or TCP wire protocols are REQUIRED, beyond those specified
already for ECN [RFC3168]. No changes to the handling of IP in
senders, receivers or routers are REQUIRED and the TCP receiver does
not need changing either, only the TCP sender. However, later, we
define RECOMMENDED changes to both the IP and TCP wire-protocols and
to the TCP receiver (Section 8 gives the incremental deployment
strategy).
The re-ECN protocol makes no changes and has no effect on the TCP
congestion control algorithm. Re-ECN is only concerned with setting
the proportions of ECT(0) and ECT(1), which is completely orthogonal
to congestion control.
3.1. Imprecise Protocol Overview
We will first give an imprecise but intuitive overview of the re-ECN
protocol, before being more exact. The general idea is to encode
remaining downstream path congestion into the three ECN codepoints.
Currently the ECN field only encodes the path congestion that has
already been experienced upstream.
Although we do not change the behaviour of ECN-capable routers, we
need to highlight the way they accumulate ECN marking along a path.
ECN-capable routers encode a time-varying congestion signal into a
stream of packets by varying the rate at which they set the CE
codepoint. Each ECN-capable router marks some packets with CE, the
marking probability increasing with the length of the queue at its
egress link (the RED algorithm [RFC2309]). The combined effect of
the packet marking of all the routers along the path signals
congestion of the whole path to the receiver. So, for example, if
one router early in a path is marking 1% of packets and another later
in a path is marking 2%, flows that pass through both routers will
experience approximately 3% marking.
With current ECN, the TCP receiver echoes CE marked packets back to
the sender. The idea of re-ECN is for the sender at the head of the
path to re-echo each echoed CE packet back into the forward data path
using the ECT(0) field. In the above example it would set the ECT(0)
codepoint on approximately 3% of the packets it sends. It sets the
remaining 97% to the other ECT codepoint, ECT(1). Then downstream
congestion can be measured to be the rate of ECT(0) marking minus the
rate of CE marking (note, we are still being imprecise). Remaining
downstream congestion can be measured at any point along the path,
not just at the sender.
Briscoe, et al. Expires April 20, 2006 [Page 8]
Internet-Draft Re-ECN: Adding Accountability to TCP/IP October 2005
^
|
| ECT(0) marking rate
3% |--------------------------------+=====
| |
2% | |
| CE marking rate |
1% | +-----------------------+
| |
0% +---------------------------------------->
^ 0 ^ 1 ^ resource index
| ^ | ^ |
0 | 1 | 2 observation points
1.00% 2.00% marking rate
Figure 1: A 2-Router Example (Imprecise)
Figure 1 shows an example to illustrate this. The horizontal axis
represents the index of each congestible resource (typically queues)
along a path through the Internet. The two superimposed plots show
the rate of each ECN codepoint observed along this path.
+-------------------+-----------------------+
| Observation point | Downstream congestion |
+-------------------+-----------------------+
| 0 | 3% - 0% = 3% |
| 1 | 3% - 1% = 2% |
| 2 | 3% - 3% = 0% |
+-------------------+-----------------------+
Effectively, using the ECT(0) codepoint, the re-ECN sender
superimposes the whole-path congestion rate into the congestion
marking signal, without disturbing the signal representing upstream
congestion given by CE marking. So all along the path, the whole-
path congestion can be used as a reference against which to compare
the upstream congestion. The difference predicts downstream
congestion for the rest of the path. So downstream congestion,
upstream congestion and whole path congestion are all encoded in 1.5
bits (3 of the 4 ECN codepoints).
Being able to encode downstream congestion directly in the packet
stream is the key to adding accountability to IP, as outlined in the
introduction.
3.2. Precise Protocol Overview
We will now repeat this description with more precision, because, of
course, there is a delay between the two signals and binary marking
Briscoe, et al. Expires April 20, 2006 [Page 9]
Internet-Draft Re-ECN: Adding Accountability to TCP/IP October 2005
is probabilistic not additive. We will end up able to precisely
measure a moving average of downstream congestion at any point on a
path.
Attending so closely to precision issues might seem pedantic, but it
avoids systematic bias in downstream congestion averages. The idea
is on average to hit a target of zero downstream congestion at the
destination. An average even slightly below zero then signifies
someone is cheating. If we recommend a sender design that introduces
a systematic bias, the distinction between cheating and honesty will
be blurred.
First some notation. j represents the index of each resource
(typically queues) along a path, ranging from 0 at the first router
to n-1 at the last. We use m_j to represent the rate at which a
router marks packets using resource j. u_j is the rate of CE marking
observable in packet headers arriving at resource j (before marking).
Similarly, z_j is the rate of ECT(0) marking. (To aid readability,
think m for *m*arking rate, u for *u*pstream congestion, z for ECT
*z*ero.)
All measurements are in terms of bytes, not packets, assuming that
line resources are more congestible than packet processing. Observed
rates of each particular codepoint (u, z as well as h and v below)
have dimensions of data rate [b/s]. Router marking rate m is a
dimensionless fraction, being the ratio of two data rates (marked and
total).
We define what is effectively a virtual header field h, where h_j =
u_j - z_j at any node j on the path. As with current ECN, no packets
are sent with CE set: u_0 = 0. And TCP feeds back to the source any
CE arriving at the destination in the echo congestion experienced
(ECE) field (see Section 4.1 for how the accuracy of ECE feedback can
be improved).
The sender tries to arrange the starting value h_0 of this virtual
header so that it will reach zero at the destination. In other
words, it tries to ensure the rates of ECT(0) and CE at the
destination are equal: z_n = u_n. Of course it cannot achieve this
for certain, but it can on average over a long enough time (we have
to assume congestion processes are stationary over the short times we
will be averaging, which is a fairly safe assumption).
Even though the sender will only hit the target on average, it is
important to avoid any systematic bias. So the sender MUST allow for
some ECT(0) packets being changed to CE by downstream routers. If
the rate of ECT(0) set by the sender is z_0, and, by the end of the
path, any packet (of whatever value of ECT) might be changed to CE
Briscoe, et al. Expires April 20, 2006 [Page 10]
Internet-Draft Re-ECN: Adding Accountability to TCP/IP October 2005
with a probability u_n, then the remaining rate of packets that have
avoided having their ECT(0) marking removed is,
z_n = z_0(1 - u_n).
But we want z_n = u_n.
So u_n = z_0(1 - u_n)
or z_0 = u_n / (1 - u_n). .......(1)
So, to avoid bias, rather than just re-echoing ECE, the sender should
slightly inflate the rate it sends ECT(0) by 1/(1 - u_n) (Section 4.1
gives a simple TCP ack handler algorithm to do this).
To be absolutely clear, all the marking rates we discuss here result
from the behaviour of simple protocol handler algorithms---we are not
saying the protocol handlers have to work with these rates directly.
^
| 3.07% ECT(0) marking rate
|--------________________________
3% | 3.04% +=====
| | 2.98%
2% | |
| CE marking rate |
1% | +-----------------------+
| 0.00% | 1.00%
0% +---------------------------------------->
^ 0 ^ n-1 ^ resource index, j
| ^ | ^ |
j=0 | j | j=n observation points
| 1.00% | 2.00% | marking rate, m
0.00% 1.00% 2.98% upstr congestion, u
3.07% 3.04% 2.98% rate of ECT(0), z
-3.07% -2.04% 0.00% virtual header, h
2.98% 2.00% 0.00% downstr congestion, v
Figure 2: Measuring Upstream and Downstream Congestion (Precise)
Figure 2 repeats our example from Figure 1, but with more precision.
It shows how combining 1% and 2% marking leads to slightly less than
3% whole-path marking:
u_n = 1 - (1 - m_0)(1 - m_1)
= 100% - 99.00% x 98.00%
= 2.98%
Briscoe, et al. Expires April 20, 2006 [Page 11]
Internet-Draft Re-ECN: Adding Accountability to TCP/IP October 2005
The figure also shows the sender slightly inflating the rate it sets
ECT(0) to 3.07% in order to hit the 2.98% target.
z_0 = u_n / (1 - u_n) .......From Equation (1)
= 2.98% / 97.02%
= 3.07%
We now introduce the notation v for the downstream congestion metric
we need for accountability applications. For low levels of
congestion (|h_j| << 1), the virtual headers h arriving in packets at
any node on the path are themselves a good approximation to
downstream congestion, that is v ~ -h (we have deliberately used a
definition of h that usually makes it numerically negative). In
other words, downstream congestion can be approximated simply by
subtracting the rate of CE from that of ECT(0).
But, because the rate of ECT(0) had to be inflated by the sender, it
needs deflating again if a precise measure of downstream congestion
is required. The following formula does the necessary deflation
(derived in Appendix A.1 of [Re-fb]):
v_j = 1 - 1 / (1 - h_j). .......(2)
The last two rows in Figure 2 show the virtual header and this
precise downstream congestion metric for our example scenario. Note
that Equation (2) deliberately implies that the sender cannot declare
downstream congestion of more than 50%, as it MUST not set the
virtual header outside the bounds -1 <= h_j <= 0. We discuss this
saturation in Section 7.1.5.
4. Transport Layers
4.1. TCP
The ECN field in the IPv4 and IPv6 wire protocols and the names of
the codepoints within it remain unchanged from their definition in
[RFC3168].
Re-ECN capability at the sender is essential. At the receiver it is
optional, as long as the receiver has a basic ('vanilla flavour')
ECN-capable transport (ECT) to [RFC3168]. Given the number of
combinations of sender and receiver capability has grown to 16, we
give a table below summarising what happens with each combination.
The sender of the TCP half-connection is host S and the receiver is
R. There is a column for each flavour of host capability. The last
column gives the mode the half-connection is in after the TCP
handshake (we have made up the names for the nonce-related modes ---
Briscoe, et al. Expires April 20, 2006 [Page 12]
Internet-Draft Re-ECN: Adding Accountability to TCP/IP October 2005
the ECN nonce RFC [RFC3540] doesn't specify behaviour in all cases).
Only the first three rows concern us here, as all the rest are
already outlined in the specifications of earlier flavours of ECN.
+--------+-----------+-----+---------+---------------+
| Re-ECT | ECT-Nonce | ECT | Not-ECT | Mode |
+--------+-----------+-----+---------+---------------+
| SR | | | | Re-ECT |
| S | R | | | Re-ECT-Compat |
| S | | R | | Re-ECT-Compat |
| S | | | R | Not-ECT |
| | SR | | | ECT-Nonce |
| | S | R | | Half-Nonce |
| | S | | R | Not-ECT |
| | | SR | | ECT |
| | | S | R | Not-ECT |
| | | | SR | Not-ECT |
| R | S | | | ECT-Nonce |
| R | | S | | ECT-Nonce? |
| R | | | S | Not-ECT |
| | R | S | | ECT-Nonce? |
| | R | | S | Not-ECT |
| | | R | S | Not-ECT |
+--------+-----------+-----+---------+---------------+
o Re-ECT: Full re-ECN capabable transport
o Re-ECT-Compat: Re-ECN sender in compatibility mode with a vanilla
[RFC3168] ECN receiver or an [RFC3540] ECN nonce-capable receiver.
We will describe what happens in these two modes, then describe how
they are negotiated.
4.1.1. Re-ECT mode: Full re-ECN capabable transport
In full Re-ECT mode, for each half connection, both sender and
receiver maintain an unsigned integer counter we will call ECI (echo
congestion increment). It maintains a count, modulo 8, of how many
times a CE marked packet has arrived at the receiver during the half-
connection. Conceptually the three TCP option fields used for ECN-
related functions in previous versions of ECN are used as a 3-bit
field for the receiver to repeatedly tell the sender the current
value of ECI. This conceptual field is shown in Figure 4, against
how the TCP header is actually defined at the moment, including the
addition of support for the ECN nonce in Figure 3.
Every time a CE marked packet arrives at the receiver, the receiver
transport increments its local value of ECI modulo 8 and immediately
Briscoe, et al. Expires April 20, 2006 [Page 13]
Internet-Draft Re-ECN: Adding Accountability to TCP/IP October 2005
echoes its value to the sender in this conceptual ECI field in the
TCP header. It repeats the same value of ECI in every subsequent ACK
until the next CE event, when it increments ECI again.
The increment of the local ECI values is modulo 8 so the field value
simply wraps round back to zero when it overflows. The least
significant bit is to the right (labelled bit 9). {ToDo:
Unfortunately the 3-bit field crosses a byte boundary - how important
is this?}
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | N | C | E | U | A | P | R | S | F |
| Header Length | Reserved | S | W | C | R | C | S | S | Y | I |
| | | | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 3: The (post-ECN Nonce) definition of bytes 13 and 14 of the
TCP Header
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | | U | A | P | R | S | F |
| Header Length | Reserved | ECI | R | C | S | S | Y | I |
| | | | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 4: Our alternative conceptual view of bytes 13 and 14 of the
TCP Header
On the arrival of every ACK, the sender compares the ECI field with
its own copy, then replaces its local copy with that from the ACK.
The difference is assumed to be the number of CE marked packets that
have arrived at the receiver since the last ACK (but see below for
its safety strategy). Each increment of the ECI field (or detection
of a drop), the sender MUST set the ECT(0) field in the IP header of
the next packet it sends, effectively re-echoing each increment to
ECI. Otherwise the data sender sends all packets with ECT(1) set.
As we have already emphasised in the protocol overview, the re-ECN
protocol makes no changes and has no effect on the TCP congestion
control algorithm. So, each increment of ECI (or detection of a
drop) also triggers the standard TCP congestion response, but with no
more than one congestion response per round trip, as usual.
We chose this method for echoing congestion marking because a re-ECN
sender needs to know about every CE mark arriving at the receiver,
Briscoe, et al. Expires April 20, 2006 [Page 14]
Internet-Draft Re-ECN: Adding Accountability to TCP/IP October 2005
not just whether at least one arrives within a round trip time. But
pure ACKs are not protected by TCP reliable delivery, so we repeat
the same ECI value in every ACK until it changes. Even if many ACKs
in a row are lost, as soon as one gets through, the ECI field it
repeats from previous ACKs that didn't get through will update the
sender on how many CE marks arrived since the last ACK got through.
The sender will only lose a record of the arrival of a CE mark if
/all/ the ACKS are lost (and all of them were pure ACKs) for a stream
of data long enough to contain 8 or more CE marks. To protect
against this extremely unlikely event, if the sender receives a ACK
that acknowledges a sequence number 8 or more segments higher than
the previously ack'd sequence number it should conservatively behave
as if all the intervening ACKs echoed a new CE mark. {ToDo: This
behaviour is ultra-ultra-conservative, so we need to check whether
this ultra-safely is really necessary.}
In order to slightly inflate the rate of ECT(0) marking, as described
in the precise protocol overview above (Section 3.2), for each half-
connection the TCP sender maintains a single EWMA, U, of the number
of ACKed packets between successive increments of ECI (assuming
equal-sized packets). It sets an extra ECT(0) in sent data every
(U-1) increments of the ECI field. Maintaining this EWMA can be done
with a shift and an add per packet, by choosing a power of two for
the weight.
4.1.2. Re-ECT-Compat mode: Re-ECT Sender with a Vanilla or Nonce ECT
Receiver
If the half-connection is in Re-ECT-Compat mode, the receiver will
not understand re-ECN but the sender can infer enough from the
vanilla ECN feedback to set the ECT(0) marking rate reasonably well.
Essentially, every time the receiver toggles the ECE field from 0 to
1, the Re-ECN sender does the same as it would do in full Re-ECT
mode. That is, it sets ECT(0) on the next packet and maintains the
two counters that enable it to inflate the rate of ECT(0).
If a CE marked packet arrives at the receiver within a round trip
time of a previous mark, the receiver will still be echoing ECE for
the last CE mark. Therefore, such a mark will be missed by the
sender. Of course, this isn't of concern for congestion control, but
it does mean that the rate of ECT(0) will be occasionally
understated. If there is a dropper at the egress, flows in Re-ECT-
Compat mode may be mistaken for very lightly cheating flows and
suffer a small number of packet drops. We expect Re-ECN would be
deployed for some time before policers and droppers start to enforce
it. So, given there is not much ECN deployment yet anyway, this
minor problem may affect only a very small proportion of flows,
Briscoe, et al. Expires April 20, 2006 [Page 15]
Internet-Draft Re-ECN: Adding Accountability to TCP/IP October 2005
reducing to nothing over the years as vanilla ECN sites upgrade.
{ToDo: This decision will need to be reviewed in the light of
experience at the time of re-ECN deployment.}
Re-ECT-Compat mode is OPTIONAL. Re-ECN implementers who want to keep
their code simple, MAY choose not to implement this mode. If they do
not, a re-ECN sender SHOULD fall back to vanilla ECT mode in the
presence of an ECN-capable receiver. It MAY choose to fall back to
the ECT-Nonce mode, but if implementers don't want to be bothered
with this mode, they probably won't want to bother with the nonce
either.
4.1.3. Capability Negotiation
During the TCP hand-shake at the start of a connection, the
originator of the connection (host A) indicates that it has a re-ECN-
capable transport (Re-ECT) by setting the TCP options NS=1, CWR=1 and
ECE=1 in the initial SYN.
A responding Re-ECT host (host B) should return a SYN ACK with flags
NS=0, CWR=1 and ECE=0. We would also like to reserve the combination
NS=1, CWR=1 and ECE=0 for future Re-ECN use {ToDo: describe this
future use}.
These handshakes are summarised in the table below. The handshakes
used for the other flavours of ECN are also shown for comparison.
+---------+----+-----+-----+-----------------------------+
| Phase | NS | CWR | ECE | Condition |
+---------+----+-----+-----+-----------------------------+
| SYN | 1 | 1 | 1 | A is Re-ECT |
| SYN ACK | 0 | 1 | 0 | B is Re-ECT |
| SYN ACK | 1 | 1 | 0 | Reserved: future Re-ECT use |
| SYN ACK | 0 | 0 | 1 | B is ECT |
| SYN ACK | 1 | 0 | 1 | B is ECT-Nonce |
+---------+----+-----+-----+-----------------------------+
The rationale for choosing these particular combinations of flags is
as follows.
Choice of SYN flags: The Re-ECN sender can work with vanilla ECN
receivers so we wanted to use the same flags as would be used in
an ECN-setup SYN [RFC3168]. But at the same time, we wanted a
receiver that is Re-ECT to be able to recognise that the sender is
also Re-ECT. We believe setting NS=1 achieves both these
objectives, as it should be ignored by vanilla ECT receivers and
by ECT-Nonce receivers, but senders that are not Re-ECT should not
set NS=1. {ToDo: At the time ECN was defined, the NS flag was not
Briscoe, et al. Expires April 20, 2006 [Page 16]
Internet-Draft Re-ECN: Adding Accountability to TCP/IP October 2005
defined, so setting NS=1 should be ignored by existing ECT
receivers (but you never know).}
Choice of SYN ACK flags: Choice of SYN ACK: The sender needs to be
able to determine whether the receiver is Re-ECT. The original
ECN specification required an ECT receiver to respond to an ECN-
setup SYN with an ECN-setup SYN ACK of CWR=0 and ECE=1. There is
no room to modify this by setting the NS flag, as that is already
set in the SYN ACK of an ECT-Nonce receiver. So we used the only
combination of CWR and ECE that would not be used by existing TCP
receivers: CWR=1 and ECE=0. The original ECN specification
defines this combination as a non-ECN-setup SYN ACK, which remains
true for vanilla and Nonce ECTs. But for re-ECN we define it as a
Re-ECN-setup SYN ACK. We didn't use a SYN ACK with both CWR and
ECE cleared to 0 because that would be the likely response from
most Not-ECT receivers. And we didn't use a SYN ACK with both CWR
and ECE set to 1 either, as at least one broken receiver
implementation echos whatever flags were in the SYN into its SYN
ACK.
Choice of Reserved SYN ACK: {ToDo:}
4.1.4. Flow Start
Note that at the network layer a TCP SYN should have the ECN field
cleared (Not-ECT).
Contrary to the original ECN specification [RFC3168] a SYN ACK SHOULD
have ECT set at the network layer, as currently being proposed
[I-D.kuzmanovic-ecn-syn]. Specifically, a Re-ECT receiver SHOULD set
the ECN field of the SYN ACK to ECT(0). Once the TCP flow starts,
the TCP sender SHOULD set ECT(0) on the first packet it sends (after
the SYN). The TCP sender for each half-connection MUST then follow
the above procedure for determining whether to set ECT(1) or ECT(0)
at the network layer for each subsequent packet.
The first SYN and the first ECT packet in each half connection SHOULD
have the CR flag cleared to 0 at the network layer (see Section 5).
Subsequent packets MUST have the CR flag set to 1.
The above behaviour for the very first ECT packet of a flow is
necessary because the transport does not have the benefit of ECN
feedback. So ECT(0) is set rather than ECT(1) as a conservative
estimate that there might be congestion. And the CR flag is cleared
to indicate that the ECT field has been set without certain knowledge
of the path.
It might seem pedantic worrying about these single packets, but this
Briscoe, et al. Expires April 20, 2006 [Page 17]
Internet-Draft Re-ECN: Adding Accountability to TCP/IP October 2005
behaviour ensures the system is safe, even if the application mix on
the Internet evolves to the point where the majority of flows consist
of a single packet. It also allows denial of service attacks to be
more easily isolated and prevented.
Note that we have said SHOULD rather than MUST for this behaviour
with initial ECT packets. This is to entertain the possibility of
the TCP transport having the benefit of other knowledge of the path,
which it re-uses from one flow to the benefit of a newly starting
flow. For instance, multiple flows between the same hosts using a
Congestion Manager [RFC3124]. Or a proxy host that is aggregating
congestion information for large numbers of flows (indeed, if
Internet traffic evolves to be dominated by single-packet flows we
will need plenty of these).
4.2. Other Transports
4.2.1. Guidelines for Adding Re-feedback to Other Transports
Re-ECT sender transports that have established the receiver transport
is at least ECN-capable (not necessarily Re-ECN capable) MUST set the
ECT(0) codepoint at least as often as the CE codepoint arrives at the
receiver. As with the current ECN protocol, whenever ECT(0) is not
set, the ECT(1) codepoint should be set.
If the sender transport does not have sufficient feedback to even
estimate the path's CE rate, it SHOULD set ECT(0) continuously. If
the sender transport has some, perhaps stale, feedback to estimate
the path's CE rate, the transport SHOULD set ECT(0) and ECT(1) in
equal proportions. Alternating them, starting with ECT(0) would be
sufficient. From Equation (2) above, the sender will then be
declaring to the network ingress that it believes downstream
congestion, v_0 = 50% or 33% respectively. Note: these estimates are
NOT used for congestion control in the Re-ECN protocol. If this is
an under-declaration of the actual (but unknown) path congestion, it
will simply result in a strongly positive virtual header, h, at the
destination.
A Re-ECT sender transport that cannot estimate the CE rate at the
receiver MUST also set the Certain flag (CR) (see Section 5).
{ToDo: Give a brief outline of what would be expected for each of the
following:
o UDP Fire and Forget (e.g. DNS)
o UDP Streaming with no F/b
Briscoe, et al. Expires April 20, 2006 [Page 18]
Internet-Draft Re-ECN: Adding Accountability to TCP/IP October 2005
o UDP Streaming with F/b
o DCCP
o RSVP and/or NSIS: A separate I-D is in preparation describing how
re-ECN can be used in an edge-to-edge rather than end-to-end
scenario. It can then be used by downstream networks to police
whether upstream networks are blocking new flows when downstream
congestion is too high, even though the congestion is in other
operators' downstream networks. This relates to current work in
progress on Admission Control over Diffserv using Pre-Congestion
Notification, being reported to the IETF TSVWG [CL-arch].
}
5. Network Layer
The ECN field in the IP header remains unchanged. However, the
semantics of the two ECT codepoints change. Previously routers and
middleboxes treated these two codepoints identically, not taking any
note of which codepoint was set. With the re-ECN protocol, routers
and middleboxes may infer downstream or full-path congestion by
monitoring the relative rates of the ECN codepoints. Routers and
middleboxes that monitor this information SHOULD ignore packets with
the CR flag (defined below) cleared. The CR flag MUST NOT be used to
determine the treatment of a single packet. It is only meaningful to
support the monitoring of averages over multiple packets.
For IPv4, this document defines a new CR (Certain) control flag in
place of the reserved control flag at bit 48 of the IPv4 header
(counting from 0). Alternatively, some would call this bit 0
(counting from 0) of byte 7 (counting from 1) of the IPv4 header.
0 1 2
+---+---+---+
| C | D | M |
| R | F | F |
+---+---+---+
Figure 5: New Definition of the Control Flags at the start of Byte 7
of the IPv4 Header
{ToDo: Include the IPv6 extension header design, including support
for the CR flag. Also its integrated support for a future multi-bit
congestion notification field, with a TTL hop count scheme to check
that all routers on the path support it (similar to Quick-Start).
So, if the whole path of routers doesn't support the extension, the
Briscoe, et al. Expires April 20, 2006 [Page 19]
Internet-Draft Re-ECN: Adding Accountability to TCP/IP October 2005
end-points can fall back to re-ECN (or drop).}
Guidelines on setting the CR flag are given in Section 4.2.1. When
set, the CR flag also serves as an indication that the transports are
re-ECN capable (Re-ECT). More generally, it will imply that the
transport understands and is using re-feedback of other fields in the
IP header, such as the TTL (see [Re-fb]), although this document does
not define re-feedback behaviour for the TTL field.
{ToDo: Describe how the sender falls back to clearing this flag if
packets don't appear to be getting through (to work round a firewall
discarding a packet it considers unusual).}
{ToDo: We are sure there will probably be other claims pending on the
use of this flag (we know of at least one {ToDo add ref to Adams}).
There is a possibility that this flag as defined can simultaneously
serve other purposes, particularly where the start of a flow needs
distinguishing from packets later in the flow. For instance it could
have been useful in tag switching? It is (nearly) Clark's state
set-up bit to protect against memory exhaustion attacks?.}
6. Non-Issues
{ToDo: This section will explain why the addition of Re-ECN does not
interact with any of the following:
o Integration with congestion notification in various link layers
(Ethernet, ATM (and MPLS if it had a congestion notification
capability added, which is not precluded for the EXP field
[RFC3270])
o Tunnels, and Overlays that wish to support congestion notification
(see also the brief discussion of edge-to-edge support for Re-ECN
in RSVP or NSIS transports earlier)
o Encryption and IPSec
}
7. Applications
7.1. Policing Per-Flow Congestion Response
Briscoe, et al. Expires April 20, 2006 [Page 20]
Internet-Draft Re-ECN: Adding Accountability to TCP/IP October 2005
7.1.1. Incentive Framework
{ToDo: This section will largely repeat the discussion in Sections 3
"Incentives" and 3.1 "The Case Against Classic Feedback" of [Re-fb],
but putting it into a standardisation context.}
7.1.2. Dropper
{ToDo: This section will largely repeat the discussion in Section 3.2
"Honest Congestion Reporting" of [Re-fb], as an example
implementation of a 'dropper' (but for 2-bit Re-ECN) that could be
deployed at the egresses from the internetwork to detect cheating
packets and flows.}
7.1.3. Per-flow Policer
{ToDo: This section will largely repeat the discussion in Section 3.3
"Fair Congestion Response" of [Re-fb], as an example implementation
of a 'policer' (but for 2-bit Re-ECN) that could be deployed at the
ingresses into the internetwork to detect flows not complying to the
agreed rate response to congestion.}
7.1.4. Inter-domain Policing
{ToDo: This section will largely repeat the discussion in Section 3.4
"Interdomain incentive mechanisms" of [Re-fb], to give examples of
how downstream networks can police the aggregate congestion response
of their upstream neighbours, against different contractual
arrangements. The goal being to ensure the upstream network in turn
polices its upstream networks, eventually ensuring upstream networks
will suffer financially if they do not police the rate response to
congestion of their users.}
7.1.5. Limitations
{ToDo: This is the most critical section, for the IETF audience, but
unfortunately we have not had time to write it. This section will
discuss the limitations of the re-feedback approach, particularly
having fit it into the one remaining spare codepoint and bit of the
IP header:
o The ability of malicious users to turn off ECT, given Not-ECT
traffic cannot be policed, and the implications on how we may have
to treat Not-ECT traffic in the longer term.
o Re-feedback for TTL would also be desirable at the same time
Briscoe, et al. Expires April 20, 2006 [Page 21]
Internet-Draft Re-ECN: Adding Accountability to TCP/IP October 2005
o The ability of malicious users to launch dynamically changing
attacks, exploiting the time it takes to detect an attack, given
ECN marking is binary.
o Tructation vs. Drop: The issue over whether it would be useful to
truncate rather than drop packets that appear to be malicious, so
that the feedback loop can continue even though useful data can be
removed.
o The apparently inherent need for at least some flow state at the
egress dropper given the binary marking environment, and the
consequent vulnerability to state exhaustion attacks.
o Issues around saturation of the number range the Re-ECN protocol
uses to signal marking rates (These issues are believed to be
safe, but they need airing anyway).
}
7.1.6. Other Applications
{ToDo: Other applications of Re-ECN will be briefly outlined here
(largely drawing from section 3 of [Re-fb]), such as:
o Per-user (rather than per-flow) long term congestion policing
o DDoS Mitigation
o E2e QoS
o Traffic Engineering
o Inter-Provider Service Monitoring
}
8. Incremental Deployment
{ToDo: This section will bring together the features related to
incremental deployment in the protocol specification as defined, to
describe the overall deployment strategy. Particularly, the final
step described in the next paragraph is neat:}
We chose the rate of ECT(0) for z, rather than ECT(1) deliberately.
Existing ECN sources set ECT(0) at either 50% (the nonce) or 100%
(the default). So they will appear to a re-feedback policer as very
highly congested paths. When policers are first deployed they can be
Briscoe, et al. Expires April 20, 2006 [Page 22]
Internet-Draft Re-ECN: Adding Accountability to TCP/IP October 2005
configured permissively, allowing through both `legacy' ECN and
misbehaving re-ECN flows. Then, as the threshold is set more
strictly, the more legacy ECN sources will gain by upgrading to re-
ECN. Thus, towards the end of the voluntary incremental deployment
period, legacy transports can be given progressively stronger
encouragement to upgrade.
9. Architectural Rationale {ToDo:}
10. Simulations
This section will refer to the simulations or policer and dropper
performance done since those in section 5 "Dropper Performance" of
[Re-fb]. Some are in submission to a conference.
11. Related Work
This section will largely be similar to the section 6 "Related Work"
of [Re-fb], but in a more standards-related context.
12. IANA Considerations
{ToDo:}This memo includes no request to IANA (yet).
13. Security Considerations
{ToDo:}
14. Conclusions
{ToDo:}
15. Acknowledgements
{ToDo:}
16. References
Briscoe, et al. Expires April 20, 2006 [Page 23]
Internet-Draft Re-ECN: Adding Accountability to TCP/IP October 2005
16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
S., Wroclawski, J., and L. Zhang, "Recommendations on
Queue Management and Congestion Avoidance in the
Internet", RFC 2309, April 1998.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces",
RFC 3540, June 2003.
16.2. Informative References
[CL-arch] Briscoe and others, B., "A framework for admission control
over Diffserv using Pre-congestion notification",
I-D draft-briscoe-tsvwg-cl-architecture-01.txt, July 2005.
(work in progress)
[I-D.kuzmanovic-ecn-syn]
Kuzmanovic, A., "Adding Explicit Congestion Notification
(ECN) Capability to TCP's SYN/ACK Packets",
draft-kuzmanovic-ecn-syn-00 (work in progress),
October 2005.
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager",
RFC 3124, June 2001.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, May 2002.
[RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion
Control for Voice Traffic in the Internet", RFC 3714,
March 2004.
[Re-fb] Briscoe, B., Jacquet, A., Di Cairano-Gilfedder, C.,
Salvatori, A., Soppera, A., and M. Koyabe, "Policing
Briscoe, et al. Expires April 20, 2006 [Page 24]
Internet-Draft Re-ECN: Adding Accountability to TCP/IP October 2005
Congestion Response in an Internetwork Using Re-Feedback",
ACM SIGCOMM CCR 35(4)277--288, August 2005, <http://
www.acm.org/sigs/sigcomm/sigcomm2005/
techprog.html#session8>.
Briscoe, et al. Expires April 20, 2006 [Page 25]
Internet-Draft Re-ECN: Adding Accountability to TCP/IP October 2005
Authors' Addresses
Bob Briscoe
BT & UCL
B54/77, Adastral Park
Martlesham Heath
Ipswich IP5 3RE
UK
Phone: +44 1473 645196
Email: bob.briscoe@bt.com
URI: http://www.cs.ucl.ac.uk/staff/B.Briscoe/
Arnaud Jacquet
BT
B54/70, Adastral Park
Martlesham Heath
Ipswich IP5 3RE
UK
Phone: +44 1473 647284
Email: arnaud.jacquet@bt.com
URI:
Alessandro Salvatori
BT
B54/77, Adastral Park
Martlesham Heath
Ipswich IP5 3RE
UK
Phone: ?
Email: sandr8@gmail.com
URI: ?
Briscoe, et al. Expires April 20, 2006 [Page 26]
Internet-Draft Re-ECN: Adding Accountability to TCP/IP October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Briscoe, et al. Expires April 20, 2006 [Page 27]
| PAFTECH AB 2003-2026 | 2026-04-22 06:35:36 |