<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="no" ?>
<?rfc subcompact="no" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC4487 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4487.xml">
<!ENTITY RFC5207 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5207.xml">
<!ENTITY RFC4864 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4864.xml">
<!ENTITY RFC5761 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5761.xml">
<!ENTITY RFC4961 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4961.xml">
<!ENTITY RFC5764 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5764.xml">
<!ENTITY RFC5763 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5763.xml">
<!ENTITY RFC5245 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5245.xml">
<!ENTITY RFC3724 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3724.xml">
<!ENTITY RFC3948 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3948.xml">
<!ENTITY RFC4821 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4821.xml">
<!ENTITY RFC3424 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3424.xml">
<!ENTITY I-D.ietf-tsvwg-sctp-udp-encaps SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tsvwg-sctp-udp-encaps.xml">
<!ENTITY I-D.tschofenig-post-standardization SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.tschofenig-post-standardization.xml">
<!ENTITY I-D.rosenberg-internet-waist-hourglass SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rosenberg-internet-waist-hourglass.xml">
<!ENTITY I-D.ietf-mmusic-media-path-middleboxes SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-media-path-middleboxes.xml">
]>
<rfc category="std" docName="draft-tschofenig-hourglass-00.txt" ipr="trust200902">
  <front>
    <title>The New Waist of the Hourglass</title>
 
    <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
      <organization>Nokia Siemens Networks</organization>
      <address>
        <postal>
          <street>Linnoitustie 6</street>
          <city>Espoo</city>
          <code>02600</code>
          <country>Finland</country>
        </postal>
        <phone>+358 (50) 4871445</phone>
        <email>Hannes.Tschofenig@gmx.net</email>
        <uri>http://www.tschofenig.priv.at</uri>
      </address>
    </author>
    <date year="2012"/>
    <keyword>Internet-Draft</keyword>
    <keyword>Internet Architecture</keyword>
    <keyword>Hourglass</keyword>

    <abstract>
			<t>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.</t>

<t>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.</t>

<t>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. </t>

  <t>This document is being discussed at https://www.ietf.org/mailman/listinfo/architecture-discuss</t>

    </abstract>
  </front>

  <middle>

  <!-- ////////////////////////////////////////////////////////////////////////////////// -->

    <section anchor="introduction" title="Introduction">
	
<t>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. </t>
   
<t>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.</t>

<t>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.</t>

<t>The "Everything over IP, and IP over everything" theme, as it is often described, 
   is shown graphically in <xref target="hourglass"/>.</t>

   <t>
      <figure title="The Original IP Hourglass" anchor="hourglass">
        <artwork xml:space="preserve">
          <![CDATA[
               +------+------+------+------+------+
               |Email | Web  | VoIP | P2P  | RTSP |
               +------+------+------+------+------+
                      | TCP  |  UDP | ICMP |
                      +------+------+------+
                             |  IP  |
                      +------+------+------+
                      |Ether |Sonet | ATM  |
               +------+------+------+------+------+
               |Fiber | TP   | CAT5 | WiFi | GSM  |
               +------+------+------+------+------+
]]></artwork>
      </figure>
      </t>  
	
<t>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).</t>
   
<t>Unfortunately, the various developments over the last years have changed this model. We will describe
   the developments below.</t>

</section>

  <!-- ////////////////////////////////////////////////////////////////////////////////// -->

<section anchor="nat" title="Network Address Translators">

<t>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.</t>

<t>   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.</t>

<t>   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. </t>

<t>   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 <xref target="RFC4821"/>.</t>

<t>   This means that the operation of the public Internet is dependent on
   the existence of UDP and TCP traffic. </t>
     
<t>   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.</t>

<t>   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 <xref target="RFC3424"/> the IAB 
   specifically addressed the problems created with NATs. </t>

</section> 

     <!-- ////////////////////////////////////////////////////////////////////////////////// -->

<section title="New Transport Protocols">

<t>   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 <xref target="nat"/> apply. </t>

<t>   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.</t>

<t>   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.</t>
   
<t>   Examples of where this has been done after the fact is
   <xref target="I-D.ietf-tsvwg-sctp-udp-encaps"/> for SCTP and <xref target="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.</t>

</section> 

     <!-- ////////////////////////////////////////////////////////////////////////////////// -->

	 
