RFC 4774
Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field
RFC 4774: Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field 🎀
okay bestie, let's get the vibes straight first 💅 This is RFC 4774, written by S. Floyd from ICIR and published in November 2006. It's a Best Current Practice (BCP 124), so it's the community's recommended way of doing things rather than a single protocol spec. It's about what happens when people want to give the ECN field in the IP header new meanings, and whether that can coexist with routers that don't know about the new meanings yet 🦋 The header doesn't list any RFCs it obsoletes or updates, so this one stands on its own ✨
Status of This Memo
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2006).
Abstract
There have been a number of proposals for alternate semantics for the Explicit Congestion Notification (ECN) field in the IP header RFC 3168. This document discusses some of the issues in defining alternate semantics for the ECN field, and specifies requirements for a safe coexistence in an Internet that could include routers that do not understand the defined alternate semantics. This document evolved as a result of discussions with the authors of one recent proposal for such alternate semantics. 🌸
Table of Contents
1. Introduction ....................................................2
2. An Overview of the Issues .......................................3
3. Signalling the Use of Alternate ECN Semantics ...................4
3.1. Using the Diffserv Field for Signalling ....................5
4. Issues of Incremental Deployment ................................6
4.1. Option 1: Unsafe for Deployment in the Internet ...........7
4.2. Option 2: Verification that Routers Understand the
Alternate ..................................................8
4.3. Option 3: Friendly Coexistence with Competing Traffic .....8
5. Evaluation of the Alternate ECN Semantics ......................10
5.1. Verification of Feedback from the Router ..................10
5.2. Coexistence with Competing Traffic ........................11
5.3. Proposals for Alternate ECN with Edge-to-Edge Semantics ...12
5.4. Encapsulated Packets ......................................12
5.5. A General Evaluation of the Alternate ECN Semantics .......12
6. Security Considerations ........................................12
7. Conclusions ....................................................13
8. Acknowledgements ...............................................13
9. Normative References ...........................................13
10. Informative References ........................................131. Introduction ✨
okay so [RFC3168] is a Proposed Standard, and it's the document that defines the ECN field in the IP header and spells out what the codepoints for that field mean. The catch is that end nodes could also choose to use alternate semantics for the ECN field, for example by using codepoints in the diffserv field of the IP header 👀
There have been a lot of proposals, both in the IETF and in the research community, for alternate semantics for the ECN codepoint, and honestly it's giving busy 🔥 One of them, [BCF05], suggests alternate ECN semantics for real-time inelastic traffic like voice, video conferencing, and multimedia streaming in DiffServ networks. In that proposal, the alternate semantics would tell you about two levels of congestion experienced along the path [BCF05]. Another research proposal, [XSSK05], introduces a low-complexity protocol called Variable-structure congestion Control Protocol (VCP). It uses the two bits in the ECN field to signal low-load, high-load, and overload (congestion), so transport protocols can ramp up more quickly during the low-load regime 🚀 Some of the proposals are meant for when ECN is used edge-to-edge, between gateways at the edge of a network region. One example is pre-congestion notification for admissions control [BESFC06]. Other proposals are listed on the ECN Web Page [ECN] 🌈
Here's the tea 🍵 Defining multiple semantics for the ECN field could have a big impact on both host and router implementations. The Internet, and other IP networks, have a huge base of hosts and routers already installed, and updating all of them is an enormous, potentially expensive job 😭 Some existing devices might handle the new ECN semantics with just a software upgrade and no real loss in performance. Some other equipment might handle them, but with a performance hit that could be anywhere from trivial to catastrophic 💀 And some deployed equipment could only support the new semantics with a hardware upgrade, which in some cases could be prohibitively expensive to roll out on a very wide scale. Because of all this, universally deploying any new ECN semantics would be difficult and would take a significant amount of time. Routers are especially tricky to upgrade, since small routers aren't always updated often, and large routers commonly have specialized forwarding paths to get high performance 🧚
So this document digs into the technical issues that come up when specifying alternate semantics for the ECN field. It also gives requirements for a safe coexistence in a world that's using the default ECN semantics, or using no ECN at all 🫶
2. An Overview of the Issues 💜
In this section, we talk through some of the issues that come up if some of the traffic in a network is alternate-ECN traffic (that is, traffic using alternate semantics for the ECN field). The issues are: (1) how routers know which ECN semantics to use with which packets; (2) incremental deployment in a network where some routers use only the default ECN semantics or don't use ECN at all; (3) coexistence of alternate-ECN traffic with competing traffic on the path; and (4) a general evaluation of the alternate ECN semantics.
(1) The first issue is about how routers know which ECN semantics to use with which packets in the network:
How does the connection indicate to the router that its packets are using alternate ECN semantics? Is the specification of alternate-ECN semantics robust and unambiguous? If not, is this a problem?
For example, in most of the proposals for alternate ECN semantics, a diffserv field is used to specify that alternate ECN semantics are in use. Do all routers that understand this diffserv codepoint understand that it means alternate ECN semantics, or not? Diffserv lets routers re-mark DiffServ Code Point (DSCP) values within the network. So what does that do to the alternate ECN semantics? 🤔
This is covered in more detail in Section 3 below.
(2) The second issue is incremental deployment in a network where some routers only use the default ECN semantics, and other routers might not use ECN at all. In this document, we use the phrase "new routers" for routers that understand the alternate ECN semantics, and "old routers" for routers that don't understand the alternate ECN semantics or aren't willing to use them 🎀
The possible existence of old routers raises this question: how does the possible presence of old routers affect the performance of the alternate-ECN connections?
(3) The possible existence of old routers also raises the question of how their presence affects the coexistence of alternate-ECN traffic with competing traffic on the path.
Issues (2) and (3) are discussed in Section 4 below.
(4) The final issue is the general evaluation of the alternate ECN semantics:
How well does the alternate-ECN traffic perform, and how well does it coexist with competing traffic on the path, in a "clean" environment with new routers and with the unambiguous specification of the use of alternate ECN semantics?
These issues are discussed in Section 5.
3. Signalling the Use of Alternate ECN Semantics 🦋
This section takes on question (1) from Section 2:
(1) How does the connection indicate to the router that its packets are using alternate ECN semantics? Is the specification of alternate ECN semantics robust and unambiguous? If not, is this a problem?
The assumption in this document is that when alternate semantics are defined for the ECN field, a codepoint in the diffserv field is used to signal to the router that those alternate ECN semantics are in use. In other words, the end host sets the codepoint in the diffserv field to tell routers that the ECN field is being used with alternate semantics. Routers that understand this diffserv codepoint would know to use the alternate semantics when interpreting and setting the ECN field. Old ECN-capable routers that don't understand this diffserv codepoint would use the default ECN semantics when interpreting and setting the ECN field 💖
In general, diffserv codepoints are used to signal the per-hop behavior at router queues. One option would be to use one diffserv codepoint for a per-hop behavior with the default ECN semantics, and a separate diffserv codepoint for a similar per-hop behavior with the alternate ECN semantics. Another option would be to use a diffserv codepoint to signal best-effort per-hop queueing and scheduling behavior, but with alternate ECN semantics. A detailed discussion of these issues is beyond the scope of this document 🌸
We should note that this discussion doesn't rule out other methods, including out-of-band mechanisms, for signalling the use of alternate semantics for the ECN field. The considerations in the rest of this document apply no matter which method is used to signal the use of alternate semantics for the ECN field ✨
3.1. Using the Diffserv Field for Signalling 🍓
Here's a key detail 👀 The default ECN semantics defined in RFC 3168 are the current default for the ECN field, regardless of what's in any other field of the IP header. Specifically, the default ECN semantics apply to more than best-effort traffic with a codepoint of '000000' for the diffserv field. The default ECN semantics currently apply regardless of what's in the diffserv field 💅
There are two ways to use the diffserv field to signal the use of alternate ECN semantics. The first is to take an existing diffserv codepoint and modify its current definition, through approved IETF processes, so that it specifies alternate ECN semantics. The second is to define a new diffserv codepoint and specify alternate ECN semantics for it. The first option raises a possibility we need to watch out for 🚨 Some routers along the path would understand the diffserv codepoint but would use the default ECN semantics with it, or wouldn't use ECN at all. Other routers would use the alternate ECN semantics with that same codepoint. That mismatch is exactly the kind of thing that makes this so tricky, bestie 😭
(Part 1 of 4 is done! 🎀 Part 2 is coming up next, so stay tuned for Section 4 and everything after it 🌈)
4. Issues of Incremental Deployment ✨
okay so this section tackles questions (2) and (3) from Section 2 🫶
- (2) How does the possible presence of old routers affect the performance of the alternate-ECN connections?
- (3) How does the possible presence of old routers affect the coexistence of the alternate-ECN traffic with competing traffic on the path?
bestie, the core idea is that when you define alternate semantics for the ECN field, you have to make sure old routers along the path that don't understand those semantics don't cause problems 🙈
One possible problem is poor performance for the alternate-ECN traffic. Is it essential to the performance of that traffic that every router on the path understands the alternate ECN semantics? If not, what can happen to the alternate-ECN traffic itself when some old routers don't get it? 🤔 You have to answer these questions for each specific proposal for alternate ECN semantics. no shortcuts, babe 💅
A second problem is possible unfair competition with other traffic on the path. Say there's an old router that doesn't use ECN. That router could drop packets from the alternate-ECN traffic and expect the alternate-ECN traffic to slow down because of it. So the real question is: does the alternate-ECN traffic respond to packet drops as a sign of congestion? 👀
|--------|
Alternate-ECN traffic ----> | | ---> CE-marked packet
| Old |
Non-ECN traffic ----------> | Router | ---> dropped packet
| |
RFC-3168 ECN traffic -----> | | ---> CE-marked packet
|--------|
Figure 1: Alternate-ECN traffic, an old router, using RFC-3168 ECN,
that is congested and ready to drop or mark the arriving packet.Now what if there's an old router on the path that only understands the default ECN semantics from RFC 3168, like in Figure 1 above? 🧚 When it's congested, that old default-ECN router could see an alternate-ECN packet with one of the ECN-Capable Transport (ECT) codepoints set in the ECN field in the IP header (as defined in RFC 3168). Instead of dropping the packet, it could set the Congestion Experienced (CE) codepoint in the ECN field. The router expects the alternate-ECN connection to respond with congestion control just like it would if the packet had been dropped. ✨
Here's the drama 😭 If the alternate-ECN traffic doesn't respond properly to a CE codepoint set by an old router, the total traffic arriving at that old router could go up. That means more packet marking and more packet dropping at that router, and then the alternate-ECN traffic ends up crowding out the other traffic competing for bandwidth on that link. not slay at all 💀
Basically, there are three ways to avoid scenarios where old routers on the path make the alternate-ECN traffic compete unfairly with other traffic:
- Option 1: Alternate-ECN traffic is clearly understood as unsafe for deployment in the global Internet; or
- Option 2: All alternate-ECN traffic deploys some mechanism for verifying that all routers on the path understand and agree to use the alternate ECN semantics for this traffic; or
- Option 3: The alternate ECN semantics are defined in such a way as to ensure the fair and peaceful coexistence of the alternate-ECN traffic with best-effort and other traffic, even in environments that include old routers that do not understand the alternate ECN semantics.
Each of these gets a closer look below 🌸
4.1. Option 1: Unsafe for Deployment in the Internet
The first option is for alternate-ECN traffic to be clearly understood as only suitable for enclosed environments and as unsafe for the global Internet. 🙅♀️ Specifically, that would mean it's unsafe to let packets using the alternate ECN semantics loose on the global Internet. This restriction would keep alternate-ECN traffic from crossing an old router outside the enclosed environment that doesn't understand the alternate semantics. This document doesn't say whether a mechanism would be required to make sure the alternate ECN semantics never get let loose on the global Internet. It also doesn't comment on how likely the IETF community would be to accept this scenario for standardization. 🤷♀️
4.2. Option 2: Verification that Routers Understand the Alternate Semantics
The second option is for alternate-ECN traffic to include a mechanism that makes sure all routers along the path understand and agree to use the alternate ECN semantics for this traffic. 🔥 As an example, such a mechanism could be a field in an IP option that every router on the path decrements if it agrees to use the alternate ECN semantics with this traffic. (A similar mechanism is proposed for Quick-Start, for verifying that all of the routers along the path understand the Quick-Start IP Option [QuickStart].) With a mechanism like this, a sender could have reasonable assurance that packets specifying the use of alternate ECN semantics only traverse routers that actually understand and agree to use those semantics for those packets. 🦋
Heads up though 🚨 most existing routers are optimized for IP packets with no options, or with only some very well-known and simple IP options. So defining and using any new IP option could have a serious detrimental effect on the performance of many existing IP routers. 😬
Such a mechanism should also be robust in the presence of paths with multi-path routing, and in the presence of routing or configuration changes along the path while the connection is in use. 💜 In particular, if this option is used, connections could include some form of monitoring for changes in path behavior, and/or periodic monitoring to check that all routers along the path still understand the alternate ECN semantics. main character energy for sure 👑
4.3. Option 3: Friendly Coexistence with Competing Traffic 🦋
okay so option 3 is the one I'm most obsessed with 😭. The idea is that alternate ECN semantics get defined so that traffic using them can coexist safely on the Internet, even on a path with one or more old routers that only understand the default ECN semantics. 🌸
In this scenario, a connection sending alternate-ECN traffic would have to respond appropriately to a CE packet (a packet with the ECN codepoint "11") that arrives at the receiver, using a conformant congestion control response. 💅 Hopefully, that connection would also respond appropriately to a dropped packet, which could be a congestion indication from a router that doesn't use ECN at all. 🫶
RFC 3168 defines the default ECN semantics like this:
"Upon the receipt by an ECN-Capable transport of a single CE packet, the congestion control algorithms followed at the end-systems MUST be essentially the same as the congestion control response to a single dropped packet. For example, for ECN-Capable TCP the source TCP is REQUIRED to halve its congestion window for any window of data containing either a packet drop or an ECN indication."
The only conformant congestion control mechanisms the IETF has standardized so far are TCP [RFC2581] and protocols that use TCP-like congestion control. That includes SCTP [RFC2960], and DCCP with CCID-2 ([RFC4340], [RFC4341]). It also includes TCP-Friendly Rate Control (TFRC) [RFC3448], and protocols with TFRC-like congestion control, such as DCCP using CCID-3 [RFC4342]. 🍓 TCP uses Additive-Increase Multiplicative-Decrease congestion control, and it responds to the loss or ECN-marking of a single packet by halving its congestion window. TFRC is different. Its equation-based congestion control estimates the loss event rate over some period of time, then uses a sending rate that would be comparable, in packets per round-trip-time, to a TCP connection experiencing that same loss event rate. ✨
So what are the requirements for alternate-ECN traffic to compete fairly with other traffic on a path through an old router that doesn't understand the alternate ECN semantics? That old router might be using the default ECN semantics. 🧐 The first and second requirements below are about compatibility between traffic using alternate ECN semantics and routers using default ECN semantics.
The first requirement for compatibility with routers using default ECN is that if a packet is marked with the ECN codepoint "11" in the network, this marking is not changed on the packet's way to the receiver. The one exception is if the packet is dropped before it reaches the receiver. 🔥 This is necessary so that congestion indications from a default-ECN router actually make it to the transport receiver.
A second requirement for compatibility with routers using default ECN is that the end-nodes respond to packets marked with the ECN codepoint "11" in a way that is friendly to flows using IETF-conformant congestion control. This one is needed because the "11"-marked packets might have come from a congested router that only understands the default ECN semantics, and that router expects end-nodes to respond appropriately to CE packets. 👑 This requirement makes sure that the traffic using the alternate semantics doesn't `bully' the competing traffic it meets along the path, and that it doesn't drive up congestion on the shared link more than it should. 💀
There are also additional requirements, covering compatibility between traffic using default ECN semantics and routers using alternate ECN semantics. This situation could happen if a diffserv codepoint that uses default ECN semantics gets redefined to use alternate ECN semantics, and traffic from an "old" source travels through a "new" router. If the router "knows" that a packet comes from a sender using alternate semantics (for example, because the packet uses a certain diffserv codepoint, and every packet with that diffserv codepoint uses alternate semantics for the ECN field), then the requirements below aren't necessary, and the rules for the alternate semantics apply. 🌈
A requirement for compatibility with end-nodes using default ECN is that if a packet that could be using default semantics is marked with the ECN codepoint "00", this marking MUST NOT be changed to "01", "10", or "11" in the network. This stops the packet from being represented incorrectly to a default-ECN router downstream as ECN-Capable. 🎀 Similarly, if a packet that could be using default semantics is marked with the ECN codepoint "01", then this codepoint SHOULD NOT be changed to "10" in the network (and a "10" codepoint SHOULD NOT be changed to "01"). This requirement is necessary to avoid interfering with the transport protocol's use of the ECN nonce [RFC3540]. 🫧
Remember, the current conformant congestion control responses to a dropped or default-ECN-marked packet are TCP and TCP-like congestion control, plus TFRC (TCP-Friendly Rate Control). There's another possible response, considered in RFC 3714 but not standardized in a standards-track document. That response is to simply terminate an alternate-ECN connection for a period of time if its long-term sending rate is higher than what a TCP connection would get under the same packet dropping or marking rates [RFC3714]. 🦋 We note that using this kind of congestion control response to CE-marked packets would require specifying time constants for measuring the loss rates and for stopping transmission. It would also need some thought about packet size issues. 🧚
5. Evaluation of the Alternate ECN Semantics 🔍
This section talks about question (4) from Section 2:
(4) How well does the alternate-ECN traffic perform, and how well
does it coexist with competing traffic on the path, in a "clean"
environment with new routers and with the unambiguous
specification of the use of alternate ECN semantics?5.1. Verification of Feedback from the Router 🕵️♀️
One issue when evaluating the alternate ECN semantics is figuring out mechanisms that discourage lying from the transport receiver to the transport sender. ngl this is the drama part 😭. In lots of cases the sender is a server that really wants to use the alternate ECN semantics correctly, while the receiver has more incentive to lie about the congestion it experienced along the path.
In the default ECN semantics, two of the four ECN codepoints are used for ECN-Capable(0) and ECN-Capable(1). Using two codepoints for ECN-Capable, instead of one, lets the data sender verify the receiver's reports that packets really did arrive unmarked. 💖 Specifically, the sender can ask the receiver to report whether each unmarked packet was received as ECN-Capable(0) or ECN-Capable(1), as discussed in RFC 3540 [RFC3540]. This use of ECN-Capable(0) and ECN-Capable(1) is independent of the semantics of the other ECN codepoints. So it could also be used, if wanted, alongside alternate semantics for the other codepoints. 🌸
If the alternate semantics for the ECN codepoint don't use two separate codepoints to indicate ECN-Capable, then connections using those semantics lose the ability to verify that the data receiver is accurately reporting the received ECN codepoint to the data sender. 😬 In that case, the alternate-ECN framework might need alternate mechanisms to make sure the data receiver is reporting feedback appropriately to the sender. One possibility is that policers could be used in routers to make sure end nodes are responding appropriately to marked packets. 👑
5.2. Coexistence with Competing Traffic 🤝
A second general issue is how alternate-ECN traffic coexists with competing traffic along the path. This is considered in a clean environment where all routers understand the alternate ECN semantics and are willing to use them for the traffic that asks for them. ✨
If the traffic using the alternate ECN semantics is best-effort traffic, then it's subject to the general requirement of fair competition with TCP and other traffic along the path [RFC2914]. 💅
If the traffic using the alternate ECN semantics is diffserv traffic, then the requirements are governed by the overall guidelines for that class of diffserv traffic. It's beyond the scope of this document to specify the requirements, if any, for coexistence of diffserv traffic with other traffic on the link. That should be addressed in the specification of the diffserv codepoint itself. 🎀
5.3. Proposals for Alternate ECN with Edge-to-Edge Semantics 🌐
RFC 3168 specifies the use of the default ECN semantics by an end-to-end transport protocol, and says:
"upon the receipt by an ECN-Capable transport of a single CE packet, the congestion control algorithms followed at the end-systems MUST be essentially the same as the congestion control response to a single dropped packet" ([RFC3168], Section 5).
Some proposals for alternate ECN semantics are different. They're for ECN used in an edge-to-edge context, between gateways at the edge of a network region, for example [BESFC06]. 🧚♀️
When alternate ECN is defined with edge-to-edge semantics, that definition needs to make sure the edge-to-edge semantics don't conflict with a connection using other ECN semantics end-to-end. One way to avoid conflict would be for the edge-to-edge ECN proposal to include some mechanism that makes sure edge-to-edge ECN isn't used for connections using other ECN semantics (standard or otherwise) end-to-end. Alternatively, the edge-to-edge semantics could be defined so that they don't conflict with a connection using other ECN semantics end-to-end. 🫶
5.4. Encapsulated Packets 📦
RFC 3168 has an extensive discussion of how ECN interacts with IP tunnels, including IPsec and IP in IP. Proposals for alternate ECN semantics might interact with IP tunnels differently from default ECN. 🌀 Because of that, proposals for alternate ECN semantics MUST explicitly consider the issue of interactions with IP tunnels. Don't skip this one, bestie 🙈
5.5. A General Evaluation of the Alternate ECN Semantics 🌟
A third general issue is evaluating the general merits of the proposed alternate ECN semantics. Again, it would be beyond the scope of this document to specify requirements for the general evaluation of alternate ECN semantics. 💜
6. Security Considerations 🔐
This document doesn't propose any new mechanisms for the Internet protocol, and therefore doesn't introduce any new security considerations. Phew, no new drama here 💅
7. Conclusions 🎉
This document has discussed some of the issues to think about when specifying alternate semantics for the ECN field in the IP header. 🦋
Specifications of alternate ECN semantics MUST clearly state how they address the issues raised in this document, particularly the issues discussed in Section 2. On top of that, specifications for alternate ECN semantics MUST meet the requirements in Section 5.2 for coexistence with competing traffic. 👑✨
8. Acknowledgements ✨
Okay bestie, huge shoutout first 🫶 This doc grew out of chats with Jozef Babiarz, Kwok Ho Chan, and Victor Firoiu about their idea for using the ECN field in an alternate way in DiffServ environments. Francois Le Faucheur also deserves a crown 👑 for suggesting the doc start with a section on the potential issues that need sorting out. Thanks as well to Mark Allman, Fred Baker, David Black, Gorry Fairhurst, and everyone in the TSVWG working group who gave feedback on these issues 🌸
9. Normative References 💜
These are the must-read docs that the spec leans on, and they're not optional extras 📚
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001.10. Informative References 🦋
These are the extra reads that give you more background. Nothing here is required, but they're absolutely worth a look if you're curious 🤓
[BCF05] Babiarz, J., Chan, K., and V. Firoiu, "Congestion
Notification Process for Real-Time Traffic", Work in
Progress, July 2005.
[BESFC06] Briscoe, B., et al., "An edge-to-edge Deployment Model
for Pre-Congestion Notification: Admission Control over
a DiffServ Region", Work in Progress, June 2006.
[ECN] ECN Web Page, URL <www.icir.org/floyd/ecn.html>.
[QuickStart] S. Floyd, M. Allman, A. Jain, and P. Sarolahti, "Quick-
Start for TCP and IP", Work in Progress, October 2006.
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
2914, September 2000.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification",
RFC 3448, January 2003.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces",
RFC 3540, June 2003.
[RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding
Congestion Control for Voice Traffic in the Internet",
RFC 3714, March 2004.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March
2006.
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram
Congestion Control Protocol (DCCP) Congestion Control ID
2: TCP-like Congestion Control", RFC 4341, March 2006.
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for
Datagram Congestion Control Protocol (DCCP) Congestion
Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC
4342, March 2006.
[XSSK05] Y. Xia, L. Subramanian, I. Stoica, and S. Kalyanaraman,
One More Bit Is Enough, SIGCOMM 2005, September 2005.Author's Address 🎀
Here's where to find the author, Sally Floyd, at ICIR (ICSI Center for Internet Research) 💖
Sally Floyd
ICIR (ICSI Center for Internet Research)
Phone: +1 (510) 666-2989
EMail: floyd@icir.org
URL: http://www.icir.org/floyd/Full Copyright Statement 💅
The legal bits are kept word for word here, because they matter 📜
Copyright (C) The IETF Trust (2006).
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.
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, THE IETF TRUST,
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.Intellectual Property 🌸
Here's the IPR info, also verbatim 🫧
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.Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society, for keeping the lights on ✨
📦 where this page comes from
- ietf: rfc4774 2006-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms