Re: [Mobopts] Ternli BOF

[Rajeev Koodli <[e-mail]>]

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
>
> -----------------------------
>
> 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
>



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