[TERNLI] updated BOF description

Lars Eggert <lars.eggert@netlab.nec.de> Mon, 12 June 2006 09:07 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpiOU-0006c2-AN; Mon, 12 Jun 2006 05:07:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpiOT-0006bw-HC for ternli@ietf.org; Mon, 12 Jun 2006 05:07:33 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FphAo-0000JZ-Mi for ternli@ietf.org; Mon, 12 Jun 2006 03:49:22 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fph8J-0002B2-QJ for ternli@ietf.org; Mon, 12 Jun 2006 03:46:50 -0400
Received: from lars.local (unknown [192.100.124.156]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 37C3F1BAC4D for <ternli@ietf.org>; Mon, 12 Jun 2006 09:36:01 +0200 (CEST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id AC64D10CDFE for <ternli@ietf.org>; Mon, 12 Jun 2006 10:46:43 +0300 (EEST)
Mime-Version: 1.0 (Apple Message framework v750)
To: ternli@ietf.org
Message-Id: <69DACCFC-405E-44D1-8C61-6342DEB943AB@netlab.nec.de>
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8--7489107; protocol="application/pkcs7-signature"
From: Lars Eggert <lars.eggert@netlab.nec.de>
Date: Mon, 12 Jun 2006 10:46:42 +0300
X-Mailer: Apple Mail (2.750)
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a
Subject: [TERNLI] updated BOF description
X-BeenThere: ternli@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport-Enhancing Refinements to the Network Layer Interface <ternli.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ternli>, <mailto:ternli-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ternli>
List-Post: <mailto:ternli@ietf.org>
List-Help: <mailto:ternli-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ternli>, <mailto:ternli-request@ietf.org?subject=subscribe>
Errors-To: ternli-bounces@ietf.org

Hi,

compared to the announcement I sent a few minutes ago, this version  
of the agenda adds a new ID to the reading list.

Lars


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

BOF Chairs:
<tbd>

Sponsoring Area Directors:
Lars Eggert <lars.eggert@netlab.nec.de>
Magnus Westerlund <magnus.westerlund@ericsson.com>
Jari Arkko <jari.arkko@piuha.net>

Mailing List:
General Discussion: ternli@ietf.org
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

Lars Eggert and Wesley 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?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

J. Korhonen, S. Park, J. Zhang, C. Hwang and P. Sarolahti. Link  
Characteristic Information for IP Mobility Problem Statement.  
Internet Draft draft-korhonen-mobopts-link-characteristics-ps-01,  
Work in Progress, June 2006.
http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft- 
korhonen-mobopts-link-characteristics-ps-01


-- 
Lars Eggert                                     NEC Network Laboratories