One document matched: draft-tschofenig-hourglass-00.xml
<?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 & 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>
| PAFTECH AB 2003-2026 | 2026-04-22 16:40:25 |