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

[Michael Welzl <[e-mail]>]

Hi,

I also think that discussing this together with ICCRG'ers
is a good idea (and another reason for them to get moving
a bit  :-)   ).

As for a presentation, I can't make it to Montreal - Keshav,
can you?

Cheers,
Michael


On Wed, 2006-06-14 at 09:07, Lars Eggert wrote:
> 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
-- 
Michael Welzl <[e-mail]>
University of Innsbruck