[MULTIMOBSEC-API] Fwd: [Int-area] BOF: Transport-Enhancing Refinements to the Network Layer Interface (TERNLI)

[Pekka Nikander <[e-mail]>]

FYI.  --Pekka

Begin forwarded message:

> From: Lars Eggert <[e-mail]>
> Date: June 12, 2006 10:33:14 GMT+03:00
> To: [e-mail], [e-mail], [e-mail], [e-mail]
> Subject: [Int-area] BOF: Transport-Enhancing Refinements to the  
> Network Layer Interface (TERNLI)
> Reply-To: [e-mail]
>
> Hi,
>
> please note that the TSV and INT are sponsoring the following non- 
> WG-forming BOF in Montreal. We'd welcome any input you may have on  
> the scope or content of this BOF. This discussion should take place  
> on the BOF mailing list.
>
> 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, 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
>
>
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/int-area


_______________________________________________
MULTIMOBSEC-API mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/multimobsec-api