idnits 2.17.1 draft-shivkuma-ecn-diffserv-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 12) being 63 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Stevens' is defined on line 608, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Clark' -- Possible downref: Non-RFC (?) normative reference: ref. 'Deering' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ellesson' -- Possible downref: Non-RFC (?) normative reference: ref. 'ESP' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ferguson' -- Possible downref: Non-RFC (?) normative reference: ref. 'Floyd-ECN' -- Possible downref: Non-RFC (?) normative reference: ref. 'Floyd-RouterMech' -- Possible downref: Non-RFC (?) normative reference: ref. 'Heinanen' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6' -- Possible downref: Non-RFC (?) normative reference: ref. 'Nichols' ** Downref: Normative reference to an Informational draft: draft-irtf-e2e-queue-mgt (ref. 'Qmgmt') -- Possible downref: Non-RFC (?) normative reference: ref. 'Ramakrishnan' -- Possible downref: Non-RFC (?) normative reference: ref. 'RED' ** Obsolete normative reference: RFC 1349 (Obsoleted by RFC 2474) -- Possible downref: Non-RFC (?) normative reference: ref. 'SIMA' -- Possible downref: Non-RFC (?) normative reference: ref. 'Stevens' -- Possible downref: Non-RFC (?) normative reference: ref. 'TCPRateControl' -- Possible downref: Non-RFC (?) normative reference: ref. '2BIT' Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Kalyanaraman/ D. Harrison/ 3 INTERNET-DRAFT S. Arora/ K. Wanglee/ G. Guarriello 4 draft-shivkuma-ecn-diffserv-01.txt Rensselaer Polytechnic Institute 5 March, 1998 6 Expires: September 1998 8 A One-bit Feedback Enhanced Differentiated Services Architecture 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress". 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 27 (US West Coast). 29 Abstract 31 This document proposes the use of one bit in the DS-byte to 32 facilitate ECN-type control in the differentiated services 33 architecture. Specifically during periods of congestion along a 34 flow's path (indicated using the one-bit mechanism), the out-of- 35 profile packets of the flow (packets for which the "In profile" bit 36 is cleared) can be either delayed or dropped by the ingress network 37 edge routers. This scheme would allow interior routers to preserve 38 their resources for processing in-profile packets during congestion 39 and guard against certain types of denial-of-service attacks. The 40 proposed mechanism could also be used to build differentiated 41 services networks with lower average delay, and aid the 42 implementation of congestion-based pricing schemes in such 43 architectures. The mechanism interoperates well with the baseline 44 differentiated services architecture and can also interoperate with 45 ECN-TCP and future ECN-enabled transports/applications. Further, the 46 ECN-type flow control can be deployed within a differentiated 47 services network even if end-to-end ECN support is unavailable, 48 allowing a quick migration path. 50 1. Introduction 52 The DS-byte (formerly TOS octet [RFC791],[RFC1349]) in the IP header 53 is being defined to allow a packet to receive differential treatment 54 depending upon the bits set [Nichols]. The DS-byte is marked by 55 traffic conditioners at the network boundaries. A DS-byte classifier 56 and per-hop behaviors based on those classifications are required in 57 all network nodes of a differentiated-services-capable network. The 58 differentiated services architecture effort is aimed at specifying 59 the number and type of the building blocks and services built from 60 them [Nichols]. 62 The operational model [Nichols] is based upon two sets of proposals. 63 One set of proposals [Ellesson, Ferguson, Heinanen, SIMA] suggests 64 various encodings of the DS-byte to get specific per-hop behaviors 65 from nodes such as low delay, drop preference, priority queueing etc. 66 The other set [Clark, 2BIT] suggests behaviors required from the 67 network as a whole. The DS-byte definition currently allows one bit 68 based upon the latter set, which is used to mark a packet as IN or 69 OUT of its negotiated service profile (we use the term "in-profile" 70 or "out-of-profile" to qualify such packets). Five bits (the per-hop 71 behavior or PHB field) have been kept for defining per-hop behaviors. 72 The last two bits are currently unused (CU) have been reserved for 73 Explicit Congestion Notification (ECN) experimentation. 75 The purpose of this draft is to highlight some features of ECN as it 76 relates to differentiated service, and propose changes in the DS-byte 77 and ICMP message type allocations to help support these features. 78 Specifically, we believe new levels of service differentiation can be 79 created using *any* existing differentiated service class combined 80 with an "edge-to-edge" flow control scheme. The term "edge-to-edge" 81 refers to a proposed control loop between the ingress and egress 82 network edge routers in the differentiated services architecture. 83 Though ECN was originally defined for controling TCP traffic [Floyd- 84 ECN], our proposed edge-to-edge ECN works at the IP layer and can 85 control both TCP and non-TCP, and both unicast and multicast traffic. 86 We propose a new "INTERNAL" ICMP message type to carry notifications 87 from the egress edge to the ingress edge (see section 5), which 88 eliminates the need for any reverse traffic or acknowledgement flow 89 for a session. Within the context of the differentiated services 90 working group charter, we propose the use of one bit which can be 91 used by such "edge-to-edge" flow control schemes. The bits currently 92 reserved for ECN in the DS-byte could be overloaded with this 93 function or a new bit can be used within the PHB for this purpose. 95 We first review ECN concepts in section 2 and discuss problems/issues 96 in a non-ECN differentiated services architecture in section 3. We 97 then describe the role of ECN (specifically the capability to do 98 edge-to-edge flow control) in the differented services architecture 99 in section 4. This discussion includes the description of a sample 100 ECN-enhanced architecture and a set of strategies for ECN generation 101 at routers and response by edge routers. The standardization issues 102 including the possible use of PHB or CU field for edge-to-edge ECN is 103 discussed in section 5. Section 6 outlines ECN issues with IPSEC 104 tunneling and a discussion of its vulnerability to the denial-of- 105 service attack problem. Section 7 discusses compatibility issues with 106 older TOS semantics and section 8 gives a summary. 108 2. Explicit Congestion Notification (ECN) mechanisms 110 The concept of ECN mechanisms for TCP congestion control was 111 developed by Sally Floyd [Floyd-ECN] and there is a recent proposal 112 to reserve two bits for ECN in the IPv6 [IPv6] Class octet 113 [Ramakrishnan]. To allow experimentation in IPv4, two bits (ECN- 114 enabled bit, and ECN bit) in the DS-byte have also been set aside for 115 ECN. As the name suggests ECN mechanisms are used by the network to 116 unambigously declare a state of congestion. ECN-enabled transport 117 protocols (like ECN-TCP) would respond to the notification through a 118 reduction of load. Specifically in the case of TCP it has been 119 suggested [Floyd-ECN] that the ECN response be similar to the 120 response to a detection of packet loss (i.e. halving the source 121 congestion window). There has also been a drive to urge all transport 122 protocols to perform some kind of flow control for the collective 123 benifit they can derive from the network, even though they may or may 124 not care for error control [Floyd-RouterMech]. Since routers can 125 utilize ECN bits to give a transport-neutral congestion indication, 126 ECN is expected to play a significant role in the development of flow 127 control methods in non-TCP transport protocols. As a result, more 128 transport or application protocols could be expected to become "ECN- 129 enabled" in the future. 131 In the context of TCP, ECN provides a clear, if modest benifit 132 [Floyd-ECN]. When a router is entering a congestion phase it could 133 use ECN instead of packet discard to notify the sources about 134 congestion. ECN-enabled routers could set the ECN bit if the ECN- 135 enabled bit is set on a packet instead of dropping the packet. The 136 destination then sets the ECN bit in the acknowledgement to notify 137 the source. The source responds by cutting its window size. Avoiding 138 unnecessary packet drops is particularly attractive to low bandwidth, 139 interactive applications [Floyd-ECN]. Bulk-data transfer applications 140 using ECN-TCP get high throughput over a wide range of conditions and 141 parameter values (TCP clock granularity, TCP window size, RED gateway 142 variation etc). 144 The authors of this document were inspired by two features of ECN: 145 the transport-neutral feedback property which would be used to 146 provide service differentiation at the IP-layer, and the potential of 147 ECN to provide resistance to certain kinds of denial-of-service 148 attacks and control the average delay inside the differentiated- 149 services-network. 151 3. Issues in a non-ECN differentiated services network: 153 Consider a simple differentiated service network which provides a 154 packet-drop priority for packets which are marked in-profile (i.e, 155 out-of-profile packets are dropped before in-profile packets during 156 congestion). Deering [Deering] argued that this situation may create 157 a positive incentive for sources to overdrive the network by sending 158 an unlimited amount of out-of-profile packets. An example is a source 159 using layered encodings, but no congestion backoff. Misbehaving TCP 160 sources (hacked or otherwise) also belong to this category. 162 When a node in the path is congested, out-of-profile packets are 163 dropped first before dropping in-profile packets. The dropping of an 164 out-of-profile packet inside the differentiated services network can 165 be construed as a waste of shared resources consumed by the packet to 166 reach the node where it was dropped. These wasted resources could 167 have been utilized to service other in-profile packets or even other 168 out-of-profile packets which could have made it to their destinations 169 - a type of denial-of-service attack. Deering [Deering] showed an 170 example where this can happen and we reproduce it here (with some 171 editing to motivate ECN): 173 In the following diagram, S1 and S2 are sources of traffic sending to 174 receivers R1 and R2, respectively. A through F are routers, and the 175 numbers in angle brackets are the capacities of the links in Kbps. 177 S1 ---<300>--- A E ---<300>--- R2 178 \ / 179 \ / 180 C ---<300>--- D 181 / \ 182 / \ 183 S2 ---<300>--- B F ----<50>--- R1 185 Assume that each of the two sources is sending a 50 Kbps voice stream 186 and a 200 Kbps video stream to its corresponding receiver, as part of 187 a teleconferencing application. And assume that that's the only 188 traffic in this simple network. 190 Further assume that both S1 and S2 are marking (by use of a 1-bit or 191 multi- bit drop-preference field) all their video packets as "out- 192 of-profile" or "less important" than their voice packets, so that if 193 congestion is encountered, the video packets will be discarded before 194 the audio packets, to avoid audio degradation if at all possible. 196 Assuming the less important packets are dropped by the routers in 197 favor of more important packets, and that packets of the same 198 importance are dropped with equal probability, C will discard half of 199 S1's video packets and half of S2's video packets, and F will discard 200 the rest of S1's video packets. R1 will receive only S1's voice 201 packets. R2 will receive S2's voice packets plus half of S2's video 202 packets. Thus, S1, by sending video (or "out-of-profile") packets 203 that cannot be delivered to R1, has denied half of S2's video packets 204 access to the C-D link. (Further, if R2 is unable to produce an 205 acceptible video image from only half of the video packets, the 206 bandwidth consumed by those packets is also wasted, which could, in 207 turn, deny bandwidth to other traffic flows in a more general 208 example.) If S1 were instead to refrain from sending its 209 undeliverable video packets, or were informed via feedback that the 210 video packets were in fact undeliverable, R2 could receive the 211 complete (or a considerably better) video stream from S2. 213 The key point is that upstream *shared* resources were wasted by 214 out-of-profile packets which would never reach their destination. The 215 need is therefore to develop network mechanisms, which can be used as 216 building blocks to provide positive incentives for applications to 217 adapt (keep all its traffic in-profile) and disincentives for those 218 that do not adapt. We look at one such mechanism, RED-plus-penalty- 219 box next and discuss its limitations to motivate the need for edge- 220 to-edge ECN. 222 3.1 RED-plus-penalty-box: 224 One way to set up the system of incentives for end-to-end flow 225 control is the "RED-plus-penalty-box" [RED] approach where a simple 226 accounting technique in addition to Random Early Detection (RED) 227 algorithm can help identify misbehaving connections, which would then 228 be treated differently. The utility of this method is constrained in 229 the differentiated services framework because in-profile packets are 230 expected to be serviced uniformly for both well-behaving and 231 misbehaving flows. Dropping more out-of-profile packets of the 232 misbehaving flow than the others, while certainly a benifit, does not 233 prevent the waste of resources upstream by this flow ("upstream" and 234 "downstream" are defined in terms of the flows and the router where 235 the packet is dropped). 237 "RED-plus-penalty-box" can still be used to avoid wastage of upstream 238 resources - by requiring that all nodes in the differentiated 239 services network implement the "penalty-box" scheme and identify 240 misbehaving flows even if they are not congested. Then out-of- 241 profile packets belonging to the misbehaving flow (detected close to 242 the entrance of the network) could be dropped at a higher rate even 243 though there is no local congestion at the node. There are two 244 problems with this scheme: first, when there is no congestion 245 downstream, there is no need to identify the misbehaving flow and 246 drop its out-of-profile packets. Second, it requires *all* nodes to 247 implement the penalty-box scheme. 249 4. Role of ECN in the Differentiated Services Architecture: 251 We show in this section that schemes based upon ECN can be used to 252 identify misbehaving sources which concentrate all "penalty" actions 253 in the traffic conditioners at the edge of the network. Therefore all 254 nodes need not implement the penalty actions. Moreover this behavior 255 is possible while interoperating with ECN-enabled transports - the 256 edges could choose not to impose edge-to-edge flow control if end- 257 to-end flow control is enabled (subject to monitoring and policing). 259 More generally, the traffic conditioners at the network edges could 260 "proxy" as ECN-capable transports. These schemes would have the 261 desirable property that out-of-profile packets are admitted into the 262 differentiated services network when the paths traversed by the flows 263 which they belong to are not congested, but kept out of the network 264 when the paths are congested, providing a strong incentive for 265 applications to adapt to remain within profile. An advantage in terms 266 of pricing is that, since ECN mechanisms indicate congestion 267 unambigously, the network edges could rely on them to implement 268 congestion-pricing schemes. Another potential advantage is to achieve 269 lower-average-delay for in-profile packets, which could translate to 270 throughput for bulk-data transfer (especially for high bandwidth 271 transfers [Stevens, Sec 24.3, pp 346-347]) and enhanced interactive 272 quality for delay-sensitive interactive applications [Floyd-ECN]. 274 Next we study the benifits from adding the ECN functionality to the 275 simple differentiated services network considered in section 3. In 276 what follows, we refer to the the differentiated services network as 277 simply "the network", where a collection of "interior routers" lie 278 within a boundary defined by "edge routers" (ingress and egress). The 279 "edge routers" implement traffic conditioning functions. The term 280 "profiler" [Clark] is used to denote the component in the edge router 281 which decides whether a packet is in/out of profile and marks/drops 282 the out-of-profile packets. The profiler corresponds to the "policer" 283 or "shaper" in the differentiated services baseline document 284 [Nichols]. The "interior routers" detect congestion using techniques 285 based upon RED [RED] or RIO [Clark]. 287 The combination of marking/dropping of out-of-profile packets by the 288 profiler is currently implementation specific. One extreme is to mark 289 out-of-profile packets and not drop them (unless they overwhelm local 290 processing/queueing facilities). This behavior would run into the 291 problems described in section 3. Another extreme is to drop all out- 292 of-profile packets, which is again not a good idea if there is no 293 congestion along the path [Qmgmt]. An intermediate behavior can be 294 achieved using ECN. 296 4.1. A Sample ECN-enhanced Differentiated Services Architecture: 298 A sample architecture for edge-to-edge flow control based upon ECN is 299 as follows. Profilers at network edges mark out-of-profile packets by 300 default, but switch over to dropping them during phases of congestion 301 in the path (indicated by the network using ECN). A ECN-capable 302 interior router upon detecting congestion drops out-of-profile 303 packets and sets ECN on in-profile packets of the same flows whose 304 out-of-profile packets were dropped. The ECN-capable egress router 305 detects the ECN indication and sends a "notification" packet (which 306 could be defined to be new "INTERNAL" ICMP type, see section 5) to 307 the source of the flow for which ECN was set. The egress router also 308 clears the ECN bit on the packet going in the forward direction 309 (before the PHB is mapped onto a corresponding PHB in the next 310 differentiated services network). Assuming that the "notification" 311 packet passes through the same ingress edge router as that seen by 312 the packets of the flow in the forward direction. The ECN-capable 313 ingress router responds to the notification by changing the policy of 314 conditioning the incoming traffic. For example, some out-of-profile 315 packets may be dropped for each notification received at the ECN- 316 capable ingress router (section 4.2 suggests other ECN response 317 options). The notification packet is filtered by the ingress router 318 and not propagated further in the direction of the source. 320 To avoid the implosion of notification messages in a multicast 321 scenario, the ECN-capable router may set ECN on packets on one of the 322 many ECN-capable branches (i.e. a branch where an egress node is 323 known to be ECN-capable). For robustness, a different ECN-capable 324 branch could be chosen each time. ECN-capable egress routers could 325 advertise that information by sending a packet (possibly as a new 326 "INTERNAL" ICMP type, see section 5) in the reverse direction of 327 flows passing through it (for the benifit of multicast routers). 328 Ingress routers should filter these advertisement packets out and not 329 propagate them to the sources of the flows. In case the packet needs 330 to travel through a tunnel, the ECN bits would also need to be copied 331 onto the outer header at the tunnel entrance and copied back into the 332 internal header at the tunnel exit (otherwise ECN-bits set by the 333 routers in the tunnel will be lost). 335 The architecture described here can be easily made to interoperate 336 with current and future ECN-capable transport protocols as follows. 337 We assume here that the ECN-enabled transport protocols will set the 338 ECN-capable bit. The routers set the ECN-bit if they are congested. 339 This "end-to-end" ECN-bit could be the same or separate from the 340 ECN-bit used in the edge-to-edge flow control described above. The 341 egress router need not generate a notification packet in the reverse 342 direction when it sees the ECN-capable bit set, because it would 343 expect the application to do that on an end-to-end basis (for 344 example, ECN-TCP would send a notification piggybacked onto its 345 acknowledgements). The ingress router can also relax its containment 346 strategy by waiting for an end-to-end ECN response rather than 347 aggressively controlling the flows using edge-to-edge ECN. Additional 348 controls could be used to monitor and guard against applications 349 which fake themselves to be ECN-capable. 351 It is completely optional for the router to set the ECN bit and for 352 the ingress edge router to respond to the ECN indication. But the 353 egress router should reset the bit (unless edge-to-edge ECN shares 354 the same codespace as end-to-end ECN (the CU bits, see section 5) and 355 ECN-capable bit is also set) before the packet in forward direction 356 leaves the network. It is also desireable for the ingress edge router 357 to filter the notification packet sent by the egress router 358 irrespective of whether it can or cannot respond to the notification. 359 Having a flow-control or ECN bit will help the network where (key) 360 routers set the bit during congestion and (key) profilers which 361 respond without designing inefficient/incompatible proprietary 362 methods for feedback. We note that, even without a flow-control bit, 363 it is possible to use proprietary methods (eg: using explicit rate- 364 control [TCPRateControl]) between ingress and egress routers. But 365 these would need to use extra packets to work in an IPsec environment 366 (overhead), could be complex to implement (cost), and may have 367 compatibility problems with future ECN-enabled 368 applications/transports. 370 4.2 Sample Strategies for Congestion Detection and Response 372 A sample method for the router to set ECN is as follows. Use the RIO 373 scheme to manage the queue. When the average out-of-profile queue 374 length is larger than its min RED thresholds, and a decision has been 375 made to drop an out-of-profile packet, remember to set ECN on the 376 next in-profile packet either received or transmitted from the same 377 flow. 379 The ingress edge router has several options for responding to the ECN 380 from the network, for example: 382 - Delay in-profile packets (do not service the in-profile queue) 383 - Cut the rate of in-profile packets (eg: use multiplicative 384 decrease) 385 - Drop out-of-profile packets 386 - If packets indicate that the application is ECN-enabled, wait for 387 the application to respond to the notification, with a backup plan 388 based on the previous points. 390 In the most general case, the ingress router can "proxy" as an 391 adaptive, ECN-enabled transport. It could maintain a separate 392 transmission rate for in-profile and out-of-profile packets and vary 393 the rate based upon ECN indications (or the absence of them). A 394 window-based scheme requires acknowledgements (or exchange of 395 credits) to maintain the window which is not available in this 396 architecture. 398 The out-of-profile drop policy could be adaptive. For example, the 399 discards of out-of-profile packets could be gradually reduced and 400 eventually stopped in the absence of further ECN indications. At the 401 same time, if further ECNs are seen, the drops could be increased 402 aggressively (eg: exponential increase in the number of out-of- 403 profile packets to be dropped). Similarly, the "rate" of in-profile 404 packets can be multiplicatively decreased during consistent ECN 405 indications and additively increased in the absence of ECN 406 indications. Packet dropping could also be randomized. The set of 407 ECN-response strategies which provide adequate performance, stability 408 and robustness is an open research issue. 410 5. Standardization Issues: 412 A simple encoding of the ECN-bit for use in differentiated services 413 edge-to-edge control can be done in the bits reserved for ECN and 414 which are currently unused (CU). There are two bits: ECN-capable bit 415 and ECN-bit. The current (non-standard) interpretation of these bits 416 is as follows. The ECN-capable transport would set the ECN-capable 417 bit, and zero the ECN-bit. ECN-capable routers would set the ECN-bit 418 during congestion periods if the ECN-capable bit is set. Floyd 419 [Floyd-ECN] suggests that the destination would simply copy the ECN 420 bits onto the acknowledgement, though additional mechanisms are 421 needed to distinguish the forward and reverse ECN for scenarios 422 involving two-way traffic and piggybacked acknowledgements. 424 The edge-to-edge flow control can work if the differentiated services 425 ECN-capable routers are configured to mark the ECN-bit even if the 426 ECN-capable bit is not set. The egress router could identify the 427 pattern (ECN-capable not set, ECN-bit set) to trigger the edge-to- 428 edge congestion notification packet, and reset the ECN-bit. The 429 problem with this encoding is that the definition of CU bits is 430 currently out of the scope of the differentiated services group 431 charter and routers within the differentiated services should ignore 432 their value [Nichols]. 434 An alternative would be to use a bit in the PHB for edge-to-edge ECN 435 which is within the charter of the differentiated services charter. 436 The disadvantage is a coding inefficiency, if it turns out later that 437 the aforementioned CU encoding can be deployed quickly. On the other 438 hand, the advantage is to interpret the PHB-ECN bit as a internal 439 service-differentiator, and as an edge-to-edge ECN-based flow control 440 enabler rather than to interpret edge-to-edge ECN as a special case 441 of end-to-end ECN-based flow control. Further, it may be possible to 442 deploy edge-to-edge ECN even when end-to-end ECN is unavailable for 443 reasons of compatibility or scope of differentiated services 444 standardization. 446 The compatibility problems (further explained in section 7) stem from 447 the fact that end-to-end ECN facilities may not be available on 448 legacy networks supporting the older TOS semantics. Using a bit in 449 the PHB also allows edge-to-edge ECN-enabled differentiated services 450 to be deployed even before the CU bits are agreed upon. We observe 451 that bits 4 and 5 of the DS-byte are currently undefined. Since 452 edge-to-edge ECN is completely internal to a differentiated services 453 network and requires one bit, the only standardization requirement 454 for edge-to-edge ECN is that at least one of the bits (4 or 5 of the 455 DS-byte) should be left open for internal definition (for edge-to- 456 edge ECN or for additional levels of priority drop/queueing or 457 anything else the administrator wishes). 459 We have also seen the need to send two kinds of proprietary messages 460 (for ECN notification and ECN-capable advertisements) in section 4.1. 461 These messages are meant for edge-to-edge communications and such 462 messages should be filtered by the border routers/edges of the 463 differentiated services network. The reason a simple IP packet cannot 464 be used with the IP addresses of the edge routers themselves is 465 because packets arriving with the ECN-bit set use source and 466 destination IP addresses and do not indicate edge router addresses. 467 Our proposed solution is to standardize a new ICMP type called 468 "INTERNAL", for proprietary control use within an administrative 469 domain or a differentiated services network. Additional ICMP codes 470 can be configured in a proprietary manner to allow multiple 471 proprietary message types. The "INTERNAL" ICMP type messages could be 472 used in the future for purposes other than differentiated services as 473 well. 475 6. Security Considerations: 477 The IPSEC tunneling procedure [ESP] copies the TOS (DS) byte of the 478 encapsulated packet (that is being tunneled) into the outer IP header 479 at the entrance to the tunnel. However, the byte is currently not 480 copied back onto the header of the encapsulated packet at the exit of 481 the tunnel. Hence, any ECN setting by intermediate routers in the 482 tunnel is lost. Similarly, if one bit in the PHB is left open for 483 internal use in a differentiated services network, the tunnel routers 484 cannot participate in the ECN-based edge-to-edge flow control. 486 ECN does incur a risk of denial-of-service attacks. Assume that the 487 sources or edges claim to be ECN-capable, but do not respond to ECN 488 effectively. The router can detect this eventually using a RED-plus- 489 penalty-box mechanism and penalize misbehaving flows by dropping 490 their packets. However, the resources used by the dropped packets to 491 reach the router (as well as the resources used during the time taken 492 by the router to detect misbehavior) could have been used to service 493 packets belonging to well-behaving flows - a denial-of-service 494 attack. The deployment of effective ECN-capable edge routers will 495 alleviate this problem because the edge routers will be administered 496 by the same body which wants to guard against denial-of-service 497 attacks. 499 7. Compatibility issues: 501 The IPv4 [RFC791,RFC1349] TOS octet does not support ECN marking. As 502 a result, end-to-end ECN marking may not be supported in legacy 503 networks which support the TOS semantics. We note that edge-to-edge 504 ECN-based flow-control scheme could be supported and enforced within 505 the differentiated services "cloud" even though an end-to-end ECN- 506 based feedback facility may not be available. 508 8. Summary 510 Using one-bit for ECN-type flow control between the edges of the 511 differentiated services network can potentially lead to service 512 differentiation based upon flow-control methods used. Specifically, 513 there is potential to address some kinds of denial-of-service attacks 514 using an an edge-to-edge ECN mechanism. The out-of-profile packets of 515 a flow can be admitted into the network during the absence of 516 congestion, but kept out (or dropped at the ingress edge) during 517 congestion along the path of the flow. Other advantages include the 518 potential for implementing congestion-based pricing schemes, and 519 building a low-average-delay differentiated service even with a high 520 degree of resource overbooking. The mechanisms can be made to 521 interoperate with ECN-TCP or other ECN-enabled transport/application 522 protocols in the future. 524 9. Acknowledgements 526 Thanks are due to Steve Deering for engaging discussions on the 527 differentiated services mailing list which motivated this draft. 529 The research was supported in part by DARPA contract number: 530 F30602-97-C-0274. 532 10. References 534 [Clark] D. Clark and J. Wroclawski, "An Approach to Service 535 Allocation in the Internet", Internet Draft 536 , July 1997. 538 [Deering] S. Deering, communications in integrated services 539 mailing list, Thread: "support for packet drop 540 priority", January 1998. 542 [Ellesson] E. Ellesson and S. Blake, "A Proposal for the Format 543 and Semantics of the TOS Byte and Traffic Class Byte 544 in IPv4 and IPv6", Internet Draft 545 , November 1997. 547 [ESP] S. Kent and R. Atkinson, "IP Encapsulating Security 548 Payload", Internet Draft 549 , October 1997. 551 [Ferguson] P. Ferguson, "Simple Differential Services: IP TOS 552 and Precedence, Delay Indication, and Drop 553 Preference, Internet Draft 554 , November 1997. 556 [Floyd-ECN] S. Floyd, "TCP and Explicit Congestion 557 Notification", ACM Computer Communication Review, 558 V. 24 N. 5, October 1994, p. 10-23. URL 559 "ftp://ftp.ee.lbl.gov/papers/tcp_ecn.4.ps.Z". 561 [Floyd-RouterMech] S. Floyd, and K. Fall, "Router Mechanisms 562 to Support End-to-End Congestion Control", 563 Technical report, February 1997. URL: 564 "ftp://ftp.ee.lbl.gov/papers/collapse.ps". 566 [Heinanen] J. Heinanen, "Use of the IPv4 TOS Octet to Support 567 Differentiated Services", Internet Draft 568 , November 1997. 570 [IPv6] S. Deering and R. Hinden, "Internet Protocol, Version 6 571 (IPv6) Specification", Internet Draft 572 , November 1997. 574 [Nichols] K. Nichols, B. Carpenter, "Differentiated Services 575 Operational Model and Definitions", Internet Draft, 576 , February 1998. 578 [Qmgmt] B. Braden, D. Clark, J. Crowcroft, B. Davie, S.Deering, 579 D. Estrin, S. Floyd, V. Jacobson, G. Minshall, 580 C. Partridge, L. Peterson, K. Ramakrishnan, S. Shenker, 581 J. Wroclawski, L. Zhang, "Recommendations on Queue 582 Management and Congestion Avoidance in the Internet", 583 Internet draft draft-irtf-e2e-queue-mgt-00.txt, March, 584 1997. 586 [Ramakrishnan] K. Ramakrishnan and S. Floyd, "A Proposal to Add 587 Explicit Congestion Notification (ECN) to IPv6 and 588 to TCP", Internet Draft , 589 November 1997. 591 [RED] S. Floyd, and V. Jacobson, "Random Early Detection 592 gateways for Congestion Avoidance", IEEE/ACM 593 Transactions on Networking, V.1 N.4, August 1993, 594 p. 397-413. URL 595 "ftp://ftp.ee.lbl.gov/papers/early.pdf". 597 [RFC791] Information Sciences Institute, "Internet Protocol", 598 Internet RFC 791, September 1981. 600 [RFC1349] P. Almquist, "Type of Service in the Internet Protocol 601 Suite", Internet RFC 1349, July 1992. 603 [SIMA] K. Kilkki, "Simple Integrated Media Access (SIMA)", 604 Internet Draft 605 , 606 June 1997. 608 [Stevens] W. Stevens, "TCP/IP Illustrated, Volume 1", 609 Addison-Wesley, 1994. 611 [TCPRateControl] R. Satyavolu, K. Duvedi, S. Kalyanaraman, 612 "Explicit rate control of TCP applications," 613 ATM_Forum/98-0152R1, February 1998. Available from 614 http://networks.ecse.rpi.edu/~shivkuma/tm-papers.html 616 [2BIT] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit 617 Differentiated Services Architecture for the Internet", 618 Internet Draft , 619 November 1997. 621 Authors: 623 Shivkumar Kalyanaraman, Surendra Arora, Khem Wanglee, Greg Guarriello 624 Dept of Electrical, Computer and Systems Engg, 625 Rensselaer Polytechnic Institute (RPI) 626 110, 8th Street, Room JEC 6003, 627 Troy NY 12180-3590 628 Phone: +1 (518) 276 8979 629 Fax: +1 (518) 276 2433 630 Email: shivkuma@ecse.rpi.edu, aroras@rpi.edu, wanglk@rpi.edu, 631 guarrg@rpi.edu 633 David Harrison 634 Department of Computer Science 635 Rensselear Polytechnic Institute 636 Troy, NY 12180 637 Phone: +1 (518) 273 2355 638 Fax: +1 (518) 276 4033 639 Email: harrisod@cs.rpi.edu