Internet Draft Document:draft-dawkins-trigtran-probstmt-00.txt Spencer Dawkins Expires: April 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 framework 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 April 2003 Page 1 TRIGTRAN Problem Statement October 2002 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. 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" Dawkins et. al Informational - Expires April 2003 Page 2 TRIGTRAN Problem Statement October 2002 - 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 April 2003 Page 3 TRIGTRAN Problem Statement October 2002 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: +------+ +-----------------+ +------+ | Host | | TRIGTRAN Router | | Host | +------+ +-----------------+ +------+ 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. There is no requirement that all routers will provide TRIGTRAN mechanisms. The following is a perfectly serviceable scenario: +------+ +-----------------+ +---------------+ +-----+ | Host | | TRIGTRAN Router | | Other Routers | |Host | +------+ +-----------------+ +---------------+ +-----+ X Sub-network Event --------------------> Notifies Transport Here Here Figure 2: TRIGTRAN Supported By Some, But Not All, Routers Note that this non-requirement means TRIGTRAN events need not be reliably delivered (if the connection path includes routers that don't generate TRIGTRAN events at all, what would be the point of reliably delivering partial information?). TRIGTRAN events are ADVISORY - end-to-end mechanisms will continue to funciton whether TRIGTRAN events are delivered or not. There's no requirement that TRIGTRAN routers be located at a network edge, although routing diversity within a network may make sub-network notifications less useful (how should a transport react if one sub-network link experiences an event, but additional paths that are unaffected by the event exist between two endpoints?). Dawkins et. al Informational - Expires April 2003 Page 4 TRIGTRAN Problem Statement October 2002 TRIGTRAN mechanisms may be useable in this scenario: +------+ +----------+ +----------+ +------+ | Host | | TRIGTRAN | | TRIGTRAN | | Host | | | | Router | | Router | | | +------+ +----------+ +----------+ +------+ X Notifies <-------- Link Event ------------------> Notifies Transport here Transport Here Here Figure 3: TRIGTRAN Notifications For Network Interconnection Links This scenario would map to two independent networks connected via microwave or satellite links. Some "Level Two Triggers" work [for example, YEGIN] has provided for notifications covering links between wireless access points, or bridges, that do not operate at the IP layer. TRIGTRAN would operate between IP-capable devices. If a TRIGTRAN router becomes aware of events through communication with a non-IP-capable device, the TRIGTRAN router may propagate these events as well, but the mechanism used by TRIGTRAN routers to communicate with non-IP-capable devices is not part of the TRIGTRAN problem space. 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. Depending on the location of these entities with respect to each other (e.g., on-link vs. Dawkins et. al Informational - Expires April 2003 Page 5 TRIGTRAN Problem Statement October 2002 multiple hops away), various discovery methods can be used. 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. 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 Dawkins et. al Informational - Expires April 2003 Page 6 TRIGTRAN Problem Statement October 2002 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 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. Dawkins et. al Informational - Expires April 2003 Page 7 TRIGTRAN Problem Statement October 2002 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, April 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, October 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 April 2003 Page 8 TRIGTRAN Problem Statement October 2002 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 April 2003 Page 9