Subject: [Mobopts] Ternli BOF

From: "James Kempf" <[email-masked]>
Date: Mon, 12 Jun 2006 08:46:44 -0700

In case folks haven't seen this. It seems to address the discussion last 
week.

            jak

-----------------------------

Transport-Enhancing Refinements to the Network Layer Interface (TERNLI)
(pronounce: "turn-ly")

BOF Chairs:
<tbd>

Sponsoring Area Directors:
Lars Eggert <[email-masked]>
Magnus Westerlund <[email-masked]>
Jari Arkko <[email-masked]>

Mailing List:
General Discussion: [email-masked]
To Subscribe: https://www.ietf.org/mailman/listinfo/ternli
Archive: http://www.ietf.org/mail-archive/web/ternli/index.html

BACKGROUND

The communication abstraction provided by IP at the network layer
delivers packets in an unordered, unreliable manner and does not
protect against duplication. The users of this abstraction, i.e., the
transport protocols, have made additional assumptions about this
abstraction. Many of these assumptions are critical to the effective
operation of important transport mechanisms, such as congestion
control, flow control or reliability. These assumptions include, for
example, that hosts remain at network locations identified by an IP
address on timescales that are orders of magnitude larger than the
duration of a communication instance. Another such assumption is that
packets flowing from a source to a destination mostly follow the same
path and that changes to that path occur on timescales that are
several orders of magnitude larger than the RTT between the two
hosts. Similarly, transport mechanisms have assumed that the
characteristics of such paths, such as bandwidth, delay, reordering
and loss probabilities, also change on timescales much larger than
the RTT.

In the current Internet, many of these assumptions are no longer
generally true, because it has become much more dynamic in recent
years. Mobile hosts and whole subnetworks have started to move
between network locations on relatively short timescales. A growing
number of hosts is multi-homed, connected through multiple links with
possibly very different properties at the same time. The Internet has
incorporated new link technologies with characteristics that are much
more dynamic than in the past, due to functionality such as link-
layer retransmissions, adaptive coding or support for link-local
mobility.

Several extensions to the internal functionality of the network
layer, such as Mobile IP, NEMO, HIP or SHIM6, support communication
in such dynamic environments. These extensions maintain the
traditional interface between network and transport layers, isolating
the transports from some of the dynamic effects present at and below
the network layer, similar to how transports remain unaware of
routing changes or packet fragmentation. They consequently allow
existing transport protocols to continue to operate without
modifications.

This isolation, however, comes at a cost, because the traditional
communication abstraction maintained by these new network-layer
extensions hides information that transport-layer protocols should
act on. Many common transport mechanisms, such as congestion window
estimation, RTT measurements or path MTU discovery, are not agile
enough to properly handle the significant instantaneous changes to
path characteristics that these network-layer extensions introduce.
This can, in turn, decrease the effectiveness of important transport
mechanisms, such as congestion control. Consequently, although
existing transports can operate on top of these network-layer
extensions to some degree, their performance and efficiency decreases.

SCOPE

This BOF brings together the INT and TSV communities to discuss how
this inter-area problem space can be successfully approached within
the IETF and IRTF. Consequently, detailed presentations of specific
technical proposals are out-of-scope for this BOF. The BOF will also
*not* lead to the formation of a working group. The goal is to give
interested parties a venue for discussing how this problem space
might be sliced.

The simple, general purpose interface between the network and
transport layers is one of the key features that has guaranteed the
evolvability of the Internet architecture, because it maintains the
independence of transport layers from functionality located below it,
and vice versa. Approaches for extending this core component must
therefore be broadly applicable and be of general usefulness. Point
solutions that optimize for specific deployment scenarios or
technologies are thus not relevant to this discussion.

DISCUSSION MATERIAL

A possible approach might be to identify a generic, technology-
independent set of well-defined network- and lower-layer information
that has the potential to improve performance and operation of a
large number of different transport mechanisms and protocols and can
be provided in different ways by different specific underlying
mechanisms and technologies. This information must be optional, i.e.,
it might improve transport operation if present, but transports must
not depend on its presence.

One existing example of an extension that follows this general
approach is Explicit Congestion Notification (ECN). The ECN signal is
well-defined and can be provided in different ways by network-layer
mechanisms; transport protocols act on the signal independently of
where and how it was generated. Another example of such an extension
in this spirit is Quick-Start, were routers in the network explicitly
signal source hosts the available capacity along the path to their
destinations. Transport protocols can utilize this generic,
technology-independent, network-layer information in different ways
to improve operation and performance.

One approach forward may be to integrate these existing or proposed
mechanisms with additional, similar extensions that result in a
uniform extension to the current network-layer interface.

The BOF organizers are interested in soliciting additional approaches
that attempt to address this problem space.

FURTHER READING

L. Eggert and W. Eddy. Towards More Expressive Transport-Layer
Interfaces. Under Submission, June 2006.
http://larseggert.de/papers/2006-ccr-transport-interfaces.pdf

B. Aboba (ed.) Architectural Implications of Link Indications.
Internet Draft draft-iab-link-indications-04, Work in Progress,
December 2005.
http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-iab-
link-indications-04.txt

K. Ramakrishnan, S. Floyd and D. Black. The Addition of Explicit
Congestion Notification (ECN) to IP. RFC 3168, September 2001.
http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?rfc=3168

A. Jain, S. Floyd, M. Allman and P. Sarolahti. Quick-Start for TCP
and IP. Internet Draft draft-ietf-tsvwg-quickstart-03, Work in
Progress, April 2006.
http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?rfc=&draft=draft-
ietf-tsvwg-quickstart-03

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, Work in Progress, May 2006.
http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?rfc=&draft=draft-
schuetz-tcpm-tcp-rlci-00

-- 

Lars Eggert                                     NEC Network Laboratories

_______________________________________________
Mobopts mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mobopts

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 12 Jun 2006 10:26:48 -0700

We should have some discussion on this at MobOpts and interact with the
BOF. Of course, our problem is lot more specific.

-Rajeev

James Kempf wrote:

> In case folks haven't seen this. It seems to address the discussion 
> last week.
>
>            jak
>