One document matched: draft-sarolahti-tsvwg-crosslayer-00.txt
Internet Engineering Task Force P. Sarolahti
INTERNET-DRAFT Nokia Research Center
draft-sarolahti-tsvwg-crosslayer-00.txt S. Floyd
Expires: April 2007 ICIR
15 October 2006
Cross-layer Indications for Transport Protocols
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 April 2007.
Abstract
This document discusses different types of explicit cross-layer
signaling and notification mechanisms that have been proposed to
enhance end-to-end transport performance. We analyze the different
mechanisms in a framework based on what level of network support
they require, and discuss the benefits and disadvantages different
approaches have. The objective is to get a common understanding of
Sarolahti/Floyd [Page 1]
INTERNET-DRAFT Expires: April 2007 October 2006
the problem space, 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 [Page 2]
INTERNET-DRAFT Expires: April 2007 October 2006
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Roles of different protocol layers . . . . . . . . . . . 4
1.2. Conventions and Terminology. . . . . . . . . . . . . . . 5
2. Possible Benefits of Explicit Signaling . . . . . . . . . . . 5
3. Classification of Explicit Signaling Mechanisms . . . . . . . 6
4. Proposed Explicit Cross-layer Mechanisms. . . . . . . . . . . 8
4.1. In-band signaling without network involve-
ment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. In-band signaling requiring support from
some routers along the path . . . . . . . . . . . . . . . . . 8
4.3. In-band signaling requiring support from all
routers along the path. . . . . . . . . . . . . . . . . . . . 9
4.4. Out-of-band signaling without network
involvement . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. Out-of-band signaling requiring support from
some routers along the path.. . . . . . . . . . . . . . . . . 10
4.6. Out-of-band signaling requiring support from
all routers along the path. . . . . . . . . . . . . . . . . . 10
5. Past IETF Activities. . . . . . . . . . . . . . . . . . . . . 11
6. Possible Problems with Cross-layer Mechanisms . . . . . . . . 12
6.1. Security Issues. . . . . . . . . . . . . . . . . . . . . 12
6.2. IP Tunnels . . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Non-conformant routers and middleboxes . . . . . . . . . 14
6.4. Processing efficiency. . . . . . . . . . . . . . . . . . 14
6.5. Path vs. link indications. . . . . . . . . . . . . . . . 14
6.6. Other concerns . . . . . . . . . . . . . . . . . . . . . 15
7. Proposals for Future Actions. . . . . . . . . . . . . . . . . 15
Normative References . . . . . . . . . . . . . . . . . . . . . . 15
Informative References . . . . . . . . . . . . . . . . . . . . . 16
AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 18
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
In the past there have been different proposals on enhancing
transport protocol (usually TCP) performance by means of explicit
cross-layer signaling. The cross-layer signaling 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, the explicit signaling between the network and the
end-hosts involves several considerations on the network behavior
that we try to capture in this document.
Sarolahti/Floyd Section 1. [Page 3]
INTERNET-DRAFT Expires: April 2007 October 2006
Cross-layer signaling could be used, for example, for delivering
hints to a TCP 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
signaling methods. While many of the signaling mechanisms discussed
in this document conform to this principle, others 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.
This document casts an overview on different types of explicit
cross-layer signaling, and discusses their possibilities and
challenges. The objective of the final document is to get a common
understanding of the problem space and to describe the possible next
steps towards removing barriers from explicit cross-layer
communication in future protocols.
1.1. Roles of different protocol layers
It is difficult to find a course book on computer networks 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
Sarolahti/Floyd Section 1.1. [Page 4]
INTERNET-DRAFT Expires: April 2007 October 2006
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.
* 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.
1.2. 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. 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]). It has been observed that with better awareness
of mobility, benefits on transport protocol performance can be
achieved.
* High delay-bandwidth networks: TCP slow-start is known to be
inefficient when used over a very high-speed network path, or over
Sarolahti/Floyd Section 2. [Page 5]
INTERNET-DRAFT Expires: April 2007 October 2006
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.
3. Classification of Explicit Signaling Mechanisms
We discuss a number of explicit signaling mechanisms by placing them
into the following catgories. Each of the classes below has some
common characteristics that determine how powerful the given type of
signaling can be, and what kind of challenges can be expected.
A high-level classification is made to in-band and out-of-band
signaling mechanisms. In-band signaling goes with the normal data
traffic. The benefit is that in-band messages are known to share the
same path as the data, and generally use less header overhead than a
separate message. In addition, with in-band messages the sender is
often able to know 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 an unknown option, the accompanying data also gets lost,
causing a performance penalty for the data transfer.
* In-band signaling without network involvement.
There have been several proposals to place information inside the
transport header, for example using a TCP option. The information
flows between the end hosts, but should not be read or modified by
the network routers, because routers do not typically investigate
transport headers. Furthermore, IPsec may prevent the routers from
reading the option altogether.
* In-band signaling requiring support from some routers along the
Sarolahti/Floyd Section 3. [Page 6]
INTERNET-DRAFT Expires: April 2007 October 2006
path.
Typically mechanisms in this class use the IP header in one way or
another; either through using the reserved (nowadays the DiffServ)
bits in the IP header, or using an IP option. If the mechanism is
such that it is useful without all routers supporting it, the
deployment seems realistic: even long network paths can be
supported and IP tunnels do not defeat the mechanism. ECN
(Explicit Congestion Notification) [RFC3168] is one example of in-
band signaling requiring support from some routers along a path.
* In-band signaling requiring support from all routers along the
path.
If all routers need to support an IP-level option, the deployment
becomes challenging. It is difficult to get universal support
outside the host's own network domain. Verifying that all routers
have indeed processed an explicit notification is also difficult
in a network environment that might consist of IP tunnels,
different types of middleboxes and other types of special network
equipment. Quick-Start [FAJS06] is an example of in-band
signaling requiring support from all routers along a path.
* Out-of-band signaling without network involvement.
ICMP is one of the oldest out-of-band signaling methods in the
Internet. If an incoming packet causes an error condition, for
example from using a protocol not supported at the receiver, the
receiver generates an ICMP error message. Usually a portion of the
transport header is included in the ICMP payload as additional
information for the sender.
* Out-of-band signaling requiring support from some routers along
the path.
Network routers can also generate ICMP messages, for example, to
implement Path MTU discovery by sending ICMP errors for packets
exceeding link MTU. The functionality is similar to the case of an
end-host generating an ICMP message. However, if IPsec encryption
is employed, it may be impossible for the ICMP message to include
portions of the transport header.
* Out-of-band signaling requiring support from all routers along the
path.
This class of mechanisms uses dedicated packets that are processed
at the router. The Resource ReserVation Protocol (RSVP) [RFC2205]
is one such mechanism. Typically a router alert IP option is
needed to notify the router forwarding function that the payload
of the IP packet contains data to be processed by the router.
Sarolahti/Floyd Section 3. [Page 7]
INTERNET-DRAFT Expires: April 2007 October 2006
4. Proposed Explicit Cross-layer Mechanisms
In this section ee discuss some of the explicit cross-layer
signaling mechanisms that have been proposed in the past.
4.1. In-band signaling without network involvement
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. The option
could be used by a mobile receiver to indicate the other end that it
has moved and the congestion control characteristics of a path
should be re-evaluated. When connectivity is re-established after a
short disruption, the option could also be used by the receiver that
detects re-establishment of link connectivity to trigger a fast
retransmission at the transmitting end. The TCP option would not
require support from network, but it would need to be supported by
both ends of the connection.
4.2. In-band signaling requiring support from some routers along the
path
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, but we believe that today most of
these routers have been fixed.
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."
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 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.
Sarolahti/Floyd Section 4.2. [Page 8]
INTERNET-DRAFT Expires: April 2007 October 2006
4.3. In-band signaling requiring support from all routers along the
path
In Quick-Start [FAJS06], the sender uses an IP option to request
permission from routers to send at a higher rate than the normal
congestion control would allow. [FAJS06] specifies use of Quick-
Start for TCP and discusses the challenges such a mechanism 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.
IP tunnels impose a serious challenge for Quick-Start and other
similar mechanisms, as discussed in [FAJS06]. We discuss IP tunnels
further in Section 6.2 of this document. Another problem with
deploying new IP options is that some routers or middle-boxes in the
network silently drop packets containing known or unknown IP options
[MAF04]. It has not been identified which network devices do this,
and on which basis.
IP options has also been proposed for Path MTU Discovery [Wel03].
The design principles of IP-option-based Path MTU Discovery are
roughly similar to Quick-Start, as are the challenges it faces.
Explicit Control Protocol (XCP) [KHR02] 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.
Variable-structure congestion Control Protocol (VCP) is another
proposed congestion control proposal using explicit feedback from
routers. VCP leverages the ECN bits 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.
4.4. Out-of-band signaling without network involvement
While the Internet Control Message Protocol (ICMP) [RFC792, RFC2463]
is not a cross-layer signaling mechanism but rather an IP-layer
signaling mechanism, it is the Internet's basic mechanism for
communicating error conditions and other notifications to the end
hosts, and could be used as a bearer for cross-layer notifications.
Many ICMP errors, such as "Protocol unreachable", originate from the
intended destination of the IP packet. Part of the IP payload is
included in the ICMP message to help the sender identify the
Sarolahti/Floyd Section 4.4. [Page 9]
INTERNET-DRAFT Expires: April 2007 October 2006
transport protocol flow that caused the error, and to provide means
of a basic (but rather weak) check of authenticity of the ICMP
message. ICMP is an unreliable mechanism: if the ICMP message is
lost in the network, neither the sender or the receiver gets a
direct indication of the loss.
4.5. Out-of-band signaling requiring support from some routers along
the path.
The ICMP messages can also originate from the network, as with a
"Destination unreachable" message. The router can include part of
the IP payload in the message, but if the original data packet is
tunneled, for example, in an IPsec tunnel, the payload cannot be
used to identify the transport protocol flow, and the sender cannot
do much about checking the authenticity of the ICMP message.
4.6. Out-of-band signaling requiring support from all routers along the
path.
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
router adds its IP address to the message to enable routing of the
Reservation (Resv) messages sent in the reverse direction to follow
exactly the same network path. 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.
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.
Sarolahti/Floyd Section 4.6. [Page 10]
INTERNET-DRAFT Expires: April 2007 October 2006
5. Past IETF Activities
This section discusses the past history of the IETF in considering
link-layer triggers and other issues 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 [Abo06]. 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]
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 a 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.
Sarolahti/Floyd Section 5. [Page 11]
INTERNET-DRAFT Expires: April 2007 October 2006
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].
6. Possible Problems with Cross-layer Mechanisms
As described in the summary above on past IETF activities, there is
some interest and motivation in starting up new work on explicit
cross-layer communication. This section attempts to summarize what
is known about some of the open issues in this area.
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.
6.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.
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
Sarolahti/Floyd Section 6.1. [Page 12]
INTERNET-DRAFT Expires: April 2007 October 2006
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]. 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 sending
router of the out-of-band signaling message can include the
transport header with the message, as for example ICMP does, to
authorize the message based on the "proof" that the message sender
is located on the packet transmission path. However, this is
unlikely to be useful 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. In many cases
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.
[TBD: Check out RSVP for IPsec [RFC2207]. However, that document
does not address the tunnel mode of IPsec.]
6.2. IP Tunnels
IP tunnels are a challenge for an explicit cross-layer protocol that
requires the participation of routers, because the tunnel isolates
Sarolahti/Floyd Section 6.2. [Page 13]
INTERNET-DRAFT Expires: April 2007 October 2006
the original IP header inside an outer header. In particular, IPsec
tunnels are intended to protect the inner header, which makes it
possible that exposing content from the inner IP header could be a
violation of the underlying security policy -- even if it was
technically possible for a tunnel ingress to do so. The Quick-Start
specification includes a thorough discussion of problems with IP
tunnels [FAJS06].
6.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.
6.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. 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.
6.5. Path vs. link indications
In some proposed cross-layer protocols, it has been unclear whether
information from a single local link or portion of a path is
sufficient to change the transmission rate of the sender. When a
link indication causes a reduction of the transmission rate, there
is usually no problem as long as reasonable measures are taken to
protect from third-party blind attacks and to ensure that the link
indication comes from a link that is still on the end-to-end path.
However, it is generally not acceptable for a link indication to
cause an increase in the transmission rate without first checking
the status of the whole network path between the sender and
receiver. Although the position of the IETF is probably solid on
this principle, in several cases the last-hop link is "known" to be
Sarolahti/Floyd Section 6.5. [Page 14]
INTERNET-DRAFT Expires: April 2007 October 2006
the bottleneck on the connection path, and in such cases there is a
high likelihood that the bandwidth of the last-hop link determines
the transmission rate between the sender and receiver. Considering
the difficulties of globally deploying an end-to-end cross-layer
scheme that requires feedback from all routers along a path, it is
possible that in the future parties will find it tempting to use
local link information in ways that are considered inappropriate by
the IETF.
6.6. Other concerns
[TBD: traffic normalizers]
[TBD: Problem of limited TCP option space]
[TBD: layer 2 queues and operation logic]
7. Proposals for Future Actions
* How tunnels should support cross-layer mechanisms?
* How to fix or go around routers and middleboxes that drop packets
with unknown options?
* How about fast-path processing at routers?
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.
[RFC3168] K.K. Ramakrishnan, S. Floyd, and D. Black. The Addition
of Explicit Congestion Notification (ECN) to IP. RFC 3168, Proposed
Sarolahti/Floyd [Page 15]
INTERNET-DRAFT Expires: April 2007 October 2006
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
[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.
[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.
[RFC2463] A. Conta and S. Deering. Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification. RFC 2463, December 1998.
[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.
[Abo06] B. Aboba (ed.). Architectural Implications of Link
Indications, Internet-Draft "draft-iab-link-indications-05.txt",
July 2006. 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.
[FAJS06] S. Floyd, M. Allman, A. Jain, and P. Sarolahti. Quick-
Start for TCP and IP. Internet-Draft "draft-ietf-tsvwg-
Sarolahti/Floyd [Page 16]
INTERNET-DRAFT Expires: April 2007 October 2006
quickstart-05.txt", July 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.
[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
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. To appear
in 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.
Sarolahti/Floyd [Page 17]
INTERNET-DRAFT Expires: April 2007 October 2006
[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. To
appear in 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.
[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.
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 [Page 18]
INTERNET-DRAFT Expires: April 2007 October 2006
Full Copyright Statement
Copyright (C) The Internet Society 2006. 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 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 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-22 23:33:01 |