[Iccrg] ICCRG-related BOF in Montreal: Transport-Enhancing Refinements to the Network Layer Interface (TERNLI)

[[e-mail] (Lars Eggert)]

Hi,

please note that the TSV and INT areas are sponsoring the following  
non-WG-forming BOF in Montreal. We'd welcome any input that ICCRG may  
have on the scope or content of this BOF. We'd also be interested in  
maybe seeing a short presentation from the congestion control  
research community during the BOF.

Thanks,
Lars

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

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

BOF Chairs:
<tbd>

Sponsoring Area Directors:
Lars Eggert <[e-mail]>
Magnus Westerlund <[e-mail]>
Jari Arkko <[e-mail]>

Mailing List:
General Discussion: [e-mail]
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 for 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/html/draft-iab-link-indications-04

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

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/html/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/html/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/html/draft-korhonen-mobopts-link- 
characteristics-ps-01

-- 
Lars Eggert                                     NEC Network Laboratories


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3686 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20060614/ba6479fa/smime-0001.bin
>From [e-mail]  Wed Jun 14 13:42:46 2006
From: [e-mail] (Wesley Eddy)
Date: Wed Jun 14 15:03:58 2006
Subject: [Iccrg] Soliciting input for cc. bibliography
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

On Tue, Jun 13, 2006 at 11:36:01PM +0200, Michael Welzl wrote:
> > For the CC-related RFCs, the TCP Roadmap already covers this ground (and
> > hopefully does so pretty well).  To me it does not seem valuable for the
> > ICCRG to spend a lot of time rehashing this, or asking participants to
> > review another, different, book report of this same material.  The
> > relevent roadmap portions are:
> > http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2006-March/000064.html
> 
> As much as I like the roadmap, it is by no means a complete
> overview of congestion control related RFCs - it's strictly
> about TCP, with no mention of, e.g., multicast congestion
> control, DCCP, Active Queue Management (RFC2309), link layer
> interactions with congestion control...
>
> The way I looked at this document is that it would give
> an overview of congestion control work in the IETF *except*
> for the things that are in the roadmap already (and that
> it would of course point to the roadmap as the main reference
> on anything TCP related) - and this is more than you might
> expect - see my previous post:
> http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2006-March/000066.html
> for an incomplete list.
>

Ah, in that case, I do think this would be valuable to work on.  The list
of RFCs in that link contains a lot of overlap with the roadmap, and I
guess that was what confused me.

> > On the other hand, a document that itemizes and describes the more
> > radical congestion control algorithms would be valuable, and I think the
> > group should concentrate on this deliverable.  To my knowledge, the only
> > such algorithms that are currently described in RFCs are HighSpeed
> > and Limited Slow-Start, so the TCP Roadmap does not even begin to cover
> > this area.
> 
> Do you still think that this should all be compiled
> in a single document in the light of what I said above?
>

I don't think it matters.  Smaller documents might generate more reviews
from the group than a single giant document, but I don't think it's
significant one way or the other,

-- 
Wesley M. Eddy
Verizon Federal Network Systems