<section title="Firewalls">

<t>  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. </t>
   
<t>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.</t>
   
<t>   IETF protocol designers have already revised some protocols to handle stateful packet filtering
   firewalls. Examples can be found with RFC 4487 <xref target="RFC4487"/> and RFC 5207 <xref target="RFC5207"/>. </t> 
   
<t>  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. </t> 
      
<t>   One such path test mechanism is the Interactive Connectivity Establishment (ICE) protocol, 
   described in RFC 5245 <xref target="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. </t>

<t>   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. </t>

<t>   To combat the ever increasing number of path candidates that have to 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. </t>
   
<t>   This design trend can already be observed since a few years with examples being found with 
   DTLS / SRTP. RFC 5764 <xref target="RFC5764"/> and RFC 5763 <xref target="RFC5763"/> describe the design and how to demultiplex 
   arriving packets. The level of multiplexing is astonishing:

<list style="symbols">
<t>
Symmetric RTP <xref target="RFC4961"/> is the case in which there are two RTP
   sessions that have their source and destination ports and addresses
   reversed.</t>
   
<t>RTP and RTCP traffic is usually sent on two separate UDP ports.
   Two bidirectional DTLS-SRTP sessions
   are needed when symmetric RTP <xref target="RFC4961"/> is used: one for the RTP port, one for the RTCP port. 
</t>

<t>RTP and RTCP traffic may also be multiplexed on a single UDP port
   <xref target="RFC5761"/>.</t>

<t>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.   
</t>
</list> 

</t> 

<t>   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 <xref target="I-D.ietf-mmusic-media-path-middleboxes"/> for 
   a discussion about middlebox behavior with SIP in context of media path security. 
</t>  

</section> 

    <!-- ////////////////////////////////////////////////////////////////////////////////// -->

	
<section title="Will IPv6 reverse the shift?">

<t>
   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.
</t>

<t>
   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.</t>

<t>   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.</t>
   
<t>   Examples of such firewall guidance for IPv6 to mimic the security 
   functionality of a NAT in IPv6 is given in RFC 4864 <xref target="RFC4864"/>. </t>
   
<t>   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.</t>

<t>   Finally, the IPv6 Internet is filled with NATs already anyway, despite
   attempts to provide ample address space.</t>

<t>   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?</t>

</section> 

    <!-- ////////////////////////////////////////////////////////////////////////////////// -->

	
<section title="The Rise of the Web"> 

<t>   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 <xref target="I-D.tschofenig-http-design-guidance"/>. 
</t>
<t>   
   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.</t>
   
<t>   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. </t>
  
<t>   While many protocol designs use HTTP/HTTPS the Web is, however, much more. In 
   <xref target="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. </t>
   
</section> 

<section title="Community Input Needed"> 

<t>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..</t> 
 
<t>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. </t>
   
<t>At this point in time it may be premature to conclude that a mandatory HTTP/HTTPS
   based protocol design is indeed appropriate.  </t>
        
<t>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).</t>

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

<t>A few publications exist, such as <xref target="IPoptions"/>, <xref target="TCPextensions"/>, and <xref target="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' <xref target="OONI"/> or the Neubot project <xref target="Neubot"/>.</t>

<t>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. </t>

</section> 

    <!-- ////////////////////////////////////////////////////////////////////////////////// -->

    <section anchor="sec-cons" title="Security Considerations">
   
<t>   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.</t>

    </section> 

    <!-- ////////////////////////////////////////////////////////////////////////////////// -->
	
<section title="IANA Considerations">

<t>   This document does not require action by IANA. </t>

</section> 

    <!-- ////////////////////////////////////////////////////////////////////////////////// -->
   
<section title="Acknowledgements">
<t>
   The author would like to thank Jonathan Rosenberg for his work on <xref target="I-D.rosenberg-internet-waist-hourglass"/>. 
   This document re-uses text from his earlier work. 
</t>
</section> 

    <!-- ////////////////////////////////////////////////////////////////////////////////// -->
  </middle>

  <!-- ////////////////////////////////////////////////////////////////////////////////// -->

  <back>
    <references title="Normative References">
      <reference anchor="RFC2119">
        <front>
          <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
          <author fullname="Scott Bradner" initials="S." surname="Bradner">
            <organization>Harvard University</organization>
          </author>
          <date month="March" year="1997"/>
        </front>
        <format octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt" type="TXT"/>
      </reference>
       
       </references>

    <references title="Informative References">

&RFC4487;
&I-D.tschofenig-post-standardization;
&I-D.rosenberg-internet-waist-hourglass;
&RFC4864;
&I-D.ietf-mmusic-media-path-middleboxes;
&RFC5761;
&RFC4961; 
&RFC5764;
&RFC5763;
&RFC5245;
&RFC5207;
&I-D.ietf-tsvwg-sctp-udp-encaps;
&RFC3724; 
&RFC3948; 
&RFC3424;
&RFC4821;

<reference anchor="I-D.tschofenig-http-design-guidance">
        <front>
          <title>HTTP Protocol Design Guidelines</title>
          <author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
            <organization/>
          </author>

          <author fullname="Lisa Dusseault" initials="L." surname="Dusseault">
            <organization/>
          </author>

          <author fullname="Julian Reschke" initials="J." surname="Reschke">
            <organization/>
          </author>

          <author fullname="Mark Nottingham" initials="M." surname="Nottingham">
            <organization/>
          </author>
          
          <date month="July" year="2012"/>
        </front>
       <seriesInfo name="status: " value="not yet published"/>

      </reference>

	
	<reference anchor="Neubot">
        <front>
          <title>The Neubot Project</title>
            <author>
              <organization>Nexa Center for Internet &amp; Society</organization>
            </author>
          <date year="2012"/>
        </front>
        <seriesInfo name="available at: " value="http://nexa.polito.it/neubot"/>
        <format type='HTML'
        target='http://nexa.polito.it/neubot' />
      </reference>

	<reference anchor="OONI">
        <front>
          <title>OONI : Open Observatory of Network Interference </title>
            <author>
              <organization>The Tor Project</organization>
            </author>
          <date year="2012"/>
        </front>
        <seriesInfo name="available at: " value="http://ooni.nu/"/>
        <format type='HTML'
        target='http://ooni.nu/' />
      </reference>

	
	<reference anchor="HomeGateway">
        <front>
          <title>An experimental study of home gateway characteristics, In Proceedings of the '10th annual conference on Internet measurement'</title>
            <author initials="L." surname="Eggert" fullname="Lars Eggert">
              <organization/>
            </author>
          <date year="2010"/>
        </front>
        <format type='PDF'
        target='http://eggert.org/papers/2010-imc-hgw-study.pdf' />
      </reference>

      <reference anchor="TCPextensions">
        <front>
          <title>Is it Still Possible to Extend TCP? In Proc. ACM Internet Measurement Conference (IMC), Berlin, Germany</title>
            <author initials="M." surname="Honda" fullname="M. Honda">
              <organization/>
            </author>
            <author initials="Y." surname="Nishida" fullname="Y. Nishida">
              <organization/>
            </author>
            <author initials="A." surname="Greenhalgh" fullname="A. Greenhalgh">
              <organization/>
            </author>
            <author initials="M." surname="Handley" fullname="M. Handley">
              <organization/>
            </author>
            <author initials="H." surname="Tokuda" fullname="H. Tokuda">
              <organization/>
            </author>
          <date month="Nov" year="2011"/>
        </front>
        <format type='PDF'
        target='http://conferences.sigcomm.org/imc/2011/docs/p181.pdf' />
      </reference>
      


      <reference anchor="IPoptions">
        <front>
          <title>IP options are not an option, Technical Report UCB/EECS</title>
            <author initials="R." surname="Fonseca" fullname="R. Fonseca">
              <organization/>
            </author>
            <author initials="G." surname="Porter" fullname="G. Porter">
              <organization/>
            </author>
            <author initials="R." surname="Katz" fullname="R. Katz">
              <organization/>
            </author>
            <author initials="S." surname="Shenker" fullname="S. Shenker">
              <organization/>
            </author>
            <author initials="I." surname="Stoica" fullname="I. Stoica">
              <organization/>
            </author>
          <date year="2005"/>
        </front>
        <format type='HTML'
        target='http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.123.4251' />
      </reference>
      
    </references>
  </back>
</rfc>
