[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/