Internet Engineering Task Force P. Sarolahti
INTERNET-DRAFT Nokia Research Center
Intended status: Informational S. Floyd
Expires: September 2007 ICIR
M. Kojo
University of Helsinki
5 March 2007
Transport-layer Considerations for Explicit Cross-layer Indications
draft-sarolahti-tsvwg-crosslayer-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 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."
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.
This Internet-Draft will expire on September 2007.
Abstract
Several types of explicit cross-layer communication schemes have
been proposed to enhance the transport protocol performance.
However, various challenges with such schemes have been identified,
Sarolahti/Floyd/Kojo [Page 1]
INTERNET-DRAFT Expires: September 2007 March 2007
for example concerning the interactions with the middleboxes and
tunnels in the network. This document discusses different types of
explicit cross-layer notification mechanisms that have been proposed
to enhance end-to-end transport performance. We analyze the
different mechanisms using a taxonomy based on what kind of network
interactions they require, and discuss the benefits and
disadvantages different approaches have. The objective is to get a
common understanding of the possibilities and challenges with these
mechanisms, with pointers to past discussions on this topic, and to
describe the possible next steps towards removing barriers from
explicit cross-layer communication in future protocols.
Sarolahti/Floyd/Kojo [Page 2]
INTERNET-DRAFT Expires: September 2007 March 2007
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions and Terminology. . . . . . . . . . . . . . . 5
2. Definitions and Scope . . . . . . . . . . . . . . . . . . . . 5
2.1. Definitions. . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Roles of different protocol layers . . . . . . . . . . . 6
2.3. Scope. . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Possible Benefits of Explicit Signaling . . . . . . . . . . . 7
4. Classification of Explicit Notification Mecha-
nisms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. In-band and out-of-band notifications. . . . . . . . . . 9
4.2. Involvement of routers on the path . . . . . . . . . . . 9
4.3. On-path and off-path mechanisms. . . . . . . . . . . . . 10
4.4. Top-down, bottom-up and mixed
notifications . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Current, Proposed, and Past Explicit Cross-layer
Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Determining the packet size. . . . . . . . . . . . . . . 11
5.2. Congestion and rate control. . . . . . . . . . . . . . . 12
5.3. Quality of Service . . . . . . . . . . . . . . . . . . . 14
6. Past IETF Activities. . . . . . . . . . . . . . . . . . . . . 15
7. Challenges with Explicit Cross-layer Mechanisms . . . . . . . 17
7.1. Security Issues. . . . . . . . . . . . . . . . . . . . . 17
7.2. IP Tunnels . . . . . . . . . . . . . . . . . . . . . . . 18
7.3. Non-conformant routers and middleboxes . . . . . . . . . 20
7.4. Processing efficiency. . . . . . . . . . . . . . . . . . 21
8. Proposals for Future Actions. . . . . . . . . . . . . . . . . 21
A. List of Changes . . . . . . . . . . . . . . . . . . . . . . . 22
Normative References . . . . . . . . . . . . . . . . . . . . . . 23
Informative References . . . . . . . . . . . . . . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27
AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 27
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction
Recent research argues that the traditional interface between the
transport layer and the network layer may not be sufficient for the
present day needs [EE06]. For example, the traditional TCP
congestion control algorithms are slow to converge to sudden path
changes where the throughput and round-trip times may change by
orders of magnitude. Therefore, it has been proposed that in
addition to the "implicit" observations about the path
characteristics, such as measured round-trip times and the available
bandwidth probed by usual congestion control mechanisms, enhancing
the transport protocols by "explicit" information would be useful.
Sarolahti/Floyd/Kojo Section 1. [Page 3]
INTERNET-DRAFT Expires: September 2007 March 2007
In the past there have been different proposals on enhancing
transport protocol (usually TCP) performance by means of providing
explicit information and notifications from different protocol
layers above or below transport. The cross-layer notifications can
be local notifications from the lower or upper protocol layers of
the host device, or it can be explicit communication between the
transport peers and the network between them. The mechanisms for
cross-layer signaling inside a host implementation are largely
dependent on the operating system architecture, and therefore not of
interest for the IETF. However, explicit signaling between the
network and the end-hosts involves several considerations on the
network behavior that we try to capture in this document.
Cross-layer signaling could be used, for example, for delivering
hints to a transport sender about the characteristics of the network
path, to allow the sender to adjust its sending rate more
efficiently than what would be possible using the traditional TCP
probing mechanisms. While designing the possible uses of such
signaling, a careful consideration needs to be made of what can be
done within the limits of the congestion control principles
[RFC2914, RFC2581], without endangering the network stability and
fairness towards other flows. Often this determines whether end-
hosts can negotiate directly without network support, or whether
some or all of the routers along the network path need to support
the signaling mechanism.
One of the guiding architectural principles of the Internet has been
that the network should be stateless, with the transmission state
and intelligence residing at the end hosts [Cla88]. Although today
this principle has been ignored more than once by the different
types of Network Address Translators (NATs) and stateful firewalls,
it is an important consideration when evaluating the cross-layer
notification methods. While many of the notification mechanisms
discussed in this document conform to this principle, some
mechanisms do require some additional state in the network. Adding
new bits of state in the network is not necessarily a bad thing, but
the design should be such that loss of the state would not cause
serious fate-sharing problems that might prevent the network's
packet forwarding function from working.
While the benefits of applying cross-layer notifications to improve
the transport protocol performance has been evaluated in number of
studies [SAF06, SEE+06, KSE+04], several problems have also been
identified with regard to conformance to congestion control
principles, interactions with middleboxes in the network, or
interoperation with IP tunnels and lower layer bridges. An
important design principle would also be to maintain the layer-
abstraction that isolates the transport layer from any particular
Sarolahti/Floyd/Kojo Section 1. [Page 4]
INTERNET-DRAFT Expires: September 2007 March 2007
link technology, which is forgotten in some proposals on enhancing
the transport performance by cross-layer interactions. This
document casts an overview on different types of explicit cross-
layer notifications, and discusses their possibilities and
challenges.
The objective of the final document is to build a common
understanding of the issues related to explicit communication
between the transport layer and the network. This is intended to
help the various proposals to enhance protocol performance using
cross-layer information. Such enhancements have been discussed both
in the TSV and INT areas. Because many IETF participants are
focused on following only a selection of areas, it is possible that
work conducted in one IETF area does not get a thorough review from
participants focusing in other areas (before the IESG review).
Because the cross-layer enhancements potentially touch different
IETF areas and may be progressed in different IETF working groups,
it could be helpful to have transport layer guidelines that would
hopefully be useful in the design process of possible new cross-
layer notification schemes. An additional goal for this document is
to propose possible next steps towards solving the identified
challenges related to explicit cross-layer communication.
1.1. Conventions and 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 [RFC2119].
2. Definitions and Scope
This section defines some terms and concepts used in the rest of
this document.
2.1. Definitions
router: Network node that forwards the IP packet to the next link
towards its destination based on the information in the IP header.
A router may modify the contents of the IP header, for example by
decrementing the IPv4 TTL or IPv6 hop count fields.
middlebox: A network device along the transport path that performs
operations that are beyond the normal IP packet forwarding done by
the routers. Often this involves investigating the transport
protocol header of the packet. Firewalls and Network Address
Sarolahti/Floyd/Kojo Section 2.1. [Page 5]
INTERNET-DRAFT Expires: September 2007 March 2007
Translators (NATs) are the most common types of middlebox.
bridge: A network node that forwards the data frames based on layer
2 information. A bridge does not process the IP header.
on-path: A message that has the same sender and receiver as the
normal protrocol traffic, and that follows exactly the same sequence
of routers as the normal traffic, is called an on-path message.
off-path: A message that has a different sender or receiver, or that
is forwarded via a different sequence of routers than the normal
protocol traffic, is called an off-path message.
in-band: A message carried in the same IP packet with the normal
protocol traffic is called an in-band message. Implicitly, an in-
band message is also an on-path message.
out-of-band: A message that is not carried in a same packet with the
normal protocol traffic, but as a separate packet, is called out-of-
band message.
notification: Although notification is a rather generic term, in
this document notification is a message that carries explicit cross-
layer information.
2.2. Roles of different protocol layers
It is difficult to find a course book on computer networking that
would not begin with a description of the different protocol layers,
usually according to the ISO reference model. For example, [Hal96,
Figure 1.11] summarizes the different protocol layers as follows:
* Physical layer (1): Mechanical and electrical network interface
definitions.
* Link layer (2): Data link control (framing, data transparency,
error control).
* Network layer (3): Network routing, addressing, call set-up, and
clearing.
* Transport layer (4): End-to-end message transfer (connection
management, error control, fragmentation, flow control).
* Session layer (5): Dialog and synchronization control for
application entities.
Sarolahti/Floyd/Kojo Section 2.2. [Page 6]
INTERNET-DRAFT Expires: September 2007 March 2007
* Presentation layer (6): Transfer syntax negotiation, data
representation transformations.
* Application layer (7): File transfer, access and management,
document and message interchange, job transfer and manipulation.
Although ISO reference model layering is not explicitly visible in
many of the IETF protocols, and some protocols might do tasks of
more than one layer, it is possible to find places of different
IETF protocols in this model. Usually the proposed cross-layer
enhancements concern interactions between the link layer, network
layer, and transport layer.
2.3. Scope
This document discusses the cross-layer mechanisms that take place
between the end-hosts and the network. Local triggers inside a
protocol stack are out of the scope of the IETF, and this document
does not discuss such schemes in detail. We focus on cross-layer
notifications that are used by the transport layer to enhance the
end-to-end communication. Therefore, for example the cross-layer
information used for routing or packet forwarding inside specific
network clouds is out-of-scope. We give somewhat less attention to
off-path notification mechanisms, to make the discussion more
focused. Also, we focus on unicast traffic and do not discuss
multi-cast communication.
3. Possible Benefits of Explicit Signaling
The past proposals to add new explicit signaling mechanisms have
been motivated in the following ways.
* Mobility: One of the key design principles of the IP mobility
protocols has been to isolate the mobility from the upper protocol
layers. While this makes sense architecturally, it has been
observed that hiding the mobility event from upper layer protocols
can lead to suboptimal performance. A significant amount of
research has been conducted to investigate and optimize the
performance of the upper layers after a mobile hand-off occurs
(e.g., [SKDK06, SEE+06, DK06]). It has been observed that with
better awareness of mobility, benefits on transport protocol
performance can be achieved.
There is ongoing work in the IEEE 802.21 group to develop Media
Independent Handover services [IEEE21]. As part of this effort,
Sarolahti/Floyd/Kojo Section 3. [Page 7]
INTERNET-DRAFT Expires: September 2007 March 2007
the IEEE specifies link-layer triggers to optimize the hand-off
performance of a mobile host. The IETF is also doing the related
work in the MIPSHOP working group, and in the MOBOPTS IRTF group
[TGM+06]. While this work is targeted to optimize mobility, the
information from the specified link-layer triggers could also be
useful to transport protocols.
* High delay-bandwidth networks: TCP slow-start is known to be
inefficient when used over a very high-speed network path, or over
a network path with large propagation delay. The TCP startup
performance could be improved with explicit information about the
current available capacity of the connection path [SAF06, KHR02].
* Non-congestion losses: a traditional research topic on TCP
performance has been detection and response to packet reordering
and to packet losses that are not caused by congestion. Possible
performance benefits for being able to detect non-congestion
losses have been evaluated in a number of documents [KSE+04].
* Quality of Service: In addition to DiffServ and RSVP QoS
signaling, there have been other proposals for smaller
enhancements regarding real-time transmission of packets. For
example, Packet Lifetime Discard [GL03] assigns a lifetime for IP
packets to allow routers to drop packets that have exceeded their
lifetime, thereby saving network resources. An earlier work
proposed adjusting the link-layer reliability mode in GSM networks
based on the transport protocol in use [LR99], to allow more
timely handling of UDP packets.
4. Classification of Explicit Notification Mechanisms
We classify the explicit notification mechanisms based on their
different characteristics. First, the notifications can be
transmitted in-band in the same packets with data, or out-of-band as
separate packets from the data. Second, the notifications may need
participation from some or all routers along the connection path, or
they can be processed at the end-hosts only. Third, notifications
may be transfered on the data path or off-path, following a
different network route than the data traffic. Finally,
notifications can be top-down (originating from the transport layer
to lower layers), bottom-up (originating from lower layers and
carrying information to the transport layer), and part of an
extended conversation with a mixture of the two.
Sarolahti/Floyd/Kojo Section 4. [Page 8]
INTERNET-DRAFT Expires: September 2007 March 2007
4.1. In-band and out-of-band notifications
In-band signaling goes with the normal protocol traffic, that is,
with a protocol control message or data. The benefit is that in-band
messages are known to share the same path as the normal protocol
traffic, and generally use less header overhead than a separate
message. In addition, with in-band messages the sender is often able
to learn about a loss event via the transport protocol's normal
acknowledgment mechanisms. The disadvantage of in-band signaling is
that if some routers or middleboxes drop a packet because of unknown
protocol information (for example, a notification transfered in an
IP option), the accompanying data also gets lost, causing a
performance penalty for the data transfer. In-band notifications can
also cause additional header and processing overhead for the data
packets, especially if routers need to process additional
notification information in the packets.
Out-of-band mechanisms require a dedicated protocol for signaling.
While the out-of-band mechanisms save the normal protocol traffic
from additional overhead, the transmission of separate messages may
be prevented by middleboxes on the connection path. If the message
is lost in the network for some reason, there may not be any way for
either end of the connection path to know about it. If the out-of-
band notification needs to be matched with a particular flow, the
notification message would need to include the IP source and
destination address, transport protocol, and source and destination
transport protocol ports. Getting and using this information may not
be possible in all cases, for example when the transport protocol
header is encrypted by IPsec ESP [RFC2401]. If the notification
needs to be in synchrony with the data flow, a separate out-of-band
message may be problematic, because the message may be lost or
delayed relative to the data traffic.
4.2. Involvement of routers on the path
The possible notification mechanisms can differ in how much they
need assistance from the routers on the connection path. Some
notification mechanisms can be useful even if they are supported by
only a few of the routers on the path, whereas other notification
mechanisms require that every router on the path supports the
notification scheme. To help further discussion, we assign short
names for each category.
* "NoRouters": Mechanisms that do not require support from routers
on the connection path are easiest to deploy. For example, such
an in-band notification scheme could use a TCP option to carry the
required information. Because this class of mechanisms can use the
Sarolahti/Floyd/Kojo Section 4.2. [Page 9]
INTERNET-DRAFT Expires: September 2007 March 2007
normal unmodified IP header, there usually should not be
additional problems with legacy routers, tunnels, or middleboxes
processing these notifications. An additional benefit is that
IPsec can be used to protect the notification content.
* "SomeRouters": If some of the routers are intended to process the
notification, it needs to be placed in the packet so that the
routers are able to see it. For example, the notification needs to
be an IP option (or IPv6 hop-by-hop option), or there needs to a
Router Alert option [RFC2113, RFC2711] that signals the router to
process the packet more thoroughly. There may be some deployment
problems with this class of mechanisms. For example, some
misbehaving routers or middleboxes in the network are known to
drop IP packets based in the ECN bits in the TCP header. It is
also known that many routers or middleboxes drop packets
containing unknown IP options [MAF04].
* "AllRouters": In some cases all routers on the connection path
need to process a notification. This is a hard requirement,
because the deployment of such mechanisms can take time. The above
mentioned deployment problems with misbehaving routers and
middleboxes applies also to this class of mechanisms. Requiring
all routers to process a notification is challenging also because
the packet forwarding logic in routers is often highly optimized
and the fast path algorithms can not be expected to conduct very
complicated additional processing on the IP packets. Verifying
that all routers have indeed processed the notification can
sometimes be difficult. A common verification mechanism is to use
a separate TTL counter that is adjusted at the same time with IP
TTL or hop count fields. However, different types of IP tunnels
can hide the notification data inside the outer IP header. In
this case, if the tunnel encrypts the data inside the outer
header, there is no way for routers to operate on the notification
data. In some cases the TTL-based verification mechanisms may not
be able to detect such tunnel. It is also possible that the TTL
fields are manipulated by a malicious node on the connection path
that has enough information to make educated guesses about the
expected TTL values.
4.3. On-path and off-path mechanisms
As mentioned in the beginning, we focus on on-path mechanisms, but
there is an important and common application of off-path signaling
that deserves to be mentioned. Most ICMP messages [RFC792, RFC2463]
are off-path notifications, because they are often sent by an
intermediate router on the connection path in the reverse direction,
towards the sender of the packet that triggered the ICMP condition;
Sarolahti/Floyd/Kojo Section 4.3. [Page 10]
INTERNET-DRAFT Expires: September 2007 March 2007
an example is the ICMP "host unreachable" error. Some ICMP messages
are triggered by the connection receiver, such as the "Protocol
unreachable" error. We consider such ICMP notification also as an
off-path notification, because it traverses the reverse direction,
and in case of asymmetric routing the ICMP message can traverse a
different set of routers than the original message.
One of the problems with off-path mechanisms is that it may be
difficult to authenticate an off-path notification that originates
from the network. In many ICMP messages the beginning of the IP
payload, i.e., the transport protocol header, is copied to the ICMP
message. This information can be used to identify the flow that has
triggered the ICMP message. There is a work-in-progress Internet-
Draft on analyzing the security of ICMP messages [G06].
4.4. Top-down, bottom-up and mixed notifications
Some cross-layer notifications involve extended conversations
between the transport layer and lower layers. For example, the ECN
field in the IP header is used to carry ECN-capable information from
the transport protocol to routers, and to carry Congestion
Experienced information from routers back to the transport protocol.
However, other proposed cross-layer notifications are more clearly
unidirectional, carrying information only from the transport layer
to lower layers, or vice versa. As an example of a proposed top-
down notification, a transport protocol such as UDP-Lite would
communicate to lower layers about the desired checksum coverage for
a packet [RFC3828]. An example of a proposed bottom-up notification
would be a link-layer trigger designed to optimize the hand-off
performance of a mobile host. Unidirectional top-down or bottom-up
notifications are best designed to serve only as hints, to be used
by the recipient only as is deemed appropriate.
5. Current, Proposed, and Past Explicit Cross-layer Mechanisms
In this section we discuss some of the explicit cross-layer
signaling mechanisms that have been proposed in the past.
5.1. Determining the packet size
TCP uses an option to negotiate the Maximum Segment Size (MSS)
during the TCP connection establishment, where each TCP end point
may send a TCP MSS option to the other end point indicating the MSS
it is able to receive. In general, the MSS information is local link
Sarolahti/Floyd/Kojo Section 5.1. [Page 11]
INTERNET-DRAFT Expires: September 2007 March 2007
information, the link MTU size, learned via the IP layer and
translated to the transport layer MSS. This mechanism would be
classified as an in-band "NoRouters" notification.
In order to determine the maximum segment size allowed on the whole
connection path between the sender and receiver, Path MTU discovery
needs to be applied. The traditional Path MTU discovery is not
strictly an explicit on-path mechanism, because it is based on the
use of an ICMP "packet too big" error message that a router sends
when an incoming packet is too large to be sent on the router's next
hop. However, an in-band IP option has been proposed as an
alternative Path MTU mechanism [Wel03]. All routers would be
required to process the IP option, so this would be a rather
challenging scheme to deploy.
5.2. Congestion and rate control
Because TCP congestion control adjustments are a popular application
for explicit notifications, some general guidelines on using the
above categories are required:
* A sender MAY reduce the sending rate in response to a "NoRouters"
or "SomeRouters" notification.
* In order to increase the sending rate more than would be allowed
by the normal congestion control principles, a sender MUST use an
"AllRouters" notification to verify that the rate increase does
not cause congestion in the network.
We call a mechanism that does not conform to these principles an
"invalid mechanism". It can be debated whether "AllRouters"
mechanisms are truly valid because of problems the "AllRouters"
mechanisms have with IP tunnels, that may cause false positives with
the "AllRouters" mechanisms. We discuss this issue more thoroughly
in Section 7.2.
Some proposals use information about the change of last-hop link
characteristics, for example in adjusting the congestion control
state [DK06, SEE+06]. This can be an attractive application for
mobile terminals that are able to detect mobility, and the change of
the wireless last-hop link, and make appropriate changes in the
congestion control state under the assumption that in many cases the
wireless last-hop link is the bottleneck on the connection path. In
some cases the indication of the last-hop link change can be
sufficient information for reducing the transmission rate, or
restarting the TCP slow-start to evaluate the capacity of new path.
However, following the principle given above, such a link indication
Sarolahti/Floyd/Kojo Section 5.2. [Page 12]
INTERNET-DRAFT Expires: September 2007 March 2007
MUST NOT be used alone to rapidly increase the data transmission
rate. The only way to increase the transmission rate is through the
normal congestion control mechanisms, or by using an "AllRouters"
notification mechanism.
The above principle should also apply to non-congestion-controlled
protocols, for example transmission of audio/video streams over RTP
and UDP. For example, using an explicit notification about changing
from a low-bandwidth first-hop link to a high-bandwidth first-hop
link as a trigger to suddenly increase the transmission rate is
against the congestion control fairness principles [RFC2914] and
therefore would be an invalid mechanism.
A notification has been suggested to allow faster adaptation to
changes in the end-to-end path properties. TCP's response to
connectivity change indications such as mobility have been discussed
in an Internet-Draft [SEE+06]. The draft describes a "connectivity-
change indication" TCP option, and the response to a connectivity-
change event, when detected either from the TCP option, or from the
local stack. The TCP option could be used by a mobile host to
indicate to the other end that it has moved and path characteristics
may have changed. Depending on the current state of a connection, a
host receiving a connectivity-change indication may decide to re-
evaluate congestion control parameters of a path and/or make a quick
retransmission to resume data transmission earlier after a temporary
connectivity disruption instead of waiting for the retransmission
timer to expire again. This is an in-band "NoRouters" notification.
Explicit Congestion Notification (ECN) [RFC3168] uses a two-bit ECN
field in the IP header to allow routers to indicate congestion in
the network before they have to start dropping packets due to buffer
overflow. ECN can be useful even if only a subset of routers
implement it on the connection path. There were initial deployment
problems with ECN because some routers in the network dropped
packets with a non-zero ECN field in the TCP header, but we believe
that today most of these routers have been fixed. ECN is an in-band
"SomeRouters" mechanism.
The use of the ECN field is taken further in an alternative protocol
to use the field, called Re-ECN [BJSK06]. The protocol aims "to
provide sufficient information in each IP datagram to be able to
hold senders and whole networks accountable for the congestion they
cause downstream, before they cause it."
In Quick-Start [RFC4782], the sender uses an IP option to request
permission from routers to send at a higher rate than the normal
congestion control would allow. [RFC4782] specifies the use of
Quick-Start for TCP and discusses the challenges such a mechanism
Sarolahti/Floyd/Kojo Section 5.2. [Page 13]
INTERNET-DRAFT Expires: September 2007 March 2007
needs to address. Quick-Start router algorithms and their
configuration are analyzed further in [SAF06], and [SKDK06] gives an
initial analysis of Quick-Start in wireless environments with
vertical hand-offs between different wireless link technologies.
Quick-Start is an in-band "AllRouters" mechanism.
Variable-structure congestion Control Protocol (VCP) is another
proposed congestion control proposal using explicit feedback from
routers. VCP leverages the ECN field to let routers indicate their
load information [XSSK05]. Based on the VCP bits, a TCP sender could
apply either Multiplicative Increase, Additive Increase, or
Multiplicative Decrease of the congestion window. VCP is an in-band
mechanism, and it is intended to be a "AllRouters" mechanism, but it
does not provide a mechanism for checking that all routers have
understood and processed the notification. It is possible than VCP
allows Multiplicative Increase even if there are fairly loaded
routers on the connection path that do not support the mechanism.
Therefore VCP is an invalid mechanism to be deployed in the
Internet.
Explicit Control Protocol (XCP) [KHR02, FPK06] is a proposal for a
full-fledged congestion control protocol involving the interaction
of routers and the end-hosts. Although XCP can be considered to be
more than just a cross-layer signaling mechanism, it also needs to
consider the above-mentioned challenges. XCP uses a separate
congestion header between IP and the transport protocols, i.e., it
is an in-band protocol. XCP is an "AllRouters" scheme, but it is not
currently specified how it is checked that all routers have
processed the congestion control header.
Different forms of in-band signaling have also been proposed for
dealing with corruption-based packet loss in wireless and satellite
networks [KSE+04]. The paper on Explicit Transport Error
Notification (ETEN) gives a taxonomy of different notification
types, depending on the granularity of the notification, the
direction of notification, the location of notification, and so on.
The efficiency of cumulative error notification is investigated by
simulation experiments. However, no specific packet format is
proposed in the paper.
5.3. Quality of Service
The Resource ReSerVation Protocol (RSVP) uses separate out-of-band
messages on top of IPv4 or IPv6 to make Quality-of-Service signaling
[RFC2205]. The data sender sends a RSVP "Path" message to the data
receiver that includes a Router Alert IP option telling the routers
on the path to investigate the RSVP message contents closer. Each
Sarolahti/Floyd/Kojo Section 5.3. [Page 14]
INTERNET-DRAFT Expires: September 2007 March 2007
router adds its IP address to the message to enable routing of the
Reservation (Resv) messages sent in the reverse direction to visit
exactly the same routers on the reverse path to the data sender. The
Resv message does not use the Router Alert option, but is rather
explicitly routed on a hop-by-hop basis between the network routers
using the state established earlier. In addition to the Path and
Resv messages, RSVP has a few other message types delivered on a
hop-by-hop basis. RSVP is an out-of-band "AllRouters" mechanism. We
also call it an on-path mechanism because it takes measures to
ensure that the resource reservation signaling follows the forward
path from sender to receiver.
Recently the IETF has specified a NSIS (Next Steps in Signaling)
framework to handle signaling in the Internet. The Generic Internet
Signaling Transport (GIST) protocol has been specified to transport
the application-specific signaling messages over the Internet
[SH06]. GIST messages are transfered using TCP or UDP as the
transport protocol, depending on whether a reliable connection-
oriented service or a connectionless service is desired. The use of
SCTP to carry GIST messages is also under investigation. GIST has
some common characteristics with RSVP: it uses a Router Alert option
to wake up the GIST-aware routers along the path, and for further
signaling, explicit hop-by-hop routing can be applied using the
state established at routers. Like RSVP, also GIST is an out-of-band
"AllRouters" scheme.
6. Past IETF Activities
This section discusses the past history of the IETF in considering
link-layer triggers and other types of cross-layer communication.
The IAB has an internet-draft on "Architectural Implications of Link
Indications" that summarizes current proposals, describes the
architectural issues and provides examples of appropriate and
inappropriate uses of link layer indications [Abo07]. The document
also gives a history of the integration of link indications within
the Internet architecture.
The "Performance Implications of Link Characteristics (pilc)"
working group produced seven RFCs concerning different types of
links and their effects on transport protocols. The PILC working
group did not explicitly consider cross-layer interactions; however,
the Performance Enhancing Proxies document [RFC3135] gives
guidelines for designing proxies that could also be useful
considerations for network devices with cross-layer functionality.
The Triggers for Transport BOF in November 2002 [TrigTranBof]
Sarolahti/Floyd/Kojo Section 6. [Page 15]
INTERNET-DRAFT Expires: September 2007 March 2007
discussed triggers such as "Link Up", "Link Down", and "Packet
Discarded". The necessity of a focused and narrow problem statement
was discussed, with a need to define the semantics and uses of
triggers in an exact way. It was questioned whether different
wireless link technologies would be able to reliably produce the
required information for the trigger, and what kind of responses
would be appropriate at the transport protocol. The consensus was
that the "Link Up" trigger might be viable, but that a "Link Down"
trigger would be more difficult to be implement in a way that would
be useful to the transport protocol. The BOF did not result in the
creation of a working group.
The Transport Service at the Intermediary BOF (intersec)
[IntersecBof] in March 2003 proposed to work on an architecture that
helps performance enhancing middleboxes interoperate better with
end-to-end transport protocols, especially with end-to-end security.
No working group was established.
BOFs on "Access Link Intermediaries Assisting Services (alias)"
[AliasBof1, AliasBof2] were held in two consecutive IETF meetings in
2003, continuing from the trigtran and intersec BOFs. ALIAS
extended the discussion to middle-boxes that explicitly signal their
existence and capabilities to the transport end-points (and vice-
versa). ALIAS included an extensive discussion of security issues,
along with a discussion of whether the possible benefits of such
intermediaries would be clear enough to make the work worthwhile. No
working group was created.
Recently there was a BOF proposal for IETF-66 in July 2006 called
"Transport-Enhancing Refinements to the Network Layer Interface
(ternli)". This didn't get as far as the above mentioned related
BOFs, because the BOF was canceled before the IETF meeting. Instead,
a group of people were gathered in an ad-hoc meeting in Montreal
discussing the problem space. TERNLI was motivated in part by the
research conducted in the MOBOPTS IRTF group about the effects of
mobility to transport protocols. While there was an agreement that
an explicit signaling mechanism between the transport and network
layers should not be limited to mobility, there was a discussion of
how the responsibilities should be divided between the Transport and
Internet Areas. It was discussed that the work in these two areas is
rather disconnected, and it is not always known what related work is
being done in the other area. It was agreed that it is worthwhile
to continue the discussion on the related research at least
informally on a mailing list established under the IETF servers.
The Jabber log of the meeting can be found at
[http://www.ietf.org/meetings/ietf-logs/tsvwg/2006-07-11.html].
Sarolahti/Floyd/Kojo Section 6. [Page 16]
INTERNET-DRAFT Expires: September 2007 March 2007
7. Challenges with Explicit Cross-layer Mechanisms
Today the Internet contains a wide variety of different types of
middleboxes, tunnels, and advanced packet handling technologies that
could cause problems for protocols that assume a simple architecture
of interconnected routers with simple packet forwarding algorithms.
In addition, the layer-two technologies have become more complex and
difficult to model and understand correctly. In this section we list
some common challenges to cross-layer mechanisms.
7.1. Security Issues
A cross-layer signaling protocol needs protective measures that are
strong enough to make attacks on the protocol difficult and
reasonably unprofitable. At the same time, if an otherwise light-
weight protocol has heavy-weight security mechanisms, the cost of
the security procedures may outweigh the possible benefits of the
protocol. It may be possible also to mitigate the potential attacks
from misleading hints by designing robust response mechanisms, and
considering the offered data as advisory information, while still
monitoring that other sources do not provide conflicting information
[EE06]. For example, if the sender has increased the transmission
rate based on a recent notification, followed by an increased number
of congestion-based packet losses, there is a clear conflict in the
received information.
For in-band mechanisms that use reserved header bits or IP options,
the receiver of the packet can be expected to check that the IP
addresses and transport ports match the existing connection, and
that the sequence numbers in the packet belong to the currently
valid window. Therefore, blind attacks generated outside the packet
transmission path have a reasonably low probability of succeeding.
For example, most TCP connections survive comfortably in the
Internet, although security of the basic TCP has been discovered to
be insufficient in certain mission-critical long-term connections
[SD06,Tou06]. However, an attacker on a connection path that is able
to read the transport and IP headers has a good chance of causing
harm to a connection, particularly if the packet contains additional
explicit information about the connection, for example in an IP
option. IPsec can protect the transport header, but does not protect
a mutable IP option that can be modified by routers along the path.
Out-of-band messages do not necessarily include the additional
context from the transport protocol, so they can be an easier target
for blind attackers. If a transport protocol context exists, for
example when the message is triggered by a data packet, the sender
of the out-of-band signaling message can include the transport
Sarolahti/Floyd/Kojo Section 7.1. [Page 17]
INTERNET-DRAFT Expires: September 2007 March 2007
header from a recent data packet with the message to authorize the
message based on the "proof" that the message has come from the
right source. In principle it cannot be assured that an out-of-band
message uses the same path as the data traffic, although it can be
assumed to be a common case.
For off-path signaling, for example sent by an intermediate router,
including transport protocol context is not necessarily possible
when IPsec is used to encrypt the data traffic. To more securely
authenticate the sender of a signaling message a more elaborate
security framework is needed. It is possible that the complexity of
such a security framework causes the costs of the mechanism to
defeat the possible benefits.
The routers on the connection path can also try to cheat a cross-
layer signaling mechanism. A first-hop router that is located in the
same administrative domain with the transport end-host may have an
incentive to game the protocol to the end-host's benefit. For
example, in the case of Explicit Congestion Notification, a router
could try to erase the Congestion Experienced bit on the packet, or
a Quick-Start-aware router could try to game a better transmission
rate for the transport sender. ECN and Quick-Start both use random
content in the header fields called Nonces to make it more difficult
for routers and receivers to misuse the protocol. Nonces usually do
not provide full protection against misuse, but rather make cheating
difficult enough to be unprofitable.
7.2. IP Tunnels
IP tunnels are a challenge for an explicit cross-layer notification
protocol that requires participation of the routers, because the
tunnel isolates the original IP header inside an outer header. A
tunnel protocol could copy the important cross-layer notification
data to the outer header at the tunnel ingress so that the routers
along the tunnel path can process the information, and then at the
tunnel egress copy the possibly changed cross-layer data back to the
inner header. For IPsec tunnels there is a special consideration
whether exposing the cross-layer data in the outer header is a
violation of the security policy. It is possible that some
additional cross-layer information on the outer header makes it
possible for an intruder to make additional conclusions about the
nature of the data that is being transfered inside the IPsec tunnel.
Because the interaction of congestion control and mobility has been
one of the key motivations for advanced cross-layer interactions, it
is worth noting that one of the most common mobility mechanisms,
Mobile IPv4, is based on the use of IP tunneling [RFC3344]. When a
Sarolahti/Floyd/Kojo Section 7.2. [Page 18]
INTERNET-DRAFT Expires: September 2007 March 2007
mobile host is not at its home location, the Mobile IPv4 home agent
receives the packets on behalf of the mobile host, and forwards them
to the care-of-address of the mobile host in an IP tunnel. There can
also be deployments with several layers of tunneling, for example
when IPsec is used together with Mobile IPv4.
IP tunnels are a particular challenge for "AllRouters" mechanisms,
because currently there is no known guaranteed way to check that an
"AllRouters" notification has indeed been processed by all routers
when there is an IP tunnel on the connection path. The Quick-Start
specification includes a thorough discussion of problems with IP
tunnels [RFC4782]. The key points of that discussion are summarized
below.
As described in Section 4.2, a typical way for an "AllRouters"
mechanism to check that all of the routers have processed the
notification mechanism is to use a special TTL or hop-count field
with the notification data. Assuming that all routers decrease the
IP TTL field as specified, the difference between the IP TTL and the
special TTL field should tell if all routers have processed the
notification. If the difference does not match, the end-host knows
that there were routers along the path that did not support the
notification. However, a problem arises because some tunnels do not
necessarily decrease the IP TTL at the tunnel ingress. Therefore the
presence of the tunnel and all the routers along the tunnel path may
go undetected. This is harmful for the cross-layer notification
mechanism that may take actions based on the false assumption that
all routers processed the notification.
The Quick-Start specification defines two main categorizes for
tunnels: "simple tunnels" simply discard the outer header at the
tunnel egress, and "non-simple tunnels" that save and use
information from the outer header before discarding it. The
specification further divides tunnels into (i) tunnels that support
Quick-Start, (ii) tunnels that do not support Quick-Start, but are
compatible with Quick-Start, and (iii) tunnels that are not
compatible with Quick-Start. A tunnel that supports Quick-Start
processes the IP TTL and the special TTL fields appropriately and
copies the Quick-Start Request to the outer header. A tunnel that
does not support Quick-Start does not copy the Quick-Start Request
to outer header, but decreases the IP TTL appropriately so that the
end-hosts are able to detect that the whole network path did not
support Quick-Start. A tunnel that is not compatible may allow
false positives, i.e., false approvals of Quick-Start request in
situations where all routers did not process the Quick-Start
Request. Because an approved Quick-Start Request allows the sender
to transmit at a higher rate than the congestion control rules would
usually allow, in the worst case this could cause severe congestion
Sarolahti/Floyd/Kojo Section 7.2. [Page 19]
INTERNET-DRAFT Expires: September 2007 March 2007
in the network. Although the above classification was given in the
context of Quick-Start, the same principles hold in general for an
"AllRouters" cross-layer notification mechanism.
Multiprotocol Label Switching can be considered a special case of an
IP tunnel, where the IP header can be encapsulated in a small MPLS
shim header [RFC3031]. When a packet is transmitted through an MPLS
region, the IP header is not processed, but the MPLS specification
strongly recommends that the IP TTL field is decremented
appropriately at the edge of an MPLS region according to the number
of hops is traversed inside the MPLS region. If this recommendation
is followed, the above-described problem of false positives due to
unadjusted IP TTL cannot occur. However, because it seems unlikely
that a cross-layer notification mechanism is supported by MPLS, the
"AllRouters" schemes are not likely to work over MPLS regions,
depending on the purpose of the cross-layer mechanism.
7.3. Non-conformant routers and middleboxes
[MAF04] observes that for 70% of the destinations tested, TCP SYN
packets with unknown IP options were either lost in the network or
ignored by the receiving web server. ([MAF04] was not able to
determine further why these connections failed when unknown IP
options were added to the TCP SYN packets.) The presence of routers
or middleboxes that drop packets containing unknown IP options would
be a major obstacle to any cross-layer mechanisms that depended on
the use of IP options. With in-band mechanisms this would also
prevent delivery of the data in the packets, while with out-of-band
mechanisms the data transfer would not be directly affected. This is
particularly a problem in "SomeRouters" and "AllRouters" schemes,
that typically need to modify the IP header.
Employing the Destination Options or Hop-by-hop Options header in
IPv6 would avoid this problem. The IPv6 Destination Options header
is not subject to intermediary router inspection and would be
suitable in delivering signaling information when in-band signaling
is used without network involvement. The Hop-by-hop Options header
with IPv6 can be used when in-band signaling with support from some
routers is needed. The two highest-order bits of the Option Type
specifies the action that must be taken if the processing IPv6 node
does not recognize the option type, including the possibility to
skip over the option.
Traffic normalizers are one type of middleboxes that can be used
together with the Intrusion Detection Systems [HKP01]. Because
traffic normalizers can modify the contents of an IP header,
particularly the IP TTL field, they may interfere with the operation
Sarolahti/Floyd/Kojo Section 7.3. [Page 20]
INTERNET-DRAFT Expires: September 2007 March 2007
of "AllRouters" mechanisms that typically use the IP TTL to check
that all routers have processed the notification. In the worst case
such traffic normalizers might result in false positives by causing
the IP TTL and special TTL to match even if some routers did not
process the notification.
7.4. Processing efficiency
Packets with IP options are assumed to take the slow-path processing
path in most routers, as opposed to the optimized fast-path. If the
use of IP options or other mechanisms requiring router attention
gained in popularity, the impact on the processing efficiency of
routers would have to be considered. This problem concerns the
"SomeRouters" and "AllRouters" mechanisms. In the Quick-Start
proposal, it is assumed that Quick-Start-capable routers would rate-
limit the number of Quick-Start requests that are processed, to
preserve router efficiency and to protect against possible attacks
on the routers themselves.
8. Proposals for Future Actions
We have described different possibilities for utilizing cross-layer
indications on transport layer, as well as several challenges there
might be in deployment and use of such mechanisms, depending on the
level of network support a mechanism requires. The "AllRouters"
notifications are the most challenging class of cross-layer
mechanisms, because they not only require support from every router
along the connection path, but also need a reliable mechanism to
verify that each router has indeed processed the notification.
If there is interest in developing cross-layer indications further
to improve transport protocol performance, it would be useful to
solve the problems below, depending on the required level of network
support.
* "AllRouters" notifications: There should be a common, well-
specified mechanism to ensure that all routers have indeed
processed an explicit notification that is required to be
processed by every router, so that false positives would not be
possible. To help solving this problem, there would need to be a
common, well-specified way for tunnel ingress and egress nodes to
process explicit indications that require some level of support
from routers along the path. A possible approach could be to aim
for a common framework for transmitting light-weight explicit
notifications.
Sarolahti/Floyd/Kojo Section 8. [Page 21]
INTERNET-DRAFT Expires: September 2007 March 2007
* "SomeRouters" and "AllRouters" notifications: There should be a
way to discourage routers and middleboxes from dropping packets
with unknown IP option header content. These nodes should rather
forward the packet without processing the unsupported option. As
the first step, there should be a better understanding of which
nodes drop the unknown options, and what is the reason for
dropping the packet.
* It would be useful for a designer of an cross-layer mechanism to
get input from the router designers to better understand the
performance limitations of a modern router, to help in designing
realistic cross-layer schemes. The router requirements can vary
much depending on the exact usage of the router: a local WLAN
access point may be able to employ more complex algorithms than a
high-performance backbone router.
The above listed challenges may be technically difficult to solve in
the current Internet. However, the above discussion hopefully sheds
some light on the amount of work required to design a cross-layer
mechanism that is usable in the Internet.
A. List of Changes
Changes from draft-sarolahti-tsvwg-crosslayer-00:
* Added a paragraph about MSS and its relation to link MTU.
* Added a paragraph about possibilities of IPv6 to Section 6.3.
* Description of terminology and the scope of this document added,
from the proposal from Scott Brim. Also the document title and
introduction were updated slightly.
* Re-organized the taxonomy and description of different proposed
schemes, after proposal from Gregory Woodhouse.
* Some updates to introduction and security issues referring to a
related paper on rethinking the transport layer interfaces [EE06].
* Changed the document title
* Added more discussion on IP tunnels and MPLS (from a
recommendation by Wesley Eddy)
* Moved discussion about path vs. link indications to the congestion
Sarolahti/Floyd/Kojo Section A. [Page 22]
INTERNET-DRAFT Expires: September 2007 March 2007
control subsection.
* Added a paragraph about traffic normalizers to middleboxes
section.
* Added a paragraph about Mobile IPv4 to the IP tunnels section,
from suggestion by Wesley Eddy.
* Added text to the "Proposals for Future Actions" section at the
end of the document
* Added a short paragraph about IEEE 802.21 and MIPSHOP & MOBOPTS
work at the IETF, from proposal of Qiaobing Xie.
* Added a section on top-down and bottom-up indications.
* Modified the Connectivity-change option description based on the
feedback from Simon Schuetz.
Normative References
[RFC793] J. Postel. Transmission Control Protocol. RFC 793,
September 1981.
[RFC2119] S. Bradner. Key words for use in RFCs to Indicate
Requirement Levels. BCP 14, RFC 2119, March 1997.
[RFC2460] S. Deering and R. Hinden. Internet Protocol, Version 6
(IPv6) Specification. RFC 2460, December 1998.
[RFC2581] M. Allman, V. Paxson, and W. Stevens. TCP Congestion
Control. RFC 2581. April 1999.
[RFC2914] S. Floyd. Congestion Control Principles. RFC 1914,
September 2000.
[RFC3168] K.K. Ramakrishnan, S. Floyd, and D. Black. The Addition
of Explicit Congestion Notification (ECN) to IP. RFC 3168, Proposed
Standard, September 2001.
Informative References
[AliasBof1] Access Link Intermediaries Assisting Services (alias)
Bof minutes from IETF-57, Vienna, Austria, July 2003. Available at
http://www3.ietf.org/proceedings/03jul/250.htm
Sarolahti/Floyd/Kojo [Page 23]
INTERNET-DRAFT Expires: September 2007 March 2007
[AliasBof2] Access Link Intermediaries Assisting Services (alias)
Bof minutes from IETF-58, Minneapolis, MN, USA, November 2003.
Available at http://www3.ietf.org/proceedings/03nov/248.htm
[RFC792] J. Postel. Internet Control Message Protocol. RFC 792,
September 1981.
[RFC1191] J. Mogul and S. Deering. Path MTU Discovery. RFC 1191,
November 1990.
[RFC2113] D. Katz. IP Router Alert Option. RFC 2113, February 1997.
[RFC2205] R. Braden (ed.). Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification. RFC 2205, September 1997.
[RFC2207] R. Berger and T. O'Malley. RSVP Extensions for IPSEC Data
Flows. RFC 2207, September 1997.
[RFC2401] S. Kent and R. Atkinson. Security Architecture for the
Internet Protocol. RFC 2401, November 1998.
[RFC2463] A. Conta and S. Deering. Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification. RFC 2463, December 1998.
[RFC2711] C. Partridge and A. Jackson. IPv6 Router Alert Option. RFC
2711, October 1999.
[RFC3031] E. Rosen, A. Viswanathan, and R. Callon. Multiprotocol
Label Switching Architecture. RFC 3031, January 2001.
[RFC3135] J. Border, M. Kojo, J. Griner, G. Montenegro, and Z.
Shelby. Performance Enhancing Proxies Intended to Mitigate Link-
Related Degradations. RFC 3135, June 2001.
[RFC3234] B. Carpenter and S. Brim, Middleboxes: Taxonomy and
Issues, RFC 3234, February 2002.
[RFC3344] C. Perkins (ed.). IP Mobility Support for IPv4. RFC 3344,
August 2002.
[RFC3828] L-A. Larzon, M. Degermark, S. Pink, L-E. Jonsonn, and G.
Fairhurst, The Lightweight User Datagram Protocol (UDP-Lite), RFC
3828, July 2004.
[RFC4782] S. Floyd, M. Allman, A. Jain, and P. Sarolahti. Quick-
Start for TCP and IP. RFC 4782, January 2007.
Sarolahti/Floyd/Kojo [Page 24]
INTERNET-DRAFT Expires: September 2007 March 2007
[Abo07] B. Aboba (ed.). Architectural Implications of Link
Indications, Internet-Draft "draft-iab-link-indications-07.txt",
February 2007. Work in progress.
[BJSK06] B. Briscoe, A. Jacquet, A. Salvatori, and M. Koyabe. Re-
ECN: Adding Accountability for Causing Congestion to TCP/IP.
Internet-Draft "draft-briscoe-tsvwg-re-ecn-tcp-02", June 2006. Work
in progress.
[Cla88] D. D. Clark. The Design Philosophy of the DARPA Internet
Protocols. In Proceedings of ACM SIGCOMM '88, pages 106--114,
Stanford, CA, USA.
[DK06] L. Daniel and M. Kojo. Adapting TCP for Vertical Handoffs in
Wireless Networks. In Proc. 31st IEEE Conference on Local Computer
Networks (LCN), Tampa, FL, USA, November 2006.
[EE06] L. Eggert and W. Eddy. Towards More Expressive Transport-
Layer Interfaces. In Proceedings of ACM MOBIARCH '06, San Francisco,
CA, USA, November 2006.
[FPK06] A. Falk, Y. Pryadkin, and D. Katabi. Specification for the
Explicit Control Protocol (XCP). Internet-Draft "draft-falk-xcp-
spec-02.txt", November 2006. Work in progress.
[G06] F. Gont. ICMP attacks against TCP. Internet-Draft "draft-ietf-
tcpm-icmp-attacks-01", October 2006. Work in progress.
[GL03] A. Gurtov and R. Ludwig. Lifetime Packet Discard for
Efficient Real-Time Transport over Cellular Links. ACM Mobile
Computing and Communications Review, 7(4):32-45, October 2003
[Hal96] F. Halsall. Data Communications, Computer Networks and Open
Systems, Fourth edition. Addison-Wesley, 1996.
[HKP01] M. Handley, C. Kreibich and V. Paxson, Network Intrusion
Detection: Evasion, Traffic Normalization, and End-to-End Protocol
Semantics, Proc. USENIX Security Symposium 2001.
[IEEE21] IEEE 802.21: Media Independent Handover Services. Available
at: http://www.ieee802.org/21/
[IntersecBof] Transport Service at the Intermediary BOF (intersec)
minutes from IETF-56, San Francisco, CA, USA, March 2003. Available
at http://www3.ietf.org/proceedings/03mar/248.htm
[KHR02] D. Katabi, M. Handley, and C. Rohrs. Congestion Control for
High Bandwidth-Delay Product Networks. In Proceedings of ACM
Sarolahti/Floyd/Kojo [Page 25]
INTERNET-DRAFT Expires: September 2007 March 2007
SIGCOMM 2002, Pittsburgh, PA, USA, August 2002.
[KSE+04] R. Krishnan, J. Sterbenz, W. Eddy, C. Partridge, and M.
Allman. Explicit Transport Error Notification (ETEN) for Error-
Prone Wireless and Satellite Networks. Computer Networks, 46(3),
October 2004
[LR99] R. Ludwig and B. Rathonyi. Link Layer Enhancements for
TCP/IP over GSM. In Proceedings of the Conference on Computer
Communications (IEEE Infocom), New York, USA, March 1999.
[MAF04] A. Medina, M. Allman, and S. Floyd. Measuring Interactions
Between Transport Protocols and Middleboxes. Internet Measurement
Conference 2004, August 2004. URL "http://www.icir.org/tbit/".
[RW03] M. Rossi and M. Welzl. On the Impact of IP Option
Processing, Preprint-Reihe des Fachbereichs Mathematik - Informatik,
No. 15, Institute of Computer Science, University of Innsbruck,
Austria, October 2003.
[RW04] M. Rossi and M. Welzl. On the Impact of IP Option Processing
- Part 2, Preprint-Reihe des Fachbereichs Mathematik - Informatik,
No. 26, Institute of Computer Science, University of Innsbruck,
Austria, July 2004.
[SAF06] P. Sarolahti, M. Allman, and S. Floyd. Determining an
Appropriate Sending Rate Over an Underutilized Network. Computer
Networks Journal, Elsevier, August 2006.
[SEE+06] S. Schuetz, L. Eggert, W. Eddy, Y. Swami, and K. Le. TCP
Response to Lower-Layer Connectivity-Change Indications. Internet-
Draft "draft-schuetz-tcpm-tcp-rlci-00", May 2006. Work in progress.
[SH06] H. Schulzrinne and R. Hancock. GIST: General Internet
Signaling Transport. Internet-Draft "draft-ietf-nsis-ntlp-10", July
2006. Work in progress.
[SKDK06] P. Sarolahti, J. Korhonen, L. Daniel, and M. Kojo. Using
Quick-Start to Improve TCP Performance with Vertical Hand-offs. In
Proc. IEEE Workshop on Wireless Local Networks (WLN) 2006, Tampa,
FL, USA, November 2006.
[SD06] R. Stewart, M. Dalal (ed.). Improving TCP's Robustness to
Blind In-Window Attacks. Internet-Draft "draft-ietf-tcpm-
tcpsecure-05.txt", June 2006. Work in progress.
[TGM+06] F. Teraoka, K. Gogo, K. Mitsuya, R. Shibui, and K. Mitani.
Unified L2 Abstractions for L3-Driven Fast Handover. Internet-Draft
Sarolahti/Floyd/Kojo [Page 26]
INTERNET-DRAFT Expires: September 2007 March 2007
"draft-irtf-mobopts-l2-abstractions-01.txt", September 2006. Work in
progress.
[Tou06] J. Touch. Defending TCP Against Spoofing Attacks. Internet-
Draft "draft-ietf-tcpm-tcp-antispoof-05.txt", October 2006. Work in
progress.
[TrigTranBof] Triggers for Transport (trigtran) Bof minutes from
IETF-56, San Francisco, CA, USA, March 2003. Available at
http://www3.ietf.org/proceedings/03mar/251.htm
[Wel03] M. Welzl, PMTU-Options: Path MTU Discovery Using Options.
Expired Internet-Draft "draft-welzl-pmtud-options-01.txt", February
2003. URL "http://www.welzl.at/research/publications/".
[XSSK05] Y. Xia, L. Subramanian, I. Stoica, and S. Kalyanaraman.
One More Bit Is Enough. In Proceedings of SIGCOMM 2005, August 2005.
[ZDPS01] Y. Zhang, N. Duffield, V. Paxson, and S. Shenker, On the
Constancy of Internet Path Properties, Proc. ACM SIGCOMM Internet
Measurement Workshop, November 2001.
Acknowledgements
The authors would like to thank Scott Brim, Bob Briscoe, Wesley
Eddy, Fernando Gont, Simon Schuetz, Gregory Woodhouse, and Qiaobing
Xie for useful comments that have helped to improve this document.
AUTHORS' ADDRESSES
Pasi Sarolahti
Nokia Research Center
P.O. Box 407
FI-00045 NOKIA GROUP
Finland
Phone: +358 50 4876607
Email: pasi.sarolahti@nokia.com
Sally Floyd
Phone: +1 (510) 666-2989
ICIR (ICSI Center for Internet Research)
Email: floyd@icir.org
URL: http://www.icir.org/floyd/
Sarolahti/Floyd/Kojo [Page 27]
INTERNET-DRAFT Expires: September 2007 March 2007
Markku Kojo
University of Helsinki
Department of Computer Science
P.O. Box 68
FIN-00014 UNIVERSITY OF HELSINKI
Finland
Phone: +358 9 191 51305
EMail: kojo@cs.helsinki.fi
Sarolahti/Floyd/Kojo [Page 28]
INTERNET-DRAFT Expires: September 2007 March 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Sarolahti/Floyd/Kojo [Page 29]
