Diameter Support for Proxy Mobile IPv6 Localized Routing
draft-ietf-dime-pmip6-lr-12
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7156.
|
|
---|---|---|---|
Authors | Glen Zorn , Qin Wu , Marco Liebsch , Jouni Korhonen | ||
Last updated | 2012-05-11 | ||
Replaces | draft-wu-dime-pmip6-lr | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Lionel Morand | ||
Shepherd write-up | Show Last changed 2011-12-13 | ||
IESG | IESG state | Became RFC 7156 (Proposed Standard) | |
Consensus boilerplate | Unknown | ||
Telechat date |
(None)
Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass. |
||
Responsible AD | Benoît Claise | ||
IESG note | ** No value found for 'doc.notedoc.note' ** | ||
Send notices to | dime-chairs@tools.ietf.org, draft-ietf-dime-pmip6-lr@tools.ietf.org |
draft-ietf-dime-pmip6-lr-12
Network Working Group G. Zorn Internet-Draft Network Zen Intended status: Standards Track Q. Wu Expires: November 12, 2012 Huawei M. Liebsch NEC J. Korhonen NSN May 11, 2012 Diameter Support for Proxy Mobile IPv6 Localized Routing draft-ietf-dime-pmip6-lr-12 Abstract In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the Mobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing. The term "localized routing" refers to a method by which packets are routed directly between an MN's MAG and the MAG of its Correspondent Node (CN) without involving any LMA. In order to establish a localized routing session between two Mobile Access Gateways in a Proxy Mobile IPv6 domain, the usage of localized routing may be authorized for both MAGs. This document specifies how to accomplish this using the Diameter protocol. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 12, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Zorn, et al. Expires November 12, 2012 [Page 1] Internet-Draft PMIP6 Localized Routing Support May 2012 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 4. Attribute Value Pair Definitions . . . . . . . . . . . . . . . 5 4.1. MIP6-Agent-Info AVP . . . . . . . . . . . . . . . . . . . 5 4.2. PMIP6-IPv4-Home-Address AVP . . . . . . . . . . . . . . . 5 4.3. MIP6-Home-Link-Prefix AVP . . . . . . . . . . . . . . . . 5 4.4. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . . . 5 5. Example Signaling Flows for Localized Routing Service Authorization . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Zorn, et al. Expires November 12, 2012 [Page 2] Internet-Draft PMIP6 Localized Routing Support May 2012 1. Introduction Proxy Mobile IPv6 (PMIPv6) [RFC5213] allows the Mobility Access Gateway to optimize media delivery by locally routing packets from a Mobile Node to a Correspondent Node that is locally attached to an access link connected to the same Mobile Access Gateway, avoiding tunneling them to the Mobile Node's Local Mobility Anchor. This is referred to as "local routing" in RFC 5213. However, this mechanism is not applicable to the typical scenarios in which the MN and CN are connected to different MAGs and are registered to the same LMA or different LMAs. [RFC6279] defines the problem statement for PMIPv6 localized routing. [I-D.ietf-netext-pmip-lr] describes a solution for PMIPv6 localized routing based on the scenarios defined in [RFC6279]. In these scenarios the information needed to set up a localized routing path (e.g., the addresses of the Mobile Access Gateways to which the MN and CN are respectively attached) is distributed between their respective Local Mobility Anchors. This may complicate the setup and maintenance of localized routing. Therefore, in order to establish a localized routing path between the two Mobile Access Gateways, the Mobile Node's MAG must identify the LMA that is managing the Correspondent Node's traffic and then obtain the address of the Correspondent Node's MAG from that LMA. In Proxy Mobile IPv6, the LMA to be assigned to the CN may be maintained as a configured entry in the Correspondent Node's policy profile located on an Authentication, Authorization and Accounting (AAA) server. However, there is no relevant work discussing how AAA-based mechanisms can be used to provide authorization to the Mobile Node's MAG or LMA for enabling localized routing. This document describes Diameter [I-D.ietf-dime-rfc3588bis] support for the authorization of PMIPv6 mobility entities during localized routing. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Solution Overview This document addresses how to provide authorization to the Mobile Node's MAG or LMA for enabling localized routing and resolve the destination MN's MAG by means of interaction between the LMA and the AAA server. Figure 1 shows the reference architecture for Localized Zorn, et al. Expires November 12, 2012 [Page 3] Internet-Draft PMIP6 Localized Routing Support May 2012 Routing Service Authorization. This reference architecture assumes that o MN1 and MN2 belong to the same LMA or different LMAs. If MN1 and MN2 belong to the same LMA, LMA1 and LMA2 to which MN1 and MN2 are anchored in Figure 1 should be the same LMA. If MN1 and MN2 belong to different LMAs, LMA1 and LMA2 in Figure 1 are in the same provider domain (as described in [RFC6279]). o The MAG and LMA support Diameter client functionality. +---------+ LMA2? | AAA & | +------>| Policy | | | Profile | Diameter +---------+ | | | | LMA2? +--V-+ +----+ +------->|LMA1| |LMA2| | +----+ +----+ | | | | // \\ PMIP // \\ | // \\ | | | | +----+ MAG2? +----+ +---->|MAG1|<-------- |MAG2| +----+ +----+ : : +---+ +---+ |MN1| |MN2| +---+ +---+ Figure 1: Localized Routing Service Authorization Reference Architecture The interaction of the MAG and LMA with the AAA server according to the extension specified in this document considers the following feature: a. The interaction of LMA1 with the AAA server is used to authorize the localized routing service and, if necessary, fetch the IP address of LMA2 Zorn, et al. Expires November 12, 2012 [Page 4] Internet-Draft PMIP6 Localized Routing Support May 2012 4. Attribute Value Pair Definitions This section describes Attribute Value Pairs (AVPs) defined by this specification or re-used from existing specifications in a PMIPv6- specific way. 4.1. MIP6-Agent-Info AVP The MIP6-Agent-Info grouped AVP (AVP Code 486) is defined in [RFC5447] and extended in [RFC5779]. This AVP with the M bit cleared is used to carry LMA addressing in the AA-Answer (AAA) message [I-D.ietf-dime-rfc4005bis]. 4.2. PMIP6-IPv4-Home-Address AVP The PMIP6-IPv4-Home-Address AVP (AVP Code 505) is defined in [RFC5779]. This AVP is used to carry the IPv4-MN-HoA (Mobile Node's IPv4 home address)[RFC5844] in the AA-Request (AAR) message [I-D.ietf-dime-rfc4005bis] from the LMA to the home AAA server (HAAA). 4.3. MIP6-Home-Link-Prefix AVP The MIP6-Home-Link-Prefix AVP (AVP Code 125) is defined in [RFC5779]. This AVP is used to carry the MN-HNP (Mobile Node's home network prefix) in the AAR from the LMA to the HAAA. 4.4. MIP6-Feature-Vector AVP The MIP6-Feature-Vector AVP is defined in [RFC5447]. This document allocates a new capability flag bit according to the IANA rules in RFC 5447. INTER_MAG_ROUTING_SUPPORTED (TBD) Direct routing of IP packets between MNs anchored to different MAGs without involving any LMA is supported. This bit is used with MN-HNP or IPv4-MN-HoA. When a LMA sets this bit in the MIP6- Feature-Vector and MN-HNP or IPv4-MN-HoA corresponding to the Correspondent Node is carried with this bit, it indicates to the HAAA that the Mobile Node associated with this LMA is allowed to use localized routing but the LMA or MAG needs to know from the HAAA if the Correspondent Node is allowed to use localized routing. If the MN-HNPs or IPv4-MN-HoAs corresponding to both the Mobile Node and the Correspondent Node are carried with this bit, it indicates that both the MN and CN are allowed to use localized routing. Note that localized routing related signaling is required prior to localized routing. If this bit is cleared in Zorn, et al. Expires November 12, 2012 [Page 5] Internet-Draft PMIP6 Localized Routing Support May 2012 the returned MIP6-Feature-Vector AVP, the HAAA does not authorize direct routing of packets between MNs anchored to the different MAG. The LMA MUST support this policy feature on a per-MN and per-subscription basis. 5. Example Signaling Flows for Localized Routing Service Authorization Localized Routing Service Authorization can happen during the network access authentication procedure [RFC5779], i.e., before localized routing is initialized. In this case, the preauthorized pairs of LMA/prefix sets can be downloaded to Proxy Mobile IPv6 entities during the RFC 5779 procedure. Localized routing can be initiated once the destination of a received packet matches one or more of the prefixes received during the RFC 5779 procedure. Figure 2 shows an example scenario in which MAG1 acts as a Diameter client, processing the data packet from MN1 to MN2 and requesting authorization of localized routing (i.e.,MAG-Initiated LR authorization). In this example scenario, MN1 and MN2 are attached to the same MAG and anchored to the different LMAs (i.e.,A12 described in [RFC6279]). In this case, MAG1 knows that MN2 belongs to a different LMA (which can be determined by looking up the binding cache entries corresponding to MN1 and MN2 and comparing the addresses of LMA1 and LMA2). In order to setup a localized routing path with MAG2, MAG1 must first locate the entity that maintains the data required to setup the path (i.e., the LMA corresponding to MN2 and MN1) by looking up the Binding Update List and then sending a Request message respectively to LMA1 and LMA2. The request message is the Localized Routing Initialization (LRI) message in Figure 2 and belongs to the Initial phase of the localized routing. The Diameter client in LMA1 sends an AAR message to the Diameter server. The message contains an instance of the MIP6-Feature-Vector (MFV) AVP ([RFC5447], Section 4.2.5) with the LOCAL_MAG_ROUTING_SUPPORTED bit ( [RFC5779],Section 5.5 ) set and an instance of the MIP6-Home-Link- Prefix AVP ([RFC5779], Section 5.3) or an instance of the PMIP6-IPv4- Home-Address AVP ([RFC5779], Section 5.2) containing the IP address/ HNP of MN2. The Diameter server authorizes localized routing service by checking if MN2 is allowed to use localized routing. If so, the Diameter server responds with an AAA message encapsulating an instance of the MIP6-Feature-Vector (MFV) AVP ([RFC5447], Section 4.2.5) with the the LOCAL_MAG_ROUTING_SUPPORTED bit ([RFC5779],Section 5.5) set indicating direct routing of IP packets between MNs anchored to the same MAG is supported and an instance of the MIP6-Agent-Info AVP [RFC5779] containing the IP address and/or Fully Qualified Domain Name (FQDN) of LMA corresponding to MN2 (i.e., LMA2). LMA1 then Zorn, et al. Expires November 12, 2012 [Page 6] Internet-Draft PMIP6 Localized Routing Support May 2012 knows the localized routing between MN1 and MN2 is allowed and verifies the IP address of LMA corresponding to MN2 using the data returned in the MIP6-Agent-Info AVP. In success case, LMA1 responds to MAG1 using the Localized Routing Acknowledge message (LRA in Figure 2) in accordance with [I-D.ietf-netext-pmip-lr]. Note: The signaling flow between LMA2 and AAA server is same as the signal flow between LMA1 and AAA server described in the Figure 2 and omitted in this example scenario. +---+ +---+ +----+ +----+ +---+ +----+ |MN2| |MN1| |MAG1| |LMA1| |AAA| |LMA2| +-|-+ +-+-+ +-+--+ +-+--+ +-+-+ +-+--+ | | Anchored | | | o---------------------------------------------o | | Anchored | | | | o------------------o | | | Data[MN1->MN2] | | | | |------->| LRI | | | | | |-------->| | | | | | |AAR(MFV, MN2) | | | | |--------->| | | | | |AAA(MFV, LMA) | | | | LRA |<---------| | | | |<--------| | | Figure 2: MAG-initiated Localized Routing Authorization Figure 3 shows the second example scenario, in which LMA1 acts as a Diameter client, processing the data packet from MN2 to MN1 and requesting the authorization of localized routing. In this scenario, MN1 and MN2 are attached to the different MAG and anchored to the same LMA (i.e., A21 described in [RFC6279] ), LMA knows that MN1 and MN2 belong to the same LMA (which can be determined by looking up the binding cache entries corresponding to MN1 and MN2 and comparing the addresses of LMA corresponding to MN1 and LMA corresponding to MN2). In contrast with the signaling flow shown in Figure 2, it is LMA1 instead of MAG1 which initiates the setup of the localized routing path. The Diameter client in LMA1 sends an AA-Request message to the Diameter server. The message contains an instance of the MIP6- Feature-Vector (MFV) AVP ([RFC5447], Section 4.2.5) with the INTER_MAG_ROUTING_SUPPORTED bit (Section 4.4) set indicating direct routing of IP packets between MNs anchored to different MAGs is supported and either an instance of the MIP6-Home-Link-Prefix AVP ([RFC5779], Section 5.3) or an instance of the PMIP6-IPv4-Home- Zorn, et al. Expires November 12, 2012 [Page 7] Internet-Draft PMIP6 Localized Routing Support May 2012 Address AVP ([RFC5779], Section 5.2) containing the IP address/HNP of MN2. The Diameter server authorizes the localized routing service by checking if MN2 is allowed to use localized routing. If so, the Diameter server responds with an AA-Answer message encapsulating an instance of the MIP6-Agent-Info AVP [RFC5779] containing the IP address and/or Fully Qualified Domain Name (FQDN) of LMA corresponding to MN2 (i.e.,LMA2) and an instance of the MIP6-Feature- Vector (MFV) AVP ([RFC5447], Section 4.2.5) with the INTER_MAG_ROUTING_SUPPORTED bit (Section 4.4) set indicating direct routing of IP packets between MNs anchored to different MAGs is supported. LMA1 then knows the localized routing is allowed and verifies the IP address of LMA corresponding to MN2 using the data returned in the MIP6-Agent-Info AVP. In success case, LMA1 responds to MAG1 in accordance with [I-D.ietf-netext-pmip-lr]. Note: The signaling flow between LMA1 and AAA server shown in Figure 3 also applies to A22 described in RFC6279. With returned LMA2 corresponding to MN2, LMA1 knows that MN2 belongs to a different LMA (i.e., LMA2) (i.e.,A22 described in [RFC6279]), LMA1 SHOULD initiate an exchange with LMA2 to trigger the corresponding LMA to setup binding entries on the corresponding MAG for localized routing and configure MAG1 and MAG2 to use the same encapsulation mechanism as that being used for the PMIP tunnel between the MAG and LMA without special configuration or dynamic tunneling negotiation between MAGs. This case is mentioned in RFC 6279 but not addressed by [I-D.ietf-netext-pmip-lr] and used here as an illustration of the capabilities provided by the AAA infrastructure. +---+ +----+ +----+ +---+ +----+ +---+ |MN1| |MAG1| |LMA1| |AAA| |MAG2| |MN2| +-+-+ +-+--+ +-+--+ +-+-+ +-+--+ +-+-+ | | | Anchored | | | Anchored o-------------------+--------o o--------+-------o Data[MN2->MN1] | | | | |<----- | | | | | |AAR(MFV,MN2 | | | | |--------->| | | | | |AAA(MFV,LMA | | | | LRI |<---------| | | | |<------| | | | | | LRA | | | | | |------>| | | | Figure 3: LMA-initiated Localized Routing Authorization Figure 4 shows another example scenario, in which LMA1 acts as a Diameter client, processing the data packet from MN2 to MN1 and Zorn, et al. Expires November 12, 2012 [Page 8] Internet-Draft PMIP6 Localized Routing Support May 2012 requesting the authorization of localized routing. In this scenario, MN1 and MN2 are attached to the same MAG and anchored to the same LMA (i.e., A11 described in [RFC6279]), LMA knows that MN1 and MN2 belong to the same LMA (which can be determined by looking up the binding cache entries corresponding to MN1 and MN2 and comparing the addresses of LMA corresponding to MN1 and LMA corresponding to MN2). The Diameter client in LMA1 sends an AA-Request message to the Diameter server. The message contains an instance of the MIP6- Feature-Vector AVP ([RFC5447], Section 4.2.5) with the LOCAL_MAG_ROUTING_SUPPORTED bit set and either an instance of the MIP6-Home-Link-Prefix AVP ([RFC5779], Section 5.3) or an instance of the PMIP6-IPv4-Home-Address AVP ([RFC5779], Section 5.2) containing the IP address/HNP of MN2. The Diameter server authorizes the localized routing service by checking if MN2 is allowed to use localized routing. If so, the Diameter server responds with an AA- Answer message encapsulating an instance of the MIP6-Agent-Info AVP [RFC5779] containing an instance of the MIP6-Feature-Vector (MFV) AVP ([RFC5447], Section 4.2.5) with the LOCAL_MAG_ROUTING_SUPPORTED bit ([RFC5779],Section 5.5) set indicating direct routing of IP packets between MNs anchored to the same MAG is supported and the IP address and/or Fully Qualified Domain Name (FQDN) of LMA corresponding to MN2 (i.e.,LMA2) . LMA1 then knows the localized routing is allowed and verifies the IP address of LMA corresponding to MN2 using the data returned in the MIP6-Agent-Info AVP. In success case, LMA1 responds to MAG1 for localized routing in accordance with [I-D.ietf-netext-pmip-lr]. +---+ +---+ +----+ +----+ +---+ |MN2| |MN1| |MAG1| |LMA1| |AAA| +-+-+ +-+-+ +-+--+ +-+--+ +-|-+ | | Anchored | | o----------------------------------o | | Anchored | | | o--------+-------o Data[MN2->MN1] | | | |<----- | | | | |AAR(MFV,MN2) | | | |--------->| | | | |AAA(MFV,LMA | | | LRI |<---------| | | |<------| | | | | LRA | | | | |------>| | Figure 4: LMA-initiated Localized Routing Authorization Zorn, et al. Expires November 12, 2012 [Page 9] Internet-Draft PMIP6 Localized Routing Support May 2012 6. Security Considerations The security considerations for the Diameter NASREQ [I-D.ietf-dime-rfc4005bis] and Diameter Proxy Mobile IPv6 [RFC5779] applications are also applicable to this document. The service authorization solicited by the MAG or the LMA relies upon the existing trust relationship between the MAG/LMA and the AAA server. An authorised MAG could in principle track the movement of any participating CNs at the level of the MAG to which they are anchored. If such a MAG were compromised, or under the control of a bad-actor, then such tracking could represent a privacy breach for the set of tracked CNs. In such a case, the traffic pattern from the compromised MAG might be notable so monitoring for e.g. excessive queries from MAGs might be worthwhile. 7. IANA Considerations This specification defines a new value in the Mobility Capability registry [RFC5447] for use with the MIP6-Feature-Vector AVP: INTER_MAG_ROUTING_SUPPORTED (see Section 4.4). 8. Contributors Paulo Loureiro, Jinwei Xia and Yungui Wang all contributed to early versions of this document. 9. Acknowledgements The authors would like to thank Carlos Jesus Bernardos Cano, Dan Romascanu, Elwyn Davies, Ralph Droms, Stephen Farrel, Robert Sparks and Abhay Roy for their valuable comments and suggestions on this document. 10. References 10.1. Normative References [I-D.ietf-dime-rfc3588bis] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", draft-ietf-dime-rfc3588bis-33 (work in progress), May 2012. Zorn, et al. Expires November 12, 2012 [Page 10] quot;, we cannot always assess how to fix the problem. In one implementation (not the one illustrated above), the problem manifested itself when (1) the sender received a zero window and stalled; (2) eventually an ACK arrived that offered a window larger than that in effect at the time of the stall; (3) the sender transmitted out of the buffer of data it held at the time of the stall, but (4) failed to limit this transfer to the buffer length, instead using the newly advertised (and larger) offered window. Consequently, in addition to the valid buffer contents, it sent whatever garbage values followed the end of the buffer. If it then retransmitted the corresponding sequence numbers, at that point it sent the correct data, resulting in an inconsistent retransmission. Note that this instance of the problem reflects a more general problem, that of initially transmitting incorrect data. 2.5. Name of Problem Failure to retain above-sequence data Classification Congestion control, performance Paxson, et. al. Informational [Page 13] RFC 2525 TCP Implementation Problems March 1999 Description When a TCP receives an "above sequence" segment, meaning one with a sequence number exceeding RCV.NXT but below RCV.NXT+RCV.WND, it SHOULD queue the segment for later delivery (RFC 1122, 4.2.2.20). (See RFC 793 for the definition of RCV.NXT and RCV.WND.) A TCP that fails to do so is said to exhibit "Failure to retain above- sequence data". It may sometimes be appropriate for a TCP to discard above- sequence data to reclaim memory. If they do so only rarely, then we would not consider them to exhibit this problem. Instead, the particular concern is with TCPs that always discard above-sequence data. Significance In environments prone to packet loss, detrimental to the performance of both other connections and the connection itself. Implications In times of congestion, a failure to retain above-sequence data will lead to numerous otherwise-unnecessary retransmissions, aggravating the congestion and potentially reducing performance by a large factor. Relevant RFCs RFC 1122 revises RFC 793 by upgrading the latter's MAY to a SHOULD on this issue. Trace file demonstrating it Made using tcpdump recording at the receiving TCP. No losses reported by the packet filter. B is the TCP sender, A the receiver. A exhibits failure to retain above sequence-data: 10:38:10.164860 B > A: . 221078:221614(536) ack 1 win 33232 [tos 0x8] 10:38:10.170809 B > A: . 221614:222150(536) ack 1 win 33232 [tos 0x8] 10:38:10.177183 B > A: . 222150:222686(536) ack 1 win 33232 [tos 0x8] 10:38:10.225039 A > B: . ack 222686 win 25800 Here B has sent up to (relative) sequence 222686 in-sequence, and A accordingly acknowledges. 10:38:10.268131 B > A: . 223222:223758(536) ack 1 win 33232 [tos 0x8] 10:38:10.337995 B > A: . 223758:224294(536) ack 1 win 33232 [tos 0x8] 10:38:10.344065 B > A: . 224294:224830(536) ack 1 win 33232 [tos 0x8] 10:38:10.350169 B > A: . 224830:225366(536) ack 1 win 33232 [tos 0x8] 10:38:10.356362 B > A: . 225366:225902(536) ack 1 win 33232 [tos 0x8] Paxson, et. al. Informational [Page 14] RFC 2525 TCP Implementation Problems March 1999 10:38:10.362445 B > A: . 225902:226438(536) ack 1 win 33232 [tos 0x8] 10:38:10.368579 B > A: . 226438:226974(536) ack 1 win 33232 [tos 0x8] 10:38:10.374732 B > A: . 226974:227510(536) ack 1 win 33232 [tos 0x8] 10:38:10.380825 B > A: . 227510:228046(536) ack 1 win 33232 [tos 0x8] 10:38:10.387027 B > A: . 228046:228582(536) ack 1 win 33232 [tos 0x8] 10:38:10.393053 B > A: . 228582:229118(536) ack 1 win 33232 [tos 0x8] 10:38:10.399193 B > A: . 229118:229654(536) ack 1 win 33232 [tos 0x8] 10:38:10.405356 B > A: . 229654:230190(536) ack 1 win 33232 [tos 0x8] A now receives 13 additional packets from B. These are above- sequence because 222686:223222 was dropped. The packets do however fit within the offered window of 25800. A does not generate any duplicate ACKs for them. The trace contributor (V. Paxson) verified that these 13 packets had valid IP and TCP checksums. 10:38:11.917728 B > A: . 222686:223222(536) ack 1 win 33232 [tos 0x8] 10:38:11.930925 A > B: . ack 223222 win 32232 B times out for 222686:223222 and retransmits it. Upon receiving it, A only acknowledges 223222. Had it retained the valid above- sequence packets, it would instead have ack'd 230190. 10:38:12.048438 B > A: . 223222:223758(536) ack 1 win 33232 [tos 0x8] 10:38:12.054397 B > A: . 223758:224294(536) ack 1 win 33232 [tos 0x8] 10:38:12.068029 A > B: . ack 224294 win 31696 B retransmits two more packets, and A only acknowledges them. This pattern continues as B retransmits the entire set of previously-received packets. A second trace confirmed that the problem is repeatable. Trace file demonstrating correct behavior Made using tcpdump recording at the receiving TCP (C). No losses reported by the packet filter. 09:11:25.790417 D > C: . 33793:34305(512) ack 1 win 61440 09:11:25.791393 D > C: . 34305:34817(512) ack 1 win 61440 09:11:25.792369 D > C: . 34817:35329(512) ack 1 win 61440 09:11:25.792369 D > C: . 35329:35841(512) ack 1 win 61440 09:11:25.793345 D > C: . 36353:36865(512) ack 1 win 61440 09:11:25.794321 C > D: . ack 35841 win 59904 A sequence hole occurs because 35841:36353 has been dropped. Paxson, et. al. Informational [Page 15] RFC 2525 TCP Implementation Problems March 1999 09:11:25.794321 D > C: . 36865:37377(512) ack 1 win 61440 09:11:25.794321 C > D: . ack 35841 win 59904 09:11:25.795297 D > C: . 37377:37889(512) ack 1 win 61440 09:11:25.795297 C > D: . ack 35841 win 59904 09:11:25.796273 C > D: . ack 35841 win 61440 09:11:25.798225 D > C: . 37889:38401(512) ack 1 win 61440 09:11:25.799201 C > D: . ack 35841 win 61440 09:11:25.807009 D > C: . 38401:38913(512) ack 1 win 61440 09:11:25.807009 C > D: . ack 35841 win 61440 (many additional lines omitted) 09:11:25.884113 D > C: . 52737:53249(512) ack 1 win 61440 09:11:25.884113 C > D: . ack 35841 win 61440 Each additional, above-sequence packet C receives from D elicits a duplicate ACK for 35841. 09:11:25.887041 D > C: . 35841:36353(512) ack 1 win 61440 09:11:25.887041 C > D: . ack 53249 win 44032 D retransmits 35841:36353 and C acknowledges receipt of data all the way up to 53249. References This problem is documented in [Paxson97]. How to detect Packet loss is common enough in the Internet that generally it is not difficult to find an Internet path that will result in some above-sequence packets arriving. A TCP that exhibits "Failure to retain ..." may not generate duplicate ACKs for these packets. However, some TCPs that do retain above-sequence data also do not generate duplicate ACKs, so failure to do so does not definitively identify the problem. Instead, the key observation is whether upon retransmission of the dropped packet, data that was previously above-sequence is acknowledged. Two considerations in detecting this problem using a packet trace are that it is easiest to do so with a trace made at the TCP receiver, in order to unambiguously determine which packets arrived successfully, and that such packets may still be correctly discarded if they arrive with checksum errors. The latter can be tested by capturing the entire packet contents and performing the IP and TCP checksum algorithms to verify their integrity; or by confirming that the packets arrive with the same checksum and contents as that with which they were sent, with a presumption that the sending TCP correctly calculates checksums for the packets it transmits. Paxson, et. al. Informational [Page 16] RFC 2525 TCP Implementation Problems March 1999 It is considerably easier to verify that an implementation does NOT exhibit this problem. This can be done by recording a trace at the data sender, and observing that sometimes after a retransmission the receiver acknowledges a higher sequence number than just that which was retransmitted. How to fix If the root problem is that the implementation lacks buffer, then then unfortunately this requires significant work to fix. However, doing so is important, for reasons outlined above. 2.6. Name of Problem Extra additive constant in congestion avoidance Classification Congestion control / performance Description RFC 1122 section 4.2.2.15 states that TCP MUST implement Jacobson's "congestion avoidance" algorithm [Jacobson88], which calls for increasing the congestion window, cwnd, by: MSS * MSS / cwnd for each ACK received for new data [RFC2001]. This has the effect of increasing cwnd by approximately one segment in each round trip time. Some TCP implementations add an additional fraction of a segment (typically MSS/8) to cwnd for each ACK received for new data [Stevens94, Wright95]: (MSS * MSS / cwnd) + MSS/8 These implementations exhibit "Extra additive constant in congestion avoidance". Significance May be detrimental to performance even in completely uncongested environments (see Implications). In congested environments, may also be detrimental to the performance of other connections. Paxson, et. al. Informational [Page 17] RFC 2525 TCP Implementation Problems March 1999 Implications The extra additive term allows a TCP to more aggressively open its congestion window (quadratic rather than linear increase). For congested networks, this can increase the loss rate experienced by all connections sharing a bottleneck with the aggressive TCP. However, even for completely uncongested networks, the extra additive term can lead to diminished performance, as follows. In congestion avoidance, a TCP sender probes the network path to determine its available capacity, which often equates to the number of buffers available at a bottleneck link. With linear congestion avoidance, the TCP only probes for sufficient capacity (buffer) to hold one extra packet per RTT. Thus, when it exceeds the available capacity, generally only one packet will be lost (since on the previous RTT it already found that the path could sustain a window with one less packet in flight). If the congestion window is sufficiently large, then the TCP will recover from this single loss using fast retransmission and avoid an expensive (in terms of performance) retransmission timeout. However, when the additional additive term is used, then cwnd can increase by more than one packet per RTT, in which case the TCP probes more aggressively. If in the previous RTT it had reached the available capacity of the path, then the excess due to the extra increase will again be lost, but now this will result in multiple losses from the flight instead of a single loss. TCPs that do not utilize SACK [RFC2018] generally will not recover from multiple losses without incurring a retransmission timeout [Fall96,Hoe96], significantly diminishing performance. Relevant RFCs RFC 1122 requires use of the "congestion avoidance" algorithm. RFC 2001 outlines the fast retransmit/fast recovery algorithms. RFC 2018 discusses the SACK option. Trace file demonstrating it Recorded using tcpdump running on the same FDDI LAN as host A. Host A is the sender and host B is the receiver. The connection establishment specified an MSS of 4,312 bytes and a window scale factor of 4. We omit the establishment and the first 2.5 MB of data transfer, as the problem is best demonstrated when the window has grown to a large value. At the beginning of the trace excerpt, the congestion window is 31 packets. The connection is never receiver-window limited, so we omit window advertisements from the trace for clarity. Paxson, et. al. Informational [Page 18] RFC 2525 TCP Implementation Problems March 1999 11:42:07.697951 B > A: . ack 2383006 11:42:07.699388 A > B: . 2508054:2512366(4312) 11:42:07.699962 A > B: . 2512366:2516678(4312) 11:42:07.700012 B > A: . ack 2391630 11:42:07.701081 A > B: . 2516678:2520990(4312) 11:42:07.701656 A > B: . 2520990:2525302(4312) 11:42:07.701739 B > A: . ack 2400254 11:42:07.702685 A > B: . 2525302:2529614(4312) 11:42:07.703257 A > B: . 2529614:2533926(4312) 11:42:07.703295 B > A: . ack 2408878 11:42:07.704414 A > B: . 2533926:2538238(4312) 11:42:07.704989 A > B: . 2538238:2542550(4312) 11:42:07.705040 B > A: . ack 2417502 11:42:07.705935 A > B: . 2542550:2546862(4312) 11:42:07.706506 A > B: . 2546862:2551174(4312) 11:42:07.706544 B > A: . ack 2426126 11:42:07.707480 A > B: . 2551174:2555486(4312) 11:42:07.708051 A > B: . 2555486:2559798(4312) 11:42:07.708088 B > A: . ack 2434750 11:42:07.709030 A > B: . 2559798:2564110(4312) 11:42:07.709604 A > B: . 2564110:2568422(4312) 11:42:07.710175 A > B: . 2568422:2572734(4312) * 11:42:07.710215 B > A: . ack 2443374 11:42:07.710799 A > B: . 2572734:2577046(4312) 11:42:07.711368 A > B: . 2577046:2581358(4312) 11:42:07.711405 B > A: . ack 2451998 11:42:07.712323 A > B: . 2581358:2585670(4312) 11:42:07.712898 A > B: . 2585670:2589982(4312) 11:42:07.712938 B > A: . ack 2460622 11:42:07.713926 A > B: . 2589982:2594294(4312) 11:42:07.714501 A > B: . 2594294:2598606(4312) 11:42:07.714547 B > A: . ack 2469246 11:42:07.715747 A > B: . 2598606:2602918(4312) 11:42:07.716287 A > B: . 2602918:2607230(4312) 11:42:07.716328 B > A: . ack 2477870 11:42:07.717146 A > B: . 2607230:2611542(4312) 11:42:07.717717 A > B: . 2611542:2615854(4312) 11:42:07.717762 B > A: . ack 2486494 11:42:07.718754 A > B: . 2615854:2620166(4312) 11:42:07.719331 A > B: . 2620166:2624478(4312) 11:42:07.719906 A > B: . 2624478:2628790(4312) ** 11:42:07.719958 B > A: . ack 2495118 11:42:07.720500 A > B: . 2628790:2633102(4312) 11:42:07.721080 A > B: . 2633102:2637414(4312) 11:42:07.721739 B > A: . ack 2503742 11:42:07.722348 A > B: . 2637414:2641726(4312) Paxson, et. al. Informational [Page 19] RFC 2525 TCP Implementation Problems March 1999 11:42:07.722918 A > B: . 2641726:2646038(4312) 11:42:07.769248 B > A: . ack 2512366 The receiver's acknowledgment policy is one ACK per two packets received. Thus, for each ACK arriving at host A, two new packets are sent, except when cwnd increases due to congestion avoidance, in which case three new packets are sent. With an ack-every-two-packets policy, cwnd should only increase one MSS per 2 RTT. However, at the point marked "*" the window increases after 7 ACKs have arrived, and then again at "**" after 6 more ACKs. While we do not have space to show the effect, this trace suffered from repeated timeout retransmissions due to multiple packet losses during a single RTT. Trace file demonstrating correct behavior Made using the same host and tracing setup as above, except now A's TCP has been modified to remove the MSS/8 additive constant. Tcpdump reported 77 packet drops; the excerpt below is fully self-consistent so it is unlikely that any of these occurred during the excerpt. We again begin when cwnd is 31 packets (this occurs significantly later in the trace, because the congestion avoidance is now less aggressive with opening the window). 14:22:21.236757 B > A: . ack 5194679 14:22:21.238192 A > B: . 5319727:5324039(4312) 14:22:21.238770 A > B: . 5324039:5328351(4312) 14:22:21.238821 B > A: . ack 5203303 14:22:21.240158 A > B: . 5328351:5332663(4312) 14:22:21.240738 A > B: . 5332663:5336975(4312) 14:22:21.270422 B > A: . ack 5211927 14:22:21.271883 A > B: . 5336975:5341287(4312) 14:22:21.272458 A > B: . 5341287:5345599(4312) 14:22:21.279099 B > A: . ack 5220551 14:22:21.280539 A > B: . 5345599:5349911(4312) 14:22:21.281118 A > B: . 5349911:5354223(4312) 14:22:21.281183 B > A: . ack 5229175 14:22:21.282348 A > B: . 5354223:5358535(4312) 14:22:21.283029 A > B: . 5358535:5362847(4312) 14:22:21.283089 B > A: . ack 5237799 14:22:21.284213 A > B: . 5362847:5367159(4312) 14:22:21.284779 A > B: . 5367159:5371471(4312) 14:22:21.285976 B > A: . ack 5246423 14:22:21.287465 A > B: . 5371471:5375783(4312) Paxson, et. al. Informational [Page 20] RFC 2525 TCP Implementation Problems March 1999 14:22:21.288036 A > B: . 5375783:5380095(4312) 14:22:21.288073 B > A: . ack 5255047 14:22:21.289155 A > B: . 5380095:5384407(4312) 14:22:21.289725 A > B: . 5384407:5388719(4312) 14:22:21.289762 B > A: . ack 5263671 14:22:21.291090 A > B: . 5388719:5393031(4312) 14:22:21.291662 A > B: . 5393031:5397343(4312) 14:22:21.291701 B > A: . ack 5272295 14:22:21.292870 A > B: . 5397343:5401655(4312) 14:22:21.293441 A > B: . 5401655:5405967(4312) 14:22:21.293481 B > A: . ack 5280919 14:22:21.294476 A > B: . 5405967:5410279(4312) 14:22:21.295053 A > B: . 5410279:5414591(4312) 14:22:21.295106 B > A: . ack 5289543 14:22:21.296306 A > B: . 5414591:5418903(4312) 14:22:21.296878 A > B: . 5418903:5423215(4312) 14:22:21.296917 B > A: . ack 5298167 14:22:21.297716 A > B: . 5423215:5427527(4312) 14:22:21.298285 A > B: . 5427527:5431839(4312) 14:22:21.298324 B > A: . ack 5306791 14:22:21.299413 A > B: . 5431839:5436151(4312) 14:22:21.299986 A > B: . 5436151:5440463(4312) 14:22:21.303696 B > A: . ack 5315415 14:22:21.305177 A > B: . 5440463:5444775(4312) 14:22:21.305755 A > B: . 5444775:5449087(4312) 14:22:21.308032 B > A: . ack 5324039 14:22:21.309525 A > B: . 5449087:5453399(4312) 14:22:21.310101 A > B: . 5453399:5457711(4312) 14:22:21.310144 B > A: . ack 5332663 *** 14:22:21.311615 A > B: . 5457711:5462023(4312) 14:22:21.312198 A > B: . 5462023:5466335(4312) 14:22:21.341876 B > A: . ack 5341287 14:22:21.343451 A > B: . 5466335:5470647(4312) 14:22:21.343985 A > B: . 5470647:5474959(4312) 14:22:21.350304 B > A: . ack 5349911 14:22:21.351852 A > B: . 5474959:5479271(4312) 14:22:21.352430 A > B: . 5479271:5483583(4312) 14:22:21.352484 B > A: . ack 5358535 14:22:21.353574 A > B: . 5483583:5487895(4312) 14:22:21.354149 A > B: . 5487895:5492207(4312) 14:22:21.354205 B > A: . ack 5367159 14:22:21.355467 A > B: . 5492207:5496519(4312) 14:22:21.356039 A > B: . 5496519:5500831(4312) 14:22:21.357361 B > A: . ack 5375783 14:22:21.358855 A > B: . 5500831:5505143(4312) 14:22:21.359424 A > B: . 5505143:5509455(4312) 14:22:21.359465 B > A: . ack 5384407 Paxson, et. al. Informational [Page 21] RFC 2525 TCP Implementation Problems March 1999 14:22:21.360605 A > B: . 5509455:5513767(4312) 14:22:21.361181 A > B: . 5513767:5518079(4312) 14:22:21.361225 B > A: . ack 5393031 14:22:21.362485 A > B: . 5518079:5522391(4312) 14:22:21.363057 A > B: . 5522391:5526703(4312) 14:22:21.363096 B > A: . ack 5401655 14:22:21.364236 A > B: . 5526703:5531015(4312) 14:22:21.364810 A > B: . 5531015:5535327(4312) 14:22:21.364867 B > A: . ack 5410279 14:22:21.365819 A > B: . 5535327:5539639(4312) 14:22:21.366386 A > B: . 5539639:5543951(4312) 14:22:21.366427 B > A: . ack 5418903 14:22:21.367586 A > B: . 5543951:5548263(4312) 14:22:21.368158 A > B: . 5548263:5552575(4312) 14:22:21.368199 B > A: . ack 5427527 14:22:21.369189 A > B: . 5552575:5556887(4312) 14:22:21.369758 A > B: . 5556887:5561199(4312) 14:22:21.369803 B > A: . ack 5436151 14:22:21.370814 A > B: . 5561199:5565511(4312) 14:22:21.371398 A > B: . 5565511:5569823(4312) 14:22:21.375159 B > A: . ack 5444775 14:22:21.376658 A > B: . 5569823:5574135(4312) 14:22:21.377235 A > B: . 5574135:5578447(4312) 14:22:21.379303 B > A: . ack 5453399 14:22:21.380802 A > B: . 5578447:5582759(4312) 14:22:21.381377 A > B: . 5582759:5587071(4312) 14:22:21.381947 A > B: . 5587071:5591383(4312) **** "***" marks the end of the first round trip. Note that cwnd did not increase (as evidenced by each ACK eliciting two new data packets). Only at "****", which comes near the end of the second round trip, does cwnd increase by one packet. This trace did not suffer any timeout retransmissions. It transferred the same amount of data as the first trace in about half as much time. This difference is repeatable between hosts A and B. References [Stevens94] and [Wright95] discuss this problem. The problem of Reno TCP failing to recover from multiple losses except via a retransmission timeout is discussed in [Fall96,Hoe96]. Paxson, et. al. Informational [Page 22] RFC 2525 TCP Implementation Problems March 1999 How to detect If source code is available, that is generally the easiest way to detect this problem. Search for each modification to the cwnd variable; (at least) one of these will be for congestion avoidance, and inspection of the related code should immediately identify the problem if present. The problem can also be detected by closely examining packet traces taken near the sender. During congestion avoidance, cwnd will increase by an additional segment upon the receipt of (typically) eight acknowledgements without a loss. This increase is in addition to the one segment increase per round trip time (or two round trip times if the receiver is using delayed ACKs). Furthermore, graphs of the sequence number vs. time, taken from packet traces, are normally linear during congestion avoidance. When viewing packet traces of transfers from senders exhibiting this problem, the graphs appear quadratic instead of linear. Finally, the traces will show that, with sufficiently large windows, nearly every loss event results in a timeout. How to fix This problem may be corrected by removing the "+ MSS/8" term from the congestion avoidance code that increases cwnd each time an ACK of new data is received. 2.7. Name of Problem Initial RTO too low Classification Performance Description When a TCP first begins transmitting data, it lacks the RTT measurements necessary to have computed an adaptive retransmission timeout (RTO). RFC 1122, 4.2.3.1, states that a TCP SHOULD initialize RTO to 3 seconds. A TCP that uses a lower value exhibits "Initial RTO too low". Significance In environments with large RTTs (where "large" means any value larger than the initial RTO), TCPs will experience very poor performance. Paxson, et. al. Informational [Page 23] RFC 2525 TCP Implementation Problems March 1999 Implications Whenever RTO < RTT, very poor performance can result as packets are unnecessarily retransmitted (because RTO will expire before an ACK for the packet can arrive) and the connection enters slow start and congestion avoidance. Generally, the algorithms for computing RTO avoid this problem by adding a positive term to the estimated RTT. However, when a connection first begins it must use some estimate for RTO, and if it picks a value less than RTT, the above problems will arise. Furthermore, when the initial RTO < RTT, it can take a long time for the TCP to correct the problem by adapting the RTT estimate, because the use of Karn's algorithm (mandated by RFC 1122, 4.2.3.1) will discard many of the candidate RTT measurements made after the first timeout, since they will be measurements of retransmitted segments. Relevant RFCs RFC 1122 states that TCPs SHOULD initialize RTO to 3 seconds and MUST implement Karn's algorithm. Trace file demonstrating it The following trace file was taken using tcpdump at host A, the data sender. The advertised window and SYN options have been omitted for clarity. 07:52:39.870301 A > B: S 2786333696:2786333696(0) 07:52:40.548170 B > A: S 130240000:130240000(0) ack 2786333697 07:52:40.561287 A > B: P 1:513(512) ack 1 07:52:40.753466 A > B: . 1:513(512) ack 1 07:52:41.133687 A > B: . 1:513(512) ack 1 07:52:41.458529 B > A: . ack 513 07:52:41.458686 A > B: . 513:1025(512) ack 1 07:52:41.458797 A > B: P 1025:1537(512) ack 1 07:52:41.541633 B > A: . ack 513 07:52:41.703732 A > B: . 513:1025(512) ack 1 07:52:42.044875 B > A: . ack 513 07:52:42.173728 A > B: . 513:1025(512) ack 1 07:52:42.330861 B > A: . ack 1537 07:52:42.331129 A > B: . 1537:2049(512) ack 1 07:52:42.331262 A > B: P 2049:2561(512) ack 1 07:52:42.623673 A > B: . 1537:2049(512) ack 1 07:52:42.683203 B > A: . ack 1537 07:52:43.044029 B > A: . ack 1537 07:52:43.193812 A > B: . 1537:2049(512) ack 1 Paxson, et. al. Informational [Page 24] RFC 2525 TCP Implementation Problems March 1999 Note from the SYN/SYN-ACK exchange, the RTT is over 600 msec. However, from the elapsed time between the third and fourth lines (the first packet being sent and then retransmitted), it is apparent the RTO was initialized to under 200 msec. The next line shows that this value has doubled to 400 msec (correct exponential backoff of RTO), but that still does not suffice to avoid an unnecessary retransmission. Finally, an ACK from B arrives for the first segment. Later two more duplicate ACKs for 513 arrive, indicating that both the original and the two retransmissions arrived at B. (Indeed, a concurrent trace at B showed that no packets were lost during the entire connection). This ACK opens the congestion window to two packets, which are sent back-to-back, but at 07:52:41.703732 RTO again expires after a little over 200 msec, leading to an unnecessary retransmission, and the pattern repeats. By the end of the trace excerpt above, 1536 bytes have been successfully transmitted from A to B, over an interval of more than 2 seconds, reflecting terrible performance. Trace file demonstrating correct behavior The following trace file was taken using tcpdump at host C, the data sender. The advertised window and SYN options have been omitted for clarity. 17:30:32.090299 C > D: S 2031744000:2031744000(0) 17:30:32.900325 D > C: S 262737964:262737964(0) ack 2031744001 17:30:32.900326 C > D: . ack 1 17:30:32.910326 C > D: . 1:513(512) ack 1 17:30:34.150355 D > C: . ack 513 17:30:34.150356 C > D: . 513:1025(512) ack 1 17:30:34.150357 C > D: . 1025:1537(512) ack 1 17:30:35.170384 D > C: . ack 1025 17:30:35.170385 C > D: . 1537:2049(512) ack 1 17:30:35.170386 C > D: . 2049:2561(512) ack 1 17:30:35.320385 D > C: . ack 1537 17:30:35.320386 C > D: . 2561:3073(512) ack 1 17:30:35.320387 C > D: . 3073:3585(512) ack 1 17:30:35.730384 D > C: . ack 2049 The initial SYN/SYN-ACK exchange shows that RTT is more than 800 msec, and for some subsequent packets it rises above 1 second, but C's retransmit timer does not ever expire. References This problem is documented in [Paxson97]. Paxson, et. al. Informational [Page 25] RFC 2525 TCP Implementation Problems March 1999 How to detect This problem is readily detected by inspecting a packet trace of the startup of a TCP connection made over a long-delay path. It can be diagnosed from either a sender-side or receiver-side trace. Long-delay paths can often be found by locating remote sites on other continents. How to fix As this problem arises from a faulty initialization, one hopes fixing it requires a one-line change to the TCP source code. 2.8. Name of Problem Failure of window deflation after loss recovery Classification Congestion control / performance Description The fast recovery algorithm allows TCP senders to continue to transmit new segments during loss recovery. First, fast retransmission is initiated after a TCP sender receives three duplicate ACKs. At this point, a retransmission is sent and cwnd is halved. The fast recovery algorithm then allows additional segments to be sent when sufficient additional duplicate ACKs arrive. Some implementations of fast recovery compute when to send additional segments by artificially incrementing cwnd, first by three segments to account for the three duplicate ACKs that triggered fast retransmission, and subsequently by 1 MSS for each new duplicate ACK that arrives. When cwnd allows, the sender transmits new data segments. When an ACK arrives that covers new data, cwnd is to be reduced by the amount by which it was artificially increased. However, some TCP implementations fail to "deflateInternet-Draft PMIP6 Localized Routing Support May 2012 [I-D.ietf-dime-rfc4005bis] Zorn, G., "Diameter Network Access Server Application", draft-ietf-dime-rfc4005bis-08 (work in progress), April 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and K. Chowdhury, "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction", RFC 5447, February 2009. [RFC5779] Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A., and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server", RFC 5779, February 2010. [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010. 10.2. Informative References [I-D.ietf-netext-pmip-lr] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A. Dutta, "Localized Routing for Proxy Mobile IPv6", draft-ietf-netext-pmip-lr-08 (work in progress), January 2012. [RFC6279] Liebsch, M., Jeong, S., and Q. Wu, "Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement", RFC 6279, June 2011. Authors' Addresses Glen Zorn Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand Phone: +66 (0) 87-040-4617 Email: glenzorn@gmail.com Zorn, et al. Expires November 12, 2012 [Page 11] Internet-Draft PMIP6 Localized Routing Support May 2012 Qin Wu Huawei Technologies Co., Ltd. 101 Software Avenue, Yuhua District Nanjing, Jiangsu 21001 China Phone: +86-25-84565892 Email: sunseawq@huawei.com Marco Liebsch NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg, 69115 Germany Email: liebsch@nw.neclab.eu Jouni Korhonen Nokia Siemens Networks Linnoitustie 6 Espoo FI-02600, Finland Email: jouni.nospam@gmail.com Zorn, et al. Expires November 12, 2012 [Page 12]