[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                      H. Tschofenig
Internet-Draft                                    Nokia Siemens Networks
Intended status: Standards Track                            July 9, 2012
Expires: January 10, 2013


                     The New Waist of the Hourglass
                   draft-tschofenig-hourglass-00.txt

Abstract

   When developing a new application layer protocol the question about
   its foundation arises.  The decision will be impacted by various
   factors but the ability for the solution to be deployable in today's
   Internet will certainly play a big role since various intermediaries
   may lead to a brittle communication architecture.

   The waist of the hourglass has changed over time: new applications
   have to run on top of UDP or TCP.  Protocol designs that use other
   transport protocols have turned out to be undeployable on the public
   Internet.  Running protocols on bare IP is also doomed to fail.  This
   change is not theoretic in nature but has real-world implications for
   protocol designers.

   There is also a trend to run applications on top of HTTP/HTTPS.  The
   author seeks more input from the wider IETF community about the
   deployment situation of protocol filtering by intermediaries and on
   the impact for protocol designers.

   This document is being discussed at
   https://www.ietf.org/mailman/listinfo/architecture-discuss

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 10, 2013.



Tschofenig              Expires January 10, 2013                [Page 1]


Internet-Draft       The New Waist of the Hourglass            July 2012


Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Network Address Translators  . . . . . . . . . . . . . . . . .  4
   3.  New Transport Protocols  . . . . . . . . . . . . . . . . . . .  6
   4.  Firewalls  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Will IPv6 reverse the shift? . . . . . . . . . . . . . . . . .  9
   6.  The Rise of the Web  . . . . . . . . . . . . . . . . . . . . . 10
   7.  Community Input Needed . . . . . . . . . . . . . . . . . . . . 11
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     11.1.  Normative References  . . . . . . . . . . . . . . . . . . 15
     11.2.  Informative References  . . . . . . . . . . . . . . . . . 15
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18



















Tschofenig              Expires January 10, 2013                [Page 2]


Internet-Draft       The New Waist of the Hourglass            July 2012


1.  Introduction

   The Internet protocol stack is organized in layers and text books
   typically talk about the data link layer, network layer, transport
   layer, and the application layer.

   IP evolved in a core part of protocol stack that represents a common
   intermediate protocol layer.  This intermediate layer is designed to
   support a variety of link layers and new link layer technologies can
   be added in the future, without affecting IP itself.

   In addition, IP supports a broad set of applications on top of it,
   ranging from email to instant messaging to voice over IP.  All of
   those applications do not require changes to IP itself.  As with link
   layers, new applications can be added at any time.

   The "Everything over IP, and IP over everything" theme, as it is
   often described, is shown graphically in Figure 1.



                  +------+------+------+------+------+
                  |Email | Web  | VoIP | P2P  | RTSP |
                  +------+------+------+------+------+
                         | TCP  |  UDP | ICMP |
                         +------+------+------+
                                |  IP  |
                         +------+------+------+
                         |Ether |Sonet | ATM  |
                  +------+------+------+------+------+
                  |Fiber | TP   | CAT5 | WiFi | GSM  |
                  +------+------+------+------+------+

                    Figure 1: The Original IP Hourglass

   This diagram is, of course, simplified but illustrates the level of
   interoperability needed to communication between different IP hosts.
   Combined with the end-to-end principle the hour glass indicates the
   level of protocol understanding intermediaries need to have in order
   to exchange forward IP packets between a sender and a receiver
   (absent any specific application layer entities, like proxies or
   caches).  Having IP as the waist meant that anyone could extend the
   layers above the network layer in the way they wanted to communicate
   end-to-end, including defining new transport layer protocols (as it
   was done with SCTP, and DCCP).

   Unfortunately, the various developments over the last years have
   changed this model.  We will describe the developments below.



Tschofenig              Expires January 10, 2013                [Page 3]


Internet-Draft       The New Waist of the Hourglass            July 2012


2.  Network Address Translators

   Originally, NAT was designed to operate strictly at the IP layer -
   translating internal to external addresses 1-for-1.  This was done
   primarily to avoid network renumbering when there was a change in
   provider.  However, NAT-P - NAT with port translation - quickly
   emerged.  In NAT-P, a large number of hosts can utilize a single
   external IP address by using the UDP and TCP port numbers as a
   demultiplexing point.

   In essence, the UDP or TCP port number became an extended version of
   the IP address - adding another 16 bits to the total amount of space,
   providing for 48 overall.

   NAT-P in particular, often just called NAT, has seem extremely
   widespread deployment.  Needless to say that this is a common
   deployment in residence with broadband Internet but with the work on
   Carrier Grade NAT it has also become a solution for dealing with IPv4
   shortage in their effort to migrate to IPv6.

   When put together, the implication is that basic packet transport
   between point A and point B is, these days, frequently possible only
   if the transport is UDP or TCP.  This is because NAT-P requires one
   of these two in order to utilize the 16 bit ports as as a
   demultiplexing point.  NATs, which are part of the network, have
   become not just TCP and UDP-aware, they have become TCP and UDP
   *dependent*.  Almost every NAT in deployment today will simply
   discard a packet above IP that is not TCP or UDP.  The primary
   exception is ICMP.  Some NATs will pass ICMP packets, but it is
   filtered by many.  Consequently, it only sometimes works on the
   Internet.  This is also making it difficult to rely on.  Indeed, it's
   success rate is sufficiently poor that new mechanisms for path MTU
   discovery have been designed which work without ICMP [RFC4821].

   This means that the operation of the public Internet is dependent on
   the existence of UDP and TCP traffic.

   Consequently, if new protocols have to ever actually work on the
   public Internet, they need to run on top of the only available packet
   transport on the Internet - UDP/IP.  UDP has replaced IP as the 'raw'
   point to point packet transport on the Internet.  If congestion
   control or signaling or other features are desired, they must be
   layered on top of UDP, rather than in a new protocol beside it.

   The IAB had published a number of publications to make the community
   aware of the implications.  In RFC 3724 the IAB examines the
   development of the end-to-end principle as it has been applied to the
   Internet architecture.  In RFC 3424 [RFC3424] the IAB specifically



Tschofenig              Expires January 10, 2013                [Page 4]


Internet-Draft       The New Waist of the Hourglass            July 2012


   addressed the problems created with NATs.


















































Tschofenig              Expires January 10, 2013                [Page 5]


Internet-Draft       The New Waist of the Hourglass            July 2012


3.  New Transport Protocols

   Does this mean that it is impossible to define new transport
   protocols?  Fortunately, the answer is no.  New transport protocols
   can be defined but the have to build on top of UDP or TCP.  The
   considerations for running them on top of UDP/TCP from Section 2
   apply.

   It is tempting to design a protocol on top of IP in such a way that
   it is "NAT friendly".  In this context, "NAT friendly" means that the
   protocol has been designed to make ALGs for that protocol easy to
   implement.  However, there is a vicious cycle that prevents such ALG
   functionality from ever being built.  New features get added to
   products, such as NATs, when the market demands them.  The market
   demands them when there is enough usage to create such a demand.
   However, if the protocol will fail utterly to work in the face of
   existing NAT, there will never be enough usage to create such demand.
   Even if there was, the amount of time it would take to upgrade all of
   the NATs on the Internet to support this ALG functionality is
   astoundingly large.  Thus, the protocol will continue to be
   unreliable on the Internet, since there is always a chance that it
   hits a NAT which does not support the necessary ALG functionality.

   Consequently, designing protocols to be "NAT friendly" in this way
   does not work in practice.  New applications and protocols must be
   designed to run on top of either UDP or TCP.

   Examples of where this has been done after the fact is
   [I-D.ietf-tsvwg-sctp-udp-encaps] for SCTP and [RFC3948] for IPSec.
   However, it is far better to define this at the beginning, and
   furthermore, have it as the one and only mode of operation.  This
   avoid protocol choices, and therefore simplifies design and improves
   interoperability.


















Tschofenig              Expires January 10, 2013                [Page 6]


Internet-Draft       The New Waist of the Hourglass            July 2012


4.  Firewalls

   Unfortunately, it is not just NATs that cause problems for end-to-end
   communication.  Firewalls are also TCP and UDP aware, and are often
   configured to discard non-UDP or non-TCP traffic.  The degree of
   filtering depends on the type of network; enterprise networks have
   traditionally been more aggressive in filtering even outgoing
   traffic.

   Many firewalls are stateful, i.e., they create state information when
   they see an packet from the internal network towards the Internet.
   An unpleasant property of stateful packet filtering firewalls is that
   they may lead to dropped packets when an arriving packet does not
   match the previously allocated state information or when they drop
   packets as part of their policy (as it is often the case when non-
   UDP/non-TCP packets are seen).  Furthermore, the firewall (as well as
   NATs) decide locally when to time-out state information without
   informing any other network entities leaving end hosts guessing about
   the rate at which they need to send keep-alive messages.  Time-out
   intervalls typically varry between TCP and UDP but vary considerable
   between different deployments and between products from different
   vendors.

   IETF protocol designers have already revised some protocols to handle
   stateful packet filtering firewalls.  Examples can be found with RFC
   4487 [RFC4487] and RFC 5207 [RFC5207].

   Clever protocol designers started to invent algorithms to test paths
   between address pairs for reachability.  These patch tests are time
   consuming and need to be re-run regularly when the network conditions
   change.  The more address pairs are available (IPv4, IPv6, tunnels,
   etc.) the longer the tests need.

   One such path test mechanism is the Interactive Connectivity
   Establishment (ICE) protocol, described in RFC 5245 [RFC5245], and it
   has been successfully used with the Extensible Messaging and Presence
   Protocol (XMPP) and the Session Initiation Protocol (SIP).  Similar
   mechanisms may also be re-used with the efforts around the Real-Time
   Communication in WEB-browsers, which is currently work in progress in
   the IETF and the W3C.

   For those cases where a protocol aims to exchange traffic between
   hosts where both sides are behind NATs or firewalls then a rendezvous
   mechanism and a mechanism for patch tests is needed.  Such a
   mechanism, however, also allows to determine when fewer protocol
   encapsulations can be used.

   To combat the ever increasing number of path candidates that have to



Tschofenig              Expires January 10, 2013                [Page 7]


Internet-Draft       The New Waist of the Hourglass            July 2012


   be tested for real-time applications a new protocol design practice
   had emerged: Instead of using separate port pairs for different media
   streams (e.g., streams for voice and video RTP traffic, feedback for
   RTP via RTCP, separate channel for signaling communication and inband
   communication, e.g., instant messaging, key exchange protocols)
   protocol architects design their protocols in such a way that they
   only use a small set of UDP/TCP port pairs and multiplex/demultiplex
   the application traffic at a higher layer.  This reduces the number
   of path candidates that have to be tested for e2e connectivity.

   This design trend can already be observed since a few years with
   examples being found with DTLS / SRTP.  RFC 5764 [RFC5764] and RFC
   5763 [RFC5763] describe the design and how to demultiplex arriving
   packets.  The level of multiplexing is astonishing:

   o  Symmetric RTP [RFC4961] is the case in which there are two RTP
      sessions that have their source and destination ports and
      addresses reversed.

   o  RTP and RTCP traffic is usually sent on two separate UDP ports.
      Two bidirectional DTLS-SRTP sessions are needed when symmetric RTP
      [RFC4961] is used: one for the RTP port, one for the RTCP port.

   o  RTP and RTCP traffic may also be multiplexed on a single UDP port
      [RFC5761].

   o  Finally, the DTLS, and the connectivity check packets using STUN
      also need to be multiplexed over the same port pair to accomplish
      best possible optimization.

   This improves the cryptographic performance of DTLS, but may cause
   problems when RTCP and RTP are subject to different network treatment
   (e.g., for bandwidth reservation).  Some organizations using SIP as
   part of their communication architecture have made assumptions about
   what network intermediaries can do in order to perform firewall
   pinholing and QoS treatment that may consequently not be compatible
   with this type of design anymore.  See
   [I-D.ietf-mmusic-media-path-middleboxes] for a discussion about
   middlebox behavior with SIP in context of media path security.












Tschofenig              Expires January 10, 2013                [Page 8]


Internet-Draft       The New Waist of the Hourglass            July 2012


5.  Will IPv6 reverse the shift?

   Will the IPv6 Internet share the same fate as the IPv4 Internet, and
   work only with UDP and TCP?  It seems likely that the answer will be
   yes.

   The primary reason is that the IPv6 Internet is not something that
   will appear overnight to replace the IPv4 Internet, as everyone had
   noticed by now already.  It will run alongside it for a very long
   time, if not forever.  Hosts that have connection to the IPv6
   Internet will find themselves frequently using IPv4 (in a dual- stack
   deployment), because the target host is available only on IPv4, or
   will find themselves communicating with via IPv6 to a v4-only host
   through NAT.  In both cases, any protocols except for UDP and TCP
   based protocols will not work.  And thus, the v6 host will need to
   utilize protocols that do work in all cases - ones based on UDP and
   TCP - rather than ones that work only in a few cases.  And so, when
   we eventually do cutover to IPv6 only, it will be with hosts which
   have, all along, only been running protocols that run on top of UDP
   or TCP.

   Another reason is that the IPv6 Internet will certainly be filled
   with firewalls, and if history is any guide for the future, only TCP
   and UDP are likely to work through such firewalls.

   Examples of such firewall guidance for IPv6 to mimic the security
   functionality of a NAT in IPv6 is given in RFC 4864 [RFC4864].

   Furthermore, (too) many efforts are currently ongoing to deal with
   the long transition period from IPv4 to IPv6 and these migration
   techniques introduce additional layers of NATs and tunneling that
   will lead to problems with bi-directional reachability.

   Finally, the IPv6 Internet is filled with NATs already anyway,
   despite attempts to provide ample address space.

   Consequently, for an application designers perspective, why build an
   application on top of a protocol which doesn't work on the IPv4
   Internet, and won't work on anything but a pure IPv6 network, when an
   application running on top of UDP or TCP will work everywhere?











Tschofenig              Expires January 10, 2013                [Page 9]


Internet-Draft       The New Waist of the Hourglass            July 2012


6.  The Rise of the Web

   The Web had enjoyed incredible success over the last 20 years and so
   it is not suprising that many application developers have used HTTP
   and HTTPS as the foundation for their application protocol design.
   The properties offered by HTTP, HTML, and JavaScript are often a good
   fit for many designs, and the familiarity of HTTP appeals to many
   developers.  With the intensive standardization efforts that happened
   over the last few years and the improvement in browser peformance Web
   applications today offer the same capabilities as native applications
   in almost all areas.  More guidance when HTTP usage is appropriate
   can be found in [I-D.tschofenig-http-design-guidance].

   Sometimes, however, the choice of HTTP is not entirely voluntarily.
   Certain networks, specifically enterprise networks, deploy aggressive
   packet filtering technology such that barely any traffic other than
   HTTP/HTTPS is allowed to bypass.  Whether this policy decision is
   based on a careful security evaluation, lack of awareness of other
   protocols, or too complex company-internal processes for interacting
   with the network administrator for updating packet filtering rules to
   allow new applications to traverse is difficult to say.

   In any case, for applications that are intented to be used in such
   environments any protocol other than HTTP (or even HTTPS) is less
   likely to function.  It is therefore not suprising that protocol
   designers are not willing to take the risk or put the additional
   complexity of supporting multiple transport mechanisms.
   Consequently, the perceived firewall traversal capability of HTTP/
   HTTPS has "convinced" many developers to use HTTP/HTTP as their
   protocol of choice.  As proxies that perform their policy at the HTTP
   layer become more common application developers will have to react
   again: an classical arms race.  Consequently, HTTPS becomes the only
   choice to prevent intermediaries from inspecting (and potentially
   modifying) application layer content.

   While many protocol designs use HTTP/HTTPS the Web is, however, much
   more.  In [I-D.tschofenig-post-standardization] we argue that the
   features provided by JavaScript, as used by many Web developments,
   have created another degree of sophistication that has helped to
   build a convenient platform for application development.  Especially
   for end-user facing applications the JavaScript-based Web platform
   has changed the standardization landscape and the work of protocol
   architects.








Tschofenig              Expires January 10, 2013               [Page 10]


Internet-Draft       The New Waist of the Hourglass            July 2012


7.  Community Input Needed

   The developments in the area of transport protocols have been
   recognized by the community for a couple of years now and NAT and
   firewall traversal techniques are taken into consideration in
   protocol designs..

   The author is, however, struggling with the question whether there is
   enough evidence to conclude that every protocol design today shall
   build on HTTP/HTTPS (rather than voluntarily using to use HTTP/HTTPS
   because of its properties).  This would lead to another shift in the
   IP hourglass model with HTTP/HTTPS being the new waist.

   At this point in time it may be premature to conclude that a
   mandatory HTTP/HTTPS based protocol design is indeed appropriate.

   Firewalling behavior certainly differs from environment to
   environment and not every Internet protocol is supposed to be
   deployed everywhere.  Some protocols are specifically focused on
   server-to-server communication or have historically been using a non-
   HTTP/HTTPS based design (e.g., routing protocols).

   The author is therefore seeking input and further research on this
   issue from the wider IETF and Internet community.

   A few publications exist, such as [IPoptions], [TCPextensions], and
   [HomeGateway], that illustrate the degree of filtering in networks
   used by end customers (e.g., home networks, hotspots, and ISP
   networks).  Note that enterprise networks are explicitly excluded
   since they are known to be challenging from filtering point of view
   and cannot serve as the basis for protocol design.  There are also
   projects ongoing that may build the foundation for additional
   insight, such as the 'Open Observatory for Network Interference'
   [OONI] or the Neubot project [Neubot].

   In any case, more data points are needed to offer a better snapshot
   of the current Internet deployment status.  It will help protocol
   developers to make informed decisions for their designs.













Tschofenig              Expires January 10, 2013               [Page 11]


Internet-Draft       The New Waist of the Hourglass            July 2012


8.  Security Considerations

   This document focuses on implications for protocol design and
   security protocols themselves are also impacted by the developments
   on the Internet caused by evolving behavior of network
   intermediaries.













































Tschofenig              Expires January 10, 2013               [Page 12]


Internet-Draft       The New Waist of the Hourglass            July 2012


9.  IANA Considerations

   This document does not require action by IANA.
















































Tschofenig              Expires January 10, 2013               [Page 13]


Internet-Draft       The New Waist of the Hourglass            July 2012


10.  Acknowledgements

   The author would like to thank Jonathan Rosenberg for his work on
   [I-D.rosenberg-internet-waist-hourglass].  This document re-uses text
   from his earlier work.














































Tschofenig              Expires January 10, 2013               [Page 14]


Internet-Draft       The New Waist of the Hourglass            July 2012


11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997.

11.2.  Informative References

   [RFC4487]  Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile
              IPv6 and Firewalls: Problem Statement", RFC 4487,
              May 2006.

   [I-D.tschofenig-post-standardization]
              Tschofenig, H., Aboba, B., Peterson, J., and D. McPherson,
              "Trends in Web Applications and the Implications on
              Standardization", draft-tschofenig-post-standardization-02
              (work in progress), May 2012.

   [I-D.rosenberg-internet-waist-hourglass]
              Rosenberg, J., "UDP and TCP as the New Waist of the
              Internet Hourglass",
              draft-rosenberg-internet-waist-hourglass-00 (work in
              progress), February 2008.

   [RFC4864]  Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
              E. Klein, "Local Network Protection for IPv6", RFC 4864,
              May 2007.

   [I-D.ietf-mmusic-media-path-middleboxes]
              Stucker, B., Tschofenig, H., and G. Salgueiro, "Analysis
              of Middlebox Interactions for Signaling Protocol
              Communication along the Media Path",
              draft-ietf-mmusic-media-path-middleboxes-04 (work in
              progress), January 2012.

   [RFC5761]  Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
              Control Packets on a Single Port", RFC 5761, April 2010.

   [RFC4961]  Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
              BCP 131, RFC 4961, July 2007.

   [RFC5764]  McGrew, D. and E. Rescorla, "Datagram Transport Layer
              Security (DTLS) Extension to Establish Keys for the Secure
              Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.

   [RFC5763]  Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
              for Establishing a Secure Real-time Transport Protocol



Tschofenig              Expires January 10, 2013               [Page 15]


Internet-Draft       The New Waist of the Hourglass            July 2012


              (SRTP) Security Context Using Datagram Transport Layer
              Security (DTLS)", RFC 5763, May 2010.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245,
              April 2010.

   [RFC5207]  Stiemerling, M., Quittek, J., and L. Eggert, "NAT and
              Firewall Traversal Issues of Host Identity Protocol (HIP)
              Communication", RFC 5207, April 2008.

   [I-D.ietf-tsvwg-sctp-udp-encaps]
              Tuexen, M. and R. Stewart, "UDP Encapsulation of SCTP
              Packets", draft-ietf-tsvwg-sctp-udp-encaps-04 (work in
              progress), July 2012.

   [RFC3724]  Kempf, J., Austein, R., and IAB, "The Rise of the Middle
              and the Future of End-to-End: Reflections on the Evolution
              of the Internet Architecture", RFC 3724, March 2004.

   [RFC3948]  Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
              Stenberg, "UDP Encapsulation of IPsec ESP Packets",
              RFC 3948, January 2005.

   [RFC3424]  Daigle, L. and IAB, "IAB Considerations for UNilateral
              Self-Address Fixing (UNSAF) Across Network Address
              Translation", RFC 3424, November 2002.

   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
              Discovery", RFC 4821, March 2007.

   [I-D.tschofenig-http-design-guidance]
              Tschofenig, H., Dusseault, L., Reschke, J., and M.
              Nottingham, "HTTP Protocol Design Guidelines", status:
               not yet published, July 2012.

   [Neubot]   Nexa Center for Internet & Society, "The Neubot Project",
              available at:  http://nexa.polito.it/neubot, 2012.

   [OONI]     The Tor Project, "OONI : Open Observatory of Network
              Interference", available at:  http://ooni.nu/, 2012.

   [HomeGateway]
              Eggert, L., "An experimental study of home gateway
              characteristics, In Proceedings of the '10th annual
              conference on Internet measurement'", 2010.




Tschofenig              Expires January 10, 2013               [Page 16]


Internet-Draft       The New Waist of the Hourglass            July 2012


   [TCPextensions]
              Honda, M., Nishida, Y., Greenhalgh, A., Handley, M., and
              H. Tokuda, "Is it Still Possible to Extend TCP? In Proc.
              ACM Internet Measurement Conference (IMC), Berlin,
              Germany", Nov 2011.

   [IPoptions]
              Fonseca, R., Porter, G., Katz, R., Shenker, S., and I.
              Stoica, "IP options are not an option, Technical Report
              UCB/EECS", 2005.









































Tschofenig              Expires January 10, 2013               [Page 17]


Internet-Draft       The New Waist of the Hourglass            July 2012


Author's Address

   Hannes Tschofenig
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  02600
   Finland

   Phone: +358 (50) 4871445
   Email: Hannes.Tschofenig@gmx.net
   URI:   http://www.tschofenig.priv.at








































Tschofenig              Expires January 10, 2013               [Page 18]