Internet Draft Document:draft-dawkins-trigtran-probstmt-01.txt Spencer Dawkins Expires: August 2003 Cyneta Networks Carl E. Williams MCSR Labs Alper E. Yegin DoCoMo USA Labs Problem Statement for Triggers for Transport(TRIGTRAN) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsolete by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Conventions used in this document 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 [ ]. Abstract When transport protocols are deployed over a path including a wireless sub-network, a wireless access device now has significantly better knowledge of the wireless portion of the connection path characteristics than one or both endpoints. End-to-end mechanisms continue to work (see [PILC] and related specifications), but must rely on communication over a sub- network link that experiences outages and degradation. This document will set the problem scope for investigation of whether this special knowledge from wireless access devices can be useful to endpoint transports. While the initial focus is on wireless links, other links will also be taken into account. Dawkins et. al Informational - Expires August 2003 Page 1 TRIGTRAN Problem Statement March 2003 List of Abbreviations TRIGTRAN Triggers for Transport AR Access Router FMIPv6 Fast Mobile IPv6 PILC Performance Implications of Link Characteristics 1. Introduction IETF transport protocol development has been based on the assumption that two communicating endpoints "know" more about characteristics of the paths between these endpoints than any single device within the network. This is implicit knowledge, based on transport algorithm adaptations to events in the paths. Because IP datagram forwarding can follow a variety of paths between two endpoints, a device within the network in contrast has information about one part of the path, but not what the transports endpoints "know". The scope of this work will focus on a framework for providing information to the transport via triggers of connection path characteristics. In particular, it is possible that a wireless access device might provide information about the path in a useful way because (a) the wireless access device has detailed knowledge of a sub- network link, and (b) it can still communicate with one endpoint when a problematic sub-network link stops working, or starts working, or... The goal here is that changes in path characteristics, especially outages, RTT ... can be explicitly signaled without end-to-end blind retransmissions based on peer transport retry timers. If this goal is accepted, it may be broadened to include changes in nominal subnetwork transmission rates or other subnetwork events, if these subnetwork events are generic in nature and accepted by the IETF community as a whole. Dawkins et. al Informational - Expires August 2003 Page 2 TRIGTRAN Problem Statement March 2003 To further this goal this document will provide a basis of understanding for the following: - The nature of generic "transport triggers" - Possible uses of "transport triggers" - Mechanisms for signaling transport triggers to accessible transport endpoints - The architectural impact of this addition to the transport layer Although the need for this change is more obvious in a wireless environment, we're also soliciting input from the rest of the Internet community in these areas: - Whether there are "transport triggers" applicable to all (other?) subnetwork types, beyond link up/link down - Whether the use of "transport triggers" is worth the effort of modifying existing transport protocols to make use of this information This investigation is similar to, but distinct from, similar discussions on triggers in MOBILEIP and in IRTF's Routing Research Group on micro-mobility. The primary difference is the low latency and tight coupling required for fast handoff. It is anticipated that the resulting model for defining transport triggers will provide a framework for future trigger discussion that are required for IP handoff protocols. Although TRIGTRAN is initially focusing on wireless sub-network links, other sub-networks may also have events of interest to transports. For example, if a TCP connection over a destination-stripping resilient packet ring "changes direction" due to a link failure, its packets are now competing with a different traffic mix, because traffic is independently scheduled in each direction. TCP's knowledge of path bandwidth characteristics is based on invalidated experience. TRIGTRAN could be used to notify TCP that this has happened. Ideally, the TRIGTRAN framework developed to provide notifications about wireless events to transports could be used for other purposes. For this reason, readers from non- wireless and non-transport communities of interest are requested to "keep us honest" - if the TRIGTRAN community heads in a direction that's right for wireless but wrong for your community of interest, please say so! Dawkins et. al Informational - Expires August 2003 Page 3 TRIGTRAN Problem Statement March 2003 2. Straw-person Architecture Transports will use TRIGTRAN mechanisms to monitor sub-network links that aren't local to a host. In the simplest case, the components are: +------+ +-----------------+ (Internet goes +------+ | Host | | TRIGTRAN Router | here) | Host | +------+ +-----------------+ +------+ X X Sub-network Event --------------> Notifies Transport Here Here Figure 1: Minimal TRIGTRAN Architecture This scenario would map to a mobile host using a wireless sub- network to connect to the Internet via an access router. The critical feature here is that the host receiving a TRIGTRAN trigger is across an arbitrary network topology from the TRIGTRAN edge router sending the trigger. The host receiving the trigger then takes some transport-level action (sending a packet, retransmitting a packet, waiting for some period of time to transmit a packet, etc). The transports would figure out "most events" eventually, given enough time (i.e., round trip times). For instance, TCP is good at figuring at bandwidth changes, but not as good at detecting a remote link transitioning to the "up" state after a retransmission timeout. Eventually, a backed-off RTO timer will fire, and the now-accessible receiver will acknowledge the next (successful) retransmission, but the sender and receiver will be waiting when they could be communicating. TRIGTRAN can give the host receiving triggers hints that it might reattempt transmission, without waiting a complete RTO interval. TRIGTRAN is intended to provide network-based hints that clue the transport in more quickly (where "quickly" is measured in RTTs, not in milliseconds). TRIGTRAN events need not be reliably delivered. TRIGTRAN events are ADVISORY - end-to-end mechanisms will continue to funciton whether TRIGTRAN events are delivered or not. This problem statement will only focus on TRIGTRAN routers located at a network edge. The reason TRIGTRAN is focusing Dawkins et. al Informational - Expires August 2003 Page 4 TRIGTRAN Problem Statement March 2003 specifically on the case of problematic access links, because so many problematic links fall into this category (although not all problematic links are access links), and because this is the simplest useful case. More complex topologies are outside the scope of TRIGTRAN, at least for now. Although TRIGTRAN is initially focusing on TCP connections over wireless sub-network links, we note that SCTP transports often have multiple wireline paths between two SCTP hosts for reliability. We don't want to do anything in TRIGTRAN that would prevent the use of TRIGTRAN as a notification mechanism for SCTP switchover - so please keep us honest! 3. What events cause notifications? Routing protocols have propagated "link up"/"link down" events for decades. This is the minimal set of TRIGTRAN events. Additional events may include - Nominal sub-network bandwidth change - Sub-network path changes - Other generic events identified by the TRIGTRAN working group An event may not be applicable to every type of subnetwork, but it must not be technology-specific. If an event is applicable to most/all mobile environments, but not applicable to non- mobile environments, it is sufficiently generic for TRIGTRAN. 4. Who receives notifications? In order to deliver notifications, TRIGTRAN routers and hosts must be able to discover each other. There are at least two different models for determining who receives notifications: - All endpoint pairs communicating via a TRIGTRAN router - Transport entities that explicitly request to be notified The first model requires a TRIGTRAN router to discover the hosts communicating via this router, so that the notifications can be sent to all of them. The second model requires hosts to discover the TRIGTRAN router and explicitly request notifications. Dawkins et. al Informational - Expires August 2003 Page 5 TRIGTRAN Problem Statement March 2003 While the choice of model is still an open issue, the decision has considerable impact on TRIGTRAN's scalability and ease of deployment in the general Internet. If entities must explicitly request notification, the TRIGTRAN working group must identify a protocol mechanism for registration. The list of possible mechanisms includes: - An RSVP-style I-care This-happened pair of flows - A registration application on TRIGTRAN routers 5. Protocol mechanisms for events This is an open question. The set of possible answers includes: - An ICMP message - A unicast message to applications that request triggers - A multicast message to listening applications There are several questions that need to be answered before a protocol mechanism can be chosen. These questions include: - The sending rate of trigger notifications assumed - Current Internet architecture issues (firewalls, NAT, ALG) - Current Internet deployment issues (ICMP black holes, multi-domain multicast) - The availability of DCCP as transport 6. What do transport entities do when they receive notifications? This is an open question. In previous practice, transports have often ignored network-level event notifications. For example, [RFC 1122] encourages transports to treat ICMP DESTINATION UNREACHABLE messages with codes of 0 (Net), 1 (Host), or 5 (Bad Source Route) as hints, not as proof that a host is unreachable, because these outages may be transitory as IP datagram networks propagate routing updates. TRIGTRAN is likely to increase the impact notifications will have on transports. Possible responses include: - Reducing TCP's congestion window - Deferring packets until additional event notifications arrive - Notifying applications that an event has occurred Dawkins et. al Informational - Expires August 2003 Page 6 TRIGTRAN Problem Statement March 2003 7. How quickly are notifications propagated? TRIGTRAN notifications are delivered to endpoint transport implementations. This has two implications: - The network topology between two arbitrary endpoints is also arbitrary. Although TRIGTRAN events are conceptually similar to Mobile IP's Fast Handoff, the timescale for notification propagation will be much greater - theoretically approaching the maximum latency between two endpoints in the Internet. - The intention is that transport implementations base sending rate decisions on TRIGTRAN events, so TRIGTRAN itself may limit the notification rate in order to prevent control-loop oscillation. For these reasons, endpoints should not assume minimal propagation delays for TRIGTRAN events. 8. Security Considerations TRIGTRAN notifications can affect ongoing communications on the recipient hosts. Therefore, they can be leveraged by malicious nodes in launching attacks on victims. For example, an attacker can spoof a TRIGTRAN vent to convince a victim that it can no longer use the network. This is an effective denial- of service attack, which can only be prevented if the notification messages are authenticated. Another possible attack can be launched on the TRIGTRAN router by spoofing very high numbers of registration requests on behalf of non-existent hosts. Such an attack would exhaust limited resources on the router, and therefore lead to another form of denial of service attack. Due to such possible exploitations, TRIGTRAN protocol will have to include authentication for messages that can potentially create or alter state on protocol entities. The TRIGTRAN framework document [TRIGFRAME] provides a preliminary security assessment. Such a write-up identifies what are some of the key obstacles for TRIGTRAN notification from a security perspective. Dawkins et. al Informational - Expires August 2003 Page 7 TRIGTRAN Problem Statement March 2003 9. Closing Statements While the draft is initially focusing on wireless links, other link types (i.e. modems) are of importance and will be taken into account. We wish to acknowledge the work done in the IP mobility community and that a number of concepts formalized during the fast-handover work were adopted here. We're particularly building on [BAR-BOF]. 10. References [BAR-BOF] Notes from L2 Triggers ad-hoc meeting at IETF 53 (PILC mailing list posting), Aaron Falk and Carl E. Williams, August 2002, available from http://pilc.grc.nasa.gov/list/archive/1837.html. The following drafts describe lower-latency triggers intended for Mobile IP fast handoff. TRIGTRAN reuses a number of concepts from this work. [CORSON] A Triggered Interface (work in progress), Scott Corson, May 2002, draft-corson-triggered-00.txt [WILLIAMS] Problem Statement for Link-layer Triggers work (work in progress), Carl Williams, Alper E. Yegin, and James Kempf, June 2002, draft-williams-l2-probstmt-00.txt [YEGIN] Link-layer Triggers Protocol (work in progress), Alper Yegin, June 2002, draft-yegin-l2-triggers-00.txt [GURI] Layer-2 API for Paging (expired work in progress), Sridhar Gurivireddy, Behcet Sarikaya, Vinod Choyi, and Xiafeng Xu, March 2001, draft-guri-seamoby-paging-triggers-00.txt [MANYFOLKS] Supporting Optimized Handover for IP Mobility Requirements for Underlying Systems (work in progress), Alper Yegin (editor), June 2002, draft-manyfolks-l2-mobilereq-02.txt [PILC] Performance Implications of Link Characteristics IETF Working Group http://www.ietf.org/html.charters/pilc-charter.html Dawkins et. al Informational - Expires August 2003 Page 8 TRIGTRAN Problem Statement March 2003 [TRIGFRAME] Framework and Requirements for TRIGTRAN, draft-dawkins-trigtran-framework-00.txt, Sencer Dawkins, Carl E. Williams, and Alper E. Yegin, February 2003. 12. Contact Information Spencer Dawkins Cyneta Networks 1201 North Bowser Road Phone: 1-469-385-2484 Suite 100 Richardson, Texas 75081 USA Email: sdawkins@cynetanetworks.com Carl E. Williams MCSR Labs 3790 El Camino Real Palo Alto, CA 94306 Phone: 1-650-380-0925 USA Email: carlw@mcsr-labs.org Alper E. Yegin DoCoMo USA Labs 181 Metro Drive, Suite 300 Phone: +1 408 451 4743 San Jose, CA 95110 Fax: +1 408 451 1090 USA Email: alper@docomolabs-usa.com Dawkins et. al Informational - Expires August 2003 Page 9