One document matched: draft-dawkins-trigtran-probstmt-01.txt
Differences from draft-dawkins-trigtran-probstmt-00.txt
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
| PAFTECH AB 2003-2026 | 2026-04-22 15:17:20 |