Internet Engineering Task Force S. Kalyanaraman/ D. Harrison/
INTERNET-DRAFT S. Arora/ K. Wanglee/ G. Guarriello
draft-shivkuma-ecn-diffserv-01.txt Rensselaer Polytechnic Institute
March, 1998
Expires: September 1998
A One-bit Feedback Enhanced Differentiated Services Architecture
Status of this Memo
This document is an Internet-Draft. 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".
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Abstract
This document proposes the use of one bit in the DS-byte to
facilitate ECN-type control in the differentiated services
architecture. Specifically during periods of congestion along a
flow's path (indicated using the one-bit mechanism), the out-of-
profile packets of the flow (packets for which the "In profile" bit
is cleared) can be either delayed or dropped by the ingress network
edge routers. This scheme would allow interior routers to preserve
their resources for processing in-profile packets during congestion
and guard against certain types of denial-of-service attacks. The
proposed mechanism could also be used to build differentiated
services networks with lower average delay, and aid the
implementation of congestion-based pricing schemes in such
architectures. The mechanism interoperates well with the baseline
differentiated services architecture and can also interoperate with
ECN-TCP and future ECN-enabled transports/applications. Further, the
ECN-type flow control can be deployed within a differentiated
services network even if end-to-end ECN support is unavailable,
allowing a quick migration path.
Kalyanaraman et al [Page 1]
INTERNET-DRAFT 1-bit Feedback Enhanced Diff-Serv March 1998
1. Introduction
The DS-byte (formerly TOS octet [RFC791],[RFC1349]) in the IP header
is being defined to allow a packet to receive differential treatment
depending upon the bits set [Nichols]. The DS-byte is marked by
traffic conditioners at the network boundaries. A DS-byte classifier
and per-hop behaviors based on those classifications are required in
all network nodes of a differentiated-services-capable network. The
differentiated services architecture effort is aimed at specifying
the number and type of the building blocks and services built from
them [Nichols].
The operational model [Nichols] is based upon two sets of proposals.
One set of proposals [Ellesson, Ferguson, Heinanen, SIMA] suggests
various encodings of the DS-byte to get specific per-hop behaviors
from nodes such as low delay, drop preference, priority queueing etc.
The other set [Clark, 2BIT] suggests behaviors required from the
network as a whole. The DS-byte definition currently allows one bit
based upon the latter set, which is used to mark a packet as IN or
OUT of its negotiated service profile (we use the term "in-profile"
or "out-of-profile" to qualify such packets). Five bits (the per-hop
behavior or PHB field) have been kept for defining per-hop behaviors.
The last two bits are currently unused (CU) have been reserved for
Explicit Congestion Notification (ECN) experimentation.
The purpose of this draft is to highlight some features of ECN as it
relates to differentiated service, and propose changes in the DS-byte
and ICMP message type allocations to help support these features.
Specifically, we believe new levels of service differentiation can be
created using *any* existing differentiated service class combined
with an "edge-to-edge" flow control scheme. The term "edge-to-edge"
refers to a proposed control loop between the ingress and egress
network edge routers in the differentiated services architecture.
Though ECN was originally defined for controling TCP traffic [Floyd-
ECN], our proposed edge-to-edge ECN works at the IP layer and can
control both TCP and non-TCP, and both unicast and multicast traffic.
We propose a new "INTERNAL" ICMP message type to carry notifications
from the egress edge to the ingress edge (see section 5), which
eliminates the need for any reverse traffic or acknowledgement flow
for a session. Within the context of the differentiated services
working group charter, we propose the use of one bit which can be
used by such "edge-to-edge" flow control schemes. The bits currently
reserved for ECN in the DS-byte could be overloaded with this
function or a new bit can be used within the PHB for this purpose.
We first review ECN concepts in section 2 and discuss problems/issues
in a non-ECN differentiated services architecture in section 3. We
then describe the role of ECN (specifically the capability to do
Kalyanaraman et al [Page 2]
INTERNET-DRAFT 1-bit Feedback Enhanced Diff-Serv March 1998
edge-to-edge flow control) in the differented services architecture
in section 4. This discussion includes the description of a sample
ECN-enhanced architecture and a set of strategies for ECN generation
at routers and response by edge routers. The standardization issues
including the possible use of PHB or CU field for edge-to-edge ECN is
discussed in section 5. Section 6 outlines ECN issues with IPSEC
tunneling and a discussion of its vulnerability to the denial-of-
service attack problem. Section 7 discusses compatibility issues with
older TOS semantics and section 8 gives a summary.
2. Explicit Congestion Notification (ECN) mechanisms
The concept of ECN mechanisms for TCP congestion control was
developed by Sally Floyd [Floyd-ECN] and there is a recent proposal
to reserve two bits for ECN in the IPv6 [IPv6] Class octet
[Ramakrishnan]. To allow experimentation in IPv4, two bits (ECN-
enabled bit, and ECN bit) in the DS-byte have also been set aside for
ECN. As the name suggests ECN mechanisms are used by the network to
unambigously declare a state of congestion. ECN-enabled transport
protocols (like ECN-TCP) would respond to the notification through a
reduction of load. Specifically in the case of TCP it has been
suggested [Floyd-ECN] that the ECN response be similar to the
response to a detection of packet loss (i.e. halving the source
congestion window). There has also been a drive to urge all transport
protocols to perform some kind of flow control for the collective
benifit they can derive from the network, even though they may or may
not care for error control [Floyd-RouterMech]. Since routers can
utilize ECN bits to give a transport-neutral congestion indication,
ECN is expected to play a significant role in the development of flow
control methods in non-TCP transport protocols. As a result, more
transport or application protocols could be expected to become "ECN-
enabled" in the future.
In the context of TCP, ECN provides a clear, if modest benifit
[Floyd-ECN]. When a router is entering a congestion phase it could
use ECN instead of packet discard to notify the sources about
congestion. ECN-enabled routers could set the ECN bit if the ECN-
enabled bit is set on a packet instead of dropping the packet. The
destination then sets the ECN bit in the acknowledgement to notify
the source. The source responds by cutting its window size. Avoiding
unnecessary packet drops is particularly attractive to low bandwidth,
interactive applications [Floyd-ECN]. Bulk-data transfer applications
using ECN-TCP get high throughput over a wide range of conditions and
parameter values (TCP clock granularity, TCP window size, RED gateway
variation etc).
The authors of this document were inspired by two features of ECN:
the transport-neutral feedback property which would be used to
Kalyanaraman et al [Page 3]
INTERNET-DRAFT 1-bit Feedback Enhanced Diff-Serv March 1998
provide service differentiation at the IP-layer, and the potential of
ECN to provide resistance to certain kinds of denial-of-service
attacks and control the average delay inside the differentiated-
services-network.
3. Issues in a non-ECN differentiated services network:
Consider a simple differentiated service network which provides a
packet-drop priority for packets which are marked in-profile (i.e,
out-of-profile packets are dropped before in-profile packets during
congestion). Deering [Deering] argued that this situation may create
a positive incentive for sources to overdrive the network by sending
an unlimited amount of out-of-profile packets. An example is a source
using layered encodings, but no congestion backoff. Misbehaving TCP
sources (hacked or otherwise) also belong to this category.
When a node in the path is congested, out-of-profile packets are
dropped first before dropping in-profile packets. The dropping of an
out-of-profile packet inside the differentiated services network can
be construed as a waste of shared resources consumed by the packet to
reach the node where it was dropped. These wasted resources could
have been utilized to service other in-profile packets or even other
out-of-profile packets which could have made it to their destinations
- a type of denial-of-service attack. Deering [Deering] showed an
example where this can happen and we reproduce it here (with some
editing to motivate ECN):
In the following diagram, S1 and S2 are sources of traffic sending to
receivers R1 and R2, respectively. A through F are routers, and the
numbers in angle brackets are the capacities of the links in Kbps.
S1 ---<300>--- A E ---<300>--- R2
\ /
\ /
C ---<300>--- D
/ \
/ \
S2 ---<300>--- B F ----<50>--- R1
Assume that each of the two sources is sending a 50 Kbps voice stream
and a 200 Kbps video stream to its corresponding receiver, as part of
a teleconferencing application. And assume that that's the only
traffic in this simple network.
Further assume that both S1 and S2 are marking (by use of a 1-bit or
multi- bit drop-preference field) all their video packets as "out-
of-profile" or "less important" than their voice packets, so that if
congestion is encountered, the video packets will be discarded before
Kalyanaraman et al [Page 4]
INTERNET-DRAFT 1-bit Feedback Enhanced Diff-Serv March 1998
the audio packets, to avoid audio degradation if at all possible.
Assuming the less important packets are dropped by the routers in
favor of more important packets, and that packets of the same
importance are dropped with equal probability, C will discard half of
S1's video packets and half of S2's video packets, and F will discard
the rest of S1's video packets. R1 will receive only S1's voice
packets. R2 will receive S2's voice packets plus half of S2's video
packets. Thus, S1, by sending video (or "out-of-profile") packets
that cannot be delivered to R1, has denied half of S2's video packets
access to the C-D link. (Further, if R2 is unable to produce an
acceptible video image from only half of the video packets, the
bandwidth consumed by those packets is also wasted, which could, in
turn, deny bandwidth to other traffic flows in a more general
example.) If S1 were instead to refrain from sending its
undeliverable video packets, or were informed via feedback that the
video packets were in fact undeliverable, R2 could receive the
complete (or a considerably better) video stream from S2.
The key point is that upstream *shared* resources were wasted by
out-of-profile packets which would never reach their destination. The
need is therefore to develop network mechanisms, which can be used as
building blocks to provide positive incentives for applications to
adapt (keep all its traffic in-profile) and disincentives for those
that do not adapt. We look at one such mechanism, RED-plus-penalty-
box next and discuss its limitations to motivate the need for edge-
to-edge ECN.
3.1 RED-plus-penalty-box:
One way to set up the system of incentives for end-to-end flow
control is the "RED-plus-penalty-box" [RED] approach where a simple
accounting technique in addition to Random Early Detection (RED)
algorithm can help identify misbehaving connections, which would then
be treated differently. The utility of this method is constrained in
the differentiated services framework because in-profile packets are
expected to be serviced uniformly for both well-behaving and
misbehaving flows. Dropping more out-of-profile packets of the
misbehaving flow than the others, while certainly a benifit, does not
prevent the waste of resources upstream by this flow ("upstream" and
"downstream" are defined in terms of the flows and the router where
the packet is dropped).
"RED-plus-penalty-box" can still be used to avoid wastage of upstream
resources - by requiring that all nodes in the differentiated
services network implement the "penalty-box" scheme and identify
misbehaving flows even if they are not congested. Then out-of-
Kalyanaraman et al [Page 5]
INTERNET-DRAFT 1-bit Feedback Enhanced Diff-Serv March 1998
profile packets belonging to the misbehaving flow (detected close to
the entrance of the network) could be dropped at a higher rate even
though there is no local congestion at the node. There are two
problems with this scheme: first, when there is no congestion
downstream, there is no need to identify the misbehaving flow and
drop its out-of-profile packets. Second, it requires *all* nodes to
implement the penalty-box scheme.
4. Role of ECN in the Differentiated Services Architecture:
We show in this section that schemes based upon ECN can be used to
identify misbehaving sources which concentrate all "penalty" actions
in the traffic conditioners at the edge of the network. Therefore all
nodes need not implement the penalty actions. Moreover this behavior
is possible while interoperating with ECN-enabled transports - the
edges could choose not to impose edge-to-edge flow control if end-
to-end flow control is enabled (subject to monitoring and policing).
More generally, the traffic conditioners at the network edges could
"proxy" as ECN-capable transports. These schemes would have the
desirable property that out-of-profile packets are admitted into the
differentiated services network when the paths traversed by the flows
which they belong to are not congested, but kept out of the network
when the paths are congested, providing a strong incentive for
applications to adapt to remain within profile. An advantage in terms
of pricing is that, since ECN mechanisms indicate congestion
unambigously, the network edges could rely on them to implement
congestion-pricing schemes. Another potential advantage is to achieve
lower-average-delay for in-profile packets, which could translate to
throughput for bulk-data transfer (especially for high bandwidth
transfers [Stevens, Sec 24.3, pp 346-347]) and enhanced interactive
quality for delay-sensitive interactive applications [Floyd-ECN].
Next we study the benifits from adding the ECN functionality to the
simple differentiated services network considered in section 3. In
what follows, we refer to the the differentiated services network as
simply "the network", where a collection of "interior routers" lie
within a boundary defined by "edge routers" (ingress and egress). The
"edge routers" implement traffic conditioning functions. The term
"profiler" [Clark] is used to denote the component in the edge router
which decides whether a packet is in/out of profile and marks/drops
the out-of-profile packets. The profiler corresponds to the "policer"
or "shaper" in the differentiated services baseline document
[Nichols]. The "interior routers" detect congestion using techniques
based upon RED [RED] or RIO [Clark].
The combination of marking/dropping of out-of-profile packets by the
Kalyanaraman et al [Page 6]
INTERNET-DRAFT 1-bit Feedback Enhanced Diff-Serv March 1998
profiler is currently implementation specific. One extreme is to mark
out-of-profile packets and not drop them (unless they overwhelm local
processing/queueing facilities). This behavior would run into the
problems described in section 3. Another extreme is to drop all out-
of-profile packets, which is again not a good idea if there is no
congestion along the path [Qmgmt]. An intermediate behavior can be
achieved using ECN.
4.1. A Sample ECN-enhanced Differentiated Services Architecture:
A sample architecture for edge-to-edge flow control based upon ECN is
as follows. Profilers at network edges mark out-of-profile packets by
default, but switch over to dropping them during phases of congestion
in the path (indicated by the network using ECN). A ECN-capable
interior router upon detecting congestion drops out-of-profile
packets and sets ECN on in-profile packets of the same flows whose
out-of-profile packets were dropped. The ECN-capable egress router
detects the ECN indication and sends a "notification" packet (which
could be defined to be new "INTERNAL" ICMP type, see section 5) to
the source of the flow for which ECN was set. The egress router also
clears the ECN bit on the packet going in the forward direction
(before the PHB is mapped onto a corresponding PHB in the next
differentiated services network). Assuming that the "notification"
packet passes through the same ingress edge router as that seen by
the packets of the flow in the forward direction. The ECN-capable
ingress router responds to the notification by changing the policy of
conditioning the incoming traffic. For example, some out-of-profile
packets may be dropped for each notification received at the ECN-
capable ingress router (section 4.2 suggests other ECN response
options). The notification packet is filtered by the ingress router
and not propagated further in the direction of the source.
To avoid the implosion of notification messages in a multicast
scenario, the ECN-capable router may set ECN on packets on one of the
many ECN-capable branches (i.e. a branch where an egress node is
known to be ECN-capable). For robustness, a different ECN-capable
branch could be chosen each time. ECN-capable egress routers could
advertise that information by sending a packet (possibly as a new
"INTERNAL" ICMP type, see section 5) in the reverse direction of
flows passing through it (for the benifit of multicast routers).
Ingress routers should filter these advertisement packets out and not
propagate them to the sources of the flows. In case the packet needs
to travel through a tunnel, the ECN bits would also need to be copied
onto the outer header at the tunnel entrance and copied back into the
internal header at the tunnel exit (otherwise ECN-bits set by the
routers in the tunnel will be lost).
The architecture described here can be easily made to interoperate
Kalyanaraman et al [Page 7]
INTERNET-DRAFT 1-bit Feedback Enhanced Diff-Serv March 1998
with current and future ECN-capable transport protocols as follows.
We assume here that the ECN-enabled transport protocols will set the
ECN-capable bit. The routers set the ECN-bit if they are congested.
This "end-to-end" ECN-bit could be the same or separate from the
ECN-bit used in the edge-to-edge flow control described above. The
egress router need not generate a notification packet in the reverse
direction when it sees the ECN-capable bit set, because it would
expect the application to do that on an end-to-end basis (for
example, ECN-TCP would send a notification piggybacked onto its
acknowledgements). The ingress router can also relax its containment
strategy by waiting for an end-to-end ECN response rather than
aggressively controlling the flows using edge-to-edge ECN. Additional
controls could be used to monitor and guard against applications
which fake themselves to be ECN-capable.
It is completely optional for the router to set the ECN bit and for
the ingress edge router to respond to the ECN indication. But the
egress router should reset the bit (unless edge-to-edge ECN shares
the same codespace as end-to-end ECN (the CU bits, see section 5) and
ECN-capable bit is also set) before the packet in forward direction
leaves the network. It is also desireable for the ingress edge router
to filter the notification packet sent by the egress router
irrespective of whether it can or cannot respond to the notification.
Having a flow-control or ECN bit will help the network where (key)
routers set the bit during congestion and (key) profilers which
respond without designing inefficient/incompatible proprietary
methods for feedback. We note that, even without a flow-control bit,
it is possible to use proprietary methods (eg: using explicit rate-
control [TCPRateControl]) between ingress and egress routers. But
these would need to use extra packets to work in an IPsec environment
(overhead), could be complex to implement (cost), and may have
compatibility problems with future ECN-enabled
applications/transports.
4.2 Sample Strategies for Congestion Detection and Response
A sample method for the router to set ECN is as follows. Use the RIO
scheme to manage the queue. When the average out-of-profile queue
length is larger than its min RED thresholds, and a decision has been
made to drop an out-of-profile packet, remember to set ECN on the
next in-profile packet either received or transmitted from the same
flow.
The ingress edge router has several options for responding to the ECN
from the network, for example:
- Delay in-profile packets (do not service the in-profile queue)
- Cut the rate of in-profile packets (eg: use multiplicative
Kalyanaraman et al [Page 8]
INTERNET-DRAFT 1-bit Feedback Enhanced Diff-Serv March 1998
decrease)
- Drop out-of-profile packets
- If packets indicate that the application is ECN-enabled, wait for
the application to respond to the notification, with a backup plan
based on the previous points.
In the most general case, the ingress router can "proxy" as an
adaptive, ECN-enabled transport. It could maintain a separate
transmission rate for in-profile and out-of-profile packets and vary
the rate based upon ECN indications (or the absence of them). A
window-based scheme requires acknowledgements (or exchange of
credits) to maintain the window which is not available in this
architecture.
The out-of-profile drop policy could be adaptive. For example, the
discards of out-of-profile packets could be gradually reduced and
eventually stopped in the absence of further ECN indications. At the
same time, if further ECNs are seen, the drops could be increased
aggressively (eg: exponential increase in the number of out-of-
profile packets to be dropped). Similarly, the "rate" of in-profile
packets can be multiplicatively decreased during consistent ECN
indications and additively increased in the absence of ECN
indications. Packet dropping could also be randomized. The set of
ECN-response strategies which provide adequate performance, stability
and robustness is an open research issue.
5. Standardization Issues:
A simple encoding of the ECN-bit for use in differentiated services
edge-to-edge control can be done in the bits reserved for ECN and
which are currently unused (CU). There are two bits: ECN-capable bit
and ECN-bit. The current (non-standard) interpretation of these bits
is as follows. The ECN-capable transport would set the ECN-capable
bit, and zero the ECN-bit. ECN-capable routers would set the ECN-bit
during congestion periods if the ECN-capable bit is set. Floyd
[Floyd-ECN] suggests that the destination would simply copy the ECN
bits onto the acknowledgement, though additional mechanisms are
needed to distinguish the forward and reverse ECN for scenarios
involving two-way traffic and piggybacked acknowledgements.
The edge-to-edge flow control can work if the differentiated services
ECN-capable routers are configured to mark the ECN-bit even if the
ECN-capable bit is not set. The egress router could identify the
pattern (ECN-capable not set, ECN-bit set) to trigger the edge-to-
edge congestion notification packet, and reset the ECN-bit. The
problem with this encoding is that the definition of CU bits is
currently out of the scope of the differentiated services group
Kalyanaraman et al [Page 9]
INTERNET-DRAFT 1-bit Feedback Enhanced Diff-Serv March 1998
charter and routers within the differentiated services should ignore
their value [Nichols].
An alternative would be to use a bit in the PHB for edge-to-edge ECN
which is within the charter of the differentiated services charter.
The disadvantage is a coding inefficiency, if it turns out later that
the aforementioned CU encoding can be deployed quickly. On the other
hand, the advantage is to interpret the PHB-ECN bit as a internal
service-differentiator, and as an edge-to-edge ECN-based flow control
enabler rather than to interpret edge-to-edge ECN as a special case
of end-to-end ECN-based flow control. Further, it may be possible to
deploy edge-to-edge ECN even when end-to-end ECN is unavailable for
reasons of compatibility or scope of differentiated services
standardization.
The compatibility problems (further explained in section 7) stem from
the fact that end-to-end ECN facilities may not be available on
legacy networks supporting the older TOS semantics. Using a bit in
the PHB also allows edge-to-edge ECN-enabled differentiated services
to be deployed even before the CU bits are agreed upon. We observe
that bits 4 and 5 of the DS-byte are currently undefined. Since
edge-to-edge ECN is completely internal to a differentiated services
network and requires one bit, the only standardization requirement
for edge-to-edge ECN is that at least one of the bits (4 or 5 of the
DS-byte) should be left open for internal definition (for edge-to-
edge ECN or for additional levels of priority drop/queueing or
anything else the administrator wishes).
We have also seen the need to send two kinds of proprietary messages
(for ECN notification and ECN-capable advertisements) in section 4.1.
These messages are meant for edge-to-edge communications and such
messages should be filtered by the border routers/edges of the
differentiated services network. The reason a simple IP packet cannot
be used with the IP addresses of the edge routers themselves is
because packets arriving with the ECN-bit set use source and
destination IP addresses and do not indicate edge router addresses.
Our proposed solution is to standardize a new ICMP type called
"INTERNAL", for proprietary control use within an administrative
domain or a differentiated services network. Additional ICMP codes
can be configured in a proprietary manner to allow multiple
proprietary message types. The "INTERNAL" ICMP type messages could be
used in the future for purposes other than differentiated services as
well.
6. Security Considerations:
The IPSEC tunneling procedure [ESP] copies the TOS (DS) byte of the
encapsulated packet (that is being tunneled) into the outer IP header
Kalyanaraman et al [Page 10]
INTERNET-DRAFT 1-bit Feedback Enhanced Diff-Serv March 1998
at the entrance to the tunnel. However, the byte is currently not
copied back onto the header of the encapsulated packet at the exit of
the tunnel. Hence, any ECN setting by intermediate routers in the
tunnel is lost. Similarly, if one bit in the PHB is left open for
internal use in a differentiated services network, the tunnel routers
cannot participate in the ECN-based edge-to-edge flow control.
ECN does incur a risk of denial-of-service attacks. Assume that the
sources or edges claim to be ECN-capable, but do not respond to ECN
effectively. The router can detect this eventually using a RED-plus-
penalty-box mechanism and penalize misbehaving flows by dropping
their packets. However, the resources used by the dropped packets to
reach the router (as well as the resources used during the time taken
by the router to detect misbehavior) could have been used to service
packets belonging to well-behaving flows - a denial-of-service
attack. The deployment of effective ECN-capable edge routers will
alleviate this problem because the edge routers will be administered
by the same body which wants to guard against denial-of-service
attacks.
7. Compatibility issues:
The IPv4 [RFC791,RFC1349] TOS octet does not support ECN marking. As
a result, end-to-end ECN marking may not be supported in legacy
networks which support the TOS semantics. We note that edge-to-edge
ECN-based flow-control scheme could be supported and enforced within
the differentiated services "cloud" even though an end-to-end ECN-
based feedback facility may not be available.
8. Summary
Using one-bit for ECN-type flow control between the edges of the
differentiated services network can potentially lead to service
differentiation based upon flow-control methods used. Specifically,
there is potential to address some kinds of denial-of-service attacks
using an an edge-to-edge ECN mechanism. The out-of-profile packets of
a flow can be admitted into the network during the absence of
congestion, but kept out (or dropped at the ingress edge) during
congestion along the path of the flow. Other advantages include the
potential for implementing congestion-based pricing schemes, and
building a low-average-delay differentiated service even with a high
degree of resource overbooking. The mechanisms can be made to
interoperate with ECN-TCP or other ECN-enabled transport/application
protocols in the future.
9. Acknowledgements
Thanks are due to Steve Deering for engaging discussions on the
Kalyanaraman et al [Page 11]
INTERNET-DRAFT 1-bit Feedback Enhanced Diff-Serv March 1998
differentiated services mailing list which motivated this draft.
The research was supported in part by DARPA contract number:
F30602-97-C-0274.
10. References
[Clark] D. Clark and J. Wroclawski, "An Approach to Service
Allocation in the Internet", Internet Draft
<draft-clark-diff-svc-alloc-00.txt>, July 1997.
[Deering] S. Deering, communications in integrated services
mailing list, Thread: "support for packet drop
priority", January 1998.
[Ellesson] E. Ellesson and S. Blake, "A Proposal for the Format
and Semantics of the TOS Byte and Traffic Class Byte
in IPv4 and IPv6", Internet Draft
<draft-ellesson-tos-00.txt>, November 1997.
[ESP] S. Kent and R. Atkinson, "IP Encapsulating Security
Payload", Internet Draft
<draft-ietf-ipsec-esp-v2-01.txt>, October 1997.
[Ferguson] P. Ferguson, "Simple Differential Services: IP TOS
and Precedence, Delay Indication, and Drop
Preference, Internet Draft
<draft-ferguson-delay-drop-00.txt>, November 1997.
[Floyd-ECN] S. Floyd, "TCP and Explicit Congestion
Notification", ACM Computer Communication Review,
V. 24 N. 5, October 1994, p. 10-23. URL
"ftp://ftp.ee.lbl.gov/papers/tcp_ecn.4.ps.Z".
[Floyd-RouterMech] S. Floyd, and K. Fall, "Router Mechanisms
to Support End-to-End Congestion Control",
Technical report, February 1997. URL:
"ftp://ftp.ee.lbl.gov/papers/collapse.ps".
[Heinanen] J. Heinanen, "Use of the IPv4 TOS Octet to Support
Differentiated Services", Internet Draft
<draft-heinanen-diff-tos-octet-01.txt>, November 1997.
[IPv6] S. Deering and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", Internet Draft
<draft-ietf-ipngwg-ipv6-spec-v2-01.txt>, November 1997.
[Nichols] K. Nichols, B. Carpenter, "Differentiated Services
Operational Model and Definitions", Internet Draft,
Kalyanaraman et al [Page 12]
INTERNET-DRAFT 1-bit Feedback Enhanced Diff-Serv March 1998
<draft-nichols-dsopdef-00.txt>, February 1998.
[Qmgmt] B. Braden, D. Clark, J. Crowcroft, B. Davie, S.Deering,
D. Estrin, S. Floyd, V. Jacobson, G. Minshall,
C. Partridge, L. Peterson, K. Ramakrishnan, S. Shenker,
J. Wroclawski, L. Zhang, "Recommendations on Queue
Management and Congestion Avoidance in the Internet",
Internet draft draft-irtf-e2e-queue-mgt-00.txt, March,
1997.
[Ramakrishnan] K. Ramakrishnan and S. Floyd, "A Proposal to Add
Explicit Congestion Notification (ECN) to IPv6 and
to TCP", Internet Draft <draft-kksjf-ecn-00.txt>,
November 1997.
[RED] S. Floyd, and V. Jacobson, "Random Early Detection
gateways for Congestion Avoidance", IEEE/ACM
Transactions on Networking, V.1 N.4, August 1993,
p. 397-413. URL
"ftp://ftp.ee.lbl.gov/papers/early.pdf".
[RFC791] Information Sciences Institute, "Internet Protocol",
Internet RFC 791, September 1981.
[RFC1349] P. Almquist, "Type of Service in the Internet Protocol
Suite", Internet RFC 1349, July 1992.
[SIMA] K. Kilkki, "Simple Integrated Media Access (SIMA)",
Internet Draft
<draft-kalevi-simple-media-access-01.txt>,
June 1997.
[Stevens] W. Stevens, "TCP/IP Illustrated, Volume 1",
Addison-Wesley, 1994.
[TCPRateControl] R. Satyavolu, K. Duvedi, S. Kalyanaraman,
"Explicit rate control of TCP applications,"
ATM_Forum/98-0152R1, February 1998. Available from
http://networks.ecse.rpi.edu/~shivkuma/tm-papers.html
[2BIT] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit
Differentiated Services Architecture for the Internet",
Internet Draft <draft-nichols-diff-svc-arch-00.txt>,
November 1997.
Kalyanaraman et al [Page 13]
INTERNET-DRAFT 1-bit Feedback Enhanced Diff-Serv March 1998
Authors:
Shivkumar Kalyanaraman, Surendra Arora, Khem Wanglee, Greg Guarriello
Dept of Electrical, Computer and Systems Engg,
Rensselaer Polytechnic Institute (RPI)
110, 8th Street, Room JEC 6003,
Troy NY 12180-3590
Phone: +1 (518) 276 8979
Fax: +1 (518) 276 2433
Email: shivkuma@ecse.rpi.edu, aroras@rpi.edu, wanglk@rpi.edu,
guarrg@rpi.edu
David Harrison
Department of Computer Science
Rensselear Polytechnic Institute
Troy, NY 12180
Phone: +1 (518) 273 2355
Fax: +1 (518) 276 4033
Email: harrisod@cs.rpi.edu
Kalyanaraman et al [Page 14]