Triggers for Transport BOF (trigtran) Wednesday, November 20 at 1300-1500 =================================== CHAIRS: Carl Williams Spencer Dawkins AGENDA: - Agenda Bashing - Overview of Problem Statement (Spencer and Carl) - Perspectives Within the transport community Sally Floyd Within the application community TBD Within the operations/routing community TBD - Discussion of Goals if TRIGTRAN BOF is chartered as WG Architectural understanding of TRIGTRAN Identification of canonical TRIGTRAN events for arbitrary subnetworking technologies (abstract API...) Specification of TRIGTRAN protocol - Discussion of Non-Goals if TRIGTRAN BOF is chartered Low-latency subnetwork triggers (still an ongoing topic) - Brief identification of relationship with other groups TSV working groups Non-TSV working groups Open Mobility Alliance/OMA? Others? - Where might this path lead? Futures (layer2) James Kempf - Identification of Land Mines and Rat Holes Tossing of Rotten Tomatoes and thick standards documents - Threat models and security considerations - Open microphone - Decision points and summary (see details below) - Assess interest in doing this work in IETF Mailing list General Discussion: trigtran@ietf.org To Subscribe: trigtran-request@ietf.org In Body: subscribe Archive: www.ietf.org/mail-archive/working-groups/trigtran/current/maillist.html Purpose of Triggers for Transport (TRIGTRAN) BOF 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". When transport protocols are deployed over paths including one or more a wireless subnets, a wireless access device now may have significant information about that part of the path. End-to-end mechanisms continue to work (see PILC and related specifications), but must rely on communication over a subnetwork link that experiences outages and degradation. The TRIGTRAN BOF is investigating whether special knowledge from wireless access devices can be useful to endpoint transports. 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 subnetwork link, and (b) it can still communicate with one endpoint when a problematic subnetwork 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. The Triggers for Transport (TRIGTRAN) BOF is being held to understand - 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 BOF is related to, but distinct from, similar discussions on triggers in MOBILEIP and in IRTF's Routing Research Group on micro-mobility. The primary difference is this departs from the low latency and tight coupling of those. It is possible that work products from a TRIGTRAN working group would be reused with fast handoff signaling. We'll explore this *briefly* in the BOF meeting. TRIGTRAN will start with a scope limited to wireless subnetworks, but it is also possible that non-wireless subnetworks (for instance, SLOW) may also have events that fit into the TRIGTRAN framework. ------------------------- Additional Information Envisioning a TRIGTRAN Protocol: - What TRIGTRAN events would be applicable to most/all subnetworking technologies? (up/down? rtt change? handoff coming? handoff done? outage done? what resolution of measurement?) - What would transports do with transport triggers in what parts of their algorithms? Might they also give triggers to applications? - What might appropriate mechanisms be to carry TRIGTRAN notifications to interested endpoints? - What latency is required for TRIGTRAN events, in order for them to be useful? Strawman Draft: Problem Statement for "Triggers for Transport" draft-dawkins-trigtran-probstmt-00.txt (to be submitted