One document matched: draft-ietf-tcpm-rtorestart-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC1122 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1122.xml">
<!ENTITY RFC2018 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2018.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3042 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3042.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC4166 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4166.xml">
<!ENTITY RFC4653 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4653.xml">
<!ENTITY RFC4960 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml">
<!ENTITY RFC5681 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5681.xml">
<!ENTITY RFC5827 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5827.xml">
<!ENTITY RFC6298 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6298.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="no"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<rfc category="exp" docName="draft-ietf-tcpm-rtorestart-00" ipr="trust200902">
<!-- noModificationTrust200902 noDerivativesTrust200902 pre5378Trust200902">-->
<!-- updates="6298"> -->
<!-- ipr="full3978"> -->
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<!--<title abbrev="Abbreviated Title">TCP and SCTP RTO Management</title>-->
<title>TCP and SCTP RTO Restart</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Per Hurtig" initials="P.H." surname="Hurtig">
<organization>Karlstad University</organization>
<address>
<postal>
<street>Universitetsgatan 2</street>
<!-- Reorder these if your country does things differently -->
<code>651 88</code>
<city>Karlstad</city>
<region></region>
<country>Sweden</country>
</postal>
<phone>+46 54 700 23 35</phone>
<email>per.hurtig@kau.se</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Anna Brunstrom" initials="A.B." surname="Brunstrom">
<organization>Karlstad University</organization>
<address>
<postal>
<street>Universitetsgatan 2</street>
<!-- Reorder these if your country does things differently -->
<code>651 88</code>
<city>Karlstad</city>
<region></region>
<country>Sweden</country>
</postal>
<phone>+46 54 700 17 95</phone>
<email>anna.brunstrom@kau.se</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Andreas Petlund" initials="A.P." surname="Petlund">
<organization>Simula Research Laboratory AS</organization>
<address>
<postal>
<street>P.O. Box 134</street>
<!-- Reorder these if your country does things differently -->
<code>1325</code>
<city>Lysaker</city>
<region></region>
<country>Norway</country>
</postal>
<phone>+47 67 82 82 00</phone>
<email>apetlund@simula.no</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Michael Welzl" initials="M.W." surname="Welzl">
<organization>University of Oslo</organization>
<address>
<postal>
<street>PO Box 1080 Blindern</street>
<!-- Reorder these if your country does things differently -->
<code>N-0316</code>
<city>Oslo</city>
<region></region>
<country>Norway</country>
</postal>
<phone>+47 22 85 24 20</phone>
<email>michawe@ifi.uio.no</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="February" year="2013" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Transport</area>
<workgroup>TCP Maintenance and Minor Extensions (tcpm)</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>tcp</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document describes a modified algorithm for managing the TCP and SCTP retransmission timers that provides faster loss recovery when a connection's amount of outstanding data is small. The modification allows the transport to restart its retransmission timer more aggressively in situations where fast retransmit cannot be used. This enables faster loss detection and recovery for connections that are short-lived or application-limited.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor='sec-intro'>
<t>TCP uses two mechanisms to detect segment loss. First, if a segment is not acknowledged within a certain amount of time, a retransmission timeout (RTO) occurs, and the segment is retransmitted <xref target="RFC6298"/>. While the RTO is based on measured round-trip times (RTTs) between the sender and receiver, it also has a conservative lower bound of 1 second to ensure that delayed segments are not mistaken as lost. Second, when a sender receives duplicate acknowledgments, the fast retransmit algorithm infers segment loss and triggers a retransmission <xref target="RFC5681"/>. Duplicate acknowledgments are generated by a receiver when out-of-order segments arrive. As both segment loss and segment reordering cause out-of-order arrival, fast retransmit waits for three duplicate acknowledgments before considering the segment as lost. In some situations, however, the number of outstanding segments is not enough to trigger three duplicate acknowledgments, and the sender must rely on lengthy RTOs for loss recovery.</t>
<t>The amount of outstanding segments can be small for several reasons:
<list style="format (%d)">
<t>The connection is limited by the congestion control when the path has a low total capacity (bandwidth-delay product) or the connection's share of the capacity is small. It is also limited by the congestion control in the first RTTs of a connection or after an RTO when the available capacity is probed using slow-start.</t>
<t>The connection is limited by the receiver's available buffer space.</t>
<t>The connection is limited by the application if the available capacity of the path is not fully utilized (e.g. interactive applications), or at the end of a transfer, which is frequent if the total amount of data is small (e.g. web traffic).</t>
</list>
</t>
<t>The first two situations can occur for any flow, as external factors at the network and/or host level cause them. The third situation primarily affects flows that are short or have a low transmission rate. Typical examples of applications that produce short flows are web servers. <xref target="RJ10"/> shows that 70% of all web objects, found at the top 500 sites, are too small for fast retransmit to work. <xref target="BPS98"/> shows that about 56% of all retransmissions sent by a busy web server are sent after RTO expiry. While the experiments were not conducted using SACK <xref target="RFC2018"/>, only 4% of the RTO-based retransmissions could have been avoided. Applications have a low transmission rate when data is sent in response to actions, or as a reaction to real life events. Typical examples of such applications are stock trading systems, remote computer operations and online games. What is special about this class of applications is that they are time-dependant, and extra latency can reduce the application service level <xref target="P09"/>. Although such applications may represent a small amount of data sent on the network, a considerable number of flows have such properties and the importance of low latency is high.</t>
<t>The RTO restart approach outlined in this document makes the RTO slightly more aggressive when the number of outstanding segments is small, in an attempt to enable faster loss recovery for all segments while being robust to reordering. While it still conforms to the requirement in <xref target="RFC6298"/> that segments must not be retransmitted earlier than RTO seconds after their original transmission, it could increase the chance for a spurious timeout, which could degrade performance when the congestion window (cwnd) is large -- for example, when an application sends enough data to reach a cwnd covering 100 segments and then stops. The likelihood and potential impact of this problem as well as possible mitigation strategies are currently under investigation.</t>
<t>While this document focuses on TCP, the described changes are also valid for the Stream Control Transmission Protocol (SCTP) <xref target="RFC4960"/> which has similar loss recovery and congestion control algorithms.</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="RTO Restart Overview">
<t>The RTO management algorithm described in <xref target="RFC6298"/> recommends that the retransmission timer is restarted when an acknowledgment (ACK) that acknowledges new data is received and there is still outstanding data. The restart is conducted to guarantee that unacknowledged segments will be retransmitted after approximately RTO seconds. However, by restarting the timer on each incoming acknowledgment, retransmissions are not typically triggered RTO seconds after their previous transmission but rather RTO seconds after the last ACK arrived. The duration of this extra delay depends on several factors but is in most cases approximately one RTT. Hence, in most situations the time before a retransmission is triggered is equal to "RTO + RTT".</t>
<t>The extra delay can be significant, especially for applications that use a lower RTOmin than the standard of 1 second and/or in environments with high RTTs, e.g. mobile networks. The restart approach is illustrated in Figure 1 where a TCP sender transmits three segments to a receiver. The arrival of the first and second segment triggers a delayed ACK <xref target="RFC1122"/>, which restarts the RTO timer at the sender. The RTO restart is performed approximately one RTT after the transmission of the third segment. Thus, if the third segment is lost, as indicated in Figure 1, the effective loss detection time is "RTO + RTT" seconds. In some situations, the effective loss detection time becomes even longer. Consider a scenario where only two segments are outstanding. If the second segment is lost, the time to expire the delayed ACK timer will also be included in the effective loss detection time.</t>
<figure align="center">
<!--<preamble>Preamble</preamble>-->
<artwork align="center">
<![CDATA[
Sender Receiver
...
DATA [SEG 1] ----------------------> (ack delayed)
DATA [SEG 2] ----------------------> (send ack)
DATA [SEG 3] ----X /-------- ACK
(restart RTO) <----------/
...
(RTO expiry)
DATA [SEG 3] ---------------------->
]]>
</artwork>
<postamble>Figure 1: RTO restart example</postamble>
</figure>
<t>During normal TCP bulk transfer the current RTO restart approach is not a problem. Actually, as long as enough segments arrive at a receiver to enable fast retransmit, RTO-based loss recovery should be avoided. RTOs should only be used as a last resort, as they drastically lower the congestion window compared to fast retransmit, and the current approach can therefore be beneficial -- it is described in <xref target="EL04"/> to act as a "safety margin" that compensates for some of the problems that the authors have identified with the standard RTO calculation. Notably, the authors of <xref target="EL04"/> also state that "this safety margin does not exist for highly interactive applications where often only a single packet is in flight."</t>
<t>There are only a few situations where timeouts are appropriate, or the only choice. For example, if the network is severely congested and no segments arrive, RTO-based recovery should be used. In this situation, the time to recover from the loss(es) will not be the performance bottleneck. Furthermore, for connections that do not utilize enough capacity to enable fast retransmit, RTO is the only choice. The time needed for loss detection in such scenarios can become a serious performance bottleneck.</t>
</section>
<section title="RTO Restart Algorithm" anchor='sec-alg'>
<t>To enable faster loss recovery for connections that are unable to use fast retransmit, an alternative RTO restart can be used. By resetting the timer to "RTO - T_earliest", where T_earliest is the time elapsed since the earliest outstanding segment was transmitted, retransmissions will always occur after exactly RTO seconds. This approach makes the RTO more aggressive than the standardized approach in <xref target="RFC6298"/> but still conforms to the requirement in <xref target="RFC6298"/> that segments must not be retransmitted earlier than RTO seconds after their original transmission.</t>
<!-- MICHAEL: I have commented the next two sentences because they don't apply in Yuchung's case (RTO at the end of a large cwnd). ... Furthermore, the possible negative impacts of a more aggressive RTO are less severe when the amount of outstanding data is small. For example, if a spurious RTO is performed the resulting congestion window will not be smaller than if fast retransmit was used, as the window is already small.</t> -->
<!--For larger congestion windows the RTT sometimes increases within a congestion window, due to the increased queueing demand of the flow. Making the timer more aggressive could trigger spurious retransmissions in this situation. However, as the restart is only conducted for small congestion windows, it is less likely that such RTT fluctuations would occur.-->
<t>This document specifies the following update of step 5.3 in Section 5 of <xref target="RFC6298"/> (and a similar update in Section 6.3.2 of <xref target="RFC4960"/> for SCTP):</t>
<t><list style="hanging">
<t>When an ACK is received that acknowledges new data:
<list style="format (%d)">
<t>Set T_earliest = 0.</t>
<t>If the following two conditions hold:
<list style="format (%c)">
<t>The number of outstanding segments is less than four.</t>
<t>There is no unsent data ready for transmission or the receiver's advertised window does not permit transmission.</t>
</list>
set T_earliest to the time elapsed since the earliest outstanding segment was sent.
</t>
<t>Restart the retransmission timer so that it will expire after "RTO - T_earliest" seconds (for the current value of RTO).</t>
</list>
</t>
</list></t>
<t>The update requires TCP implementations to track the time elapsed since the transmission of the earliest outstanding segment (T_earliest). As the alternative restart is used only when the number of outstanding segments is less than four only four segments need to be tracked. Furthermore, some implementations of TCP (e.g. Linux TCP) already track the transmission times of all segments.</t>
</section>
<section title="Discussion">
<t>The currently standardized algorithm has been shown to add at least one RTT to the loss recovery process in TCP <xref target="LS00"/> and SCTP <xref target="HB08"/><xref target="PBP09"/>. Applications that have strict timing requirements (e.g. telephony signaling and gaming) rather than throughput requirements may want to use a lower RTOmin than the standard of 1 second <xref target="RFC4166"/>. For such applications the modified restart approach could be important as the RTT and also the delayed ACK timer of receivers will be large components of the effective loss recovery time. Measurements in <xref target="HB08"/> have shown that the total transfer time of a lost segment (including the original transmission time and the loss recovery time) can be reduced with up to 35% using the suggested approach. These results match those presented in <xref target="PGH06"/><xref target="PBP09"/>, where the modified restart approach is shown to significantly reduce retransmission latency.</t>
<t>There are several proposals that address the problem of not having enough ACKs for loss recovery. In what follows, we explain why the mechanism described here is complementary to these approaches:</t>
<t>The limited transmit mechanism <xref target="RFC3042"/> allows a TCP sender to transmit a previously unsent segment for each of the first two duplicate acknowledgments. By transmitting new segments, the sender attempts to generate additional duplicate acknowledgments to enable fast retransmit. However, limited transmit does not help if no previously unsent data is ready for transmission or if the receiver is out of buffer space. <xref target="RFC5827"/> specifies an early retransmit algorithm to enable fast loss recovery in such situations. By dynamically lowering the amount of duplicate acknowledgments needed for fast retransmit (dupthresh), based on the number of outstanding segments, a smaller number of duplicate acknowledgments are needed to trigger a retransmission. In some situations, however, the algorithm is of no use or might not work properly. First, if a single segment is outstanding, and lost, it is impossible to use early retransmit. Second, if ACKs are lost, the early retransmit cannot help. Third, if the network path reorders segments, the algorithm might cause more unnecessary retransmissions than fast retransmit.</t>
<t>Following the fast retransmit mechanism standardized in <xref target="RFC5681"/> this draft assumes a value of 3 for dupthresh. However, by considering a dynamic value for dupthresh a tighter integration with early retransmit (or other experimental algorithms) could also be possible.</t>
<t>Tail Loss Probe <xref target="TLP"/> is a proposal to send up to two "probe segments" when a timer fires which is set to a value smaller than the RTO. A "probe segment" is a new segment if new data is available, else a retransmission. The intention is to compensate for sluggish RTO behavior in situations where the RTO greatly exceeds the RTT, which, according to measurements reported in <xref target="TLP"/>, is not uncommon. The Probe timeout (PTO) is at least 2 RTTs, and only scheduled in case the RTO is farther than the PTO. A spurious PTO is less risky than a spurious RTO, as it would not have the same negative effects (clearing the scoreboard and restarting with slow-start). In contrast, RTO restart is trying to make the RTO more appropriate in cases where there is no need to be overly cautious.</t>
<t>TLP could kick in in situations where RTO restart does not apply, and it could overrule (yielding a similar general behavior, but with a lower timeout) RTO restart in cases where the number of outstanding segments is smaller than 4 and no new segments are available for transmission. The shorter RTO from RTO restart also reduces the probability that TLP is activated because PTO might be farther than RTO.</t>
</section>
<!-- <section anchor="Acknowledgements" title="Acknowledgements">
<t>Maybe Allman.</t>
</section>
-->
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document discusses a change in how to set the retransmission timer's value when restarted. This change does not raise any new security issues with TCP or SCTP.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC1122;
&RFC2018;
&RFC2119;
&RFC3042;
&RFC4166;
&RFC4960;
&RFC5681;
&RFC5827;
&RFC6298;
</references>
<references title="Informative References">
<reference anchor="LS00" target="">
<front>
<title>The Eifel retransmission timer</title>
<author initials="R.L." surname="Ludwig" fullname="Reiner Ludwig">
<organization>Ericsson Research, Germany</organization>
</author>
<author initials="K.S." surname="Sklower" fullname="Keith Sklower">
<organization>University of California at Berkeley, USA</organization>
</author>
<date month="July" year="2000"/>
</front>
<seriesInfo name="ACM" value="SIGCOMM Comput. Commun. Rev., 30(3)"/>
</reference>
<reference anchor="EL04" target="">
<front>
<title>The Peak-Hopper: A New End-to-End Retransmission Timer for Reliable Unicast Transport</title>
<author initials="H.E." surname="Ekstroem" fullname="Hannes Ekstroem">
<organization>Ericsson Research, Aachen, Germany</organization>
</author>
<author initials="R.L." surname="Ludwig" fullname="Reiner Ludwig">
<organization>Ericsson Research, Aachen, Germany</organization>
</author>
<date month="March" year="2004"/>
</front>
<seriesInfo name="IEEE" value="INFOCOM 2004"/>
</reference>
<reference anchor="PGH06" target="">
<front>
<title>Considerations of SCTP Retransmission Delays for Thin Streams</title>
<author initials="J.P." surname="Pedersen" fullname="Jon Pedersen">
<organization>Dept. of Informatics, University of Oslo, Norway</organization>
</author>
<author initials="C.G." surname="Griwodz" fullname="Carsten Griwodz">
<organization>Simula Research Laboratory, Oslo, Norway</organization>
</author>
<author initials="P.H." surname="Halvorsen" fullname="Pal Halvorsen">
<organization>Simula Research Laboratory, Oslo, Norway</organization>
</author>
<date month="November" year="2006"/>
</front>
<seriesInfo name="IEEE" value="LCN 2006"/>
</reference>
<reference anchor="RJ10" target="">
<front>
<title>Web metrics: Size and number of resources</title>
<author initials="S.R." surname="Ramachandran" fullname="Sreeram Ramachandran">
<organization>Google, USA</organization>
</author>
<date month="May" year="2010"/>
</front>
<seriesInfo name="Google" value="http://code.google.com/speed/articles/web-metrics.html"/>
</reference>
<reference anchor="HB08" target="">
<front>
<title>SCTP: designed for timely message delivery?</title>
<author initials="P.H." surname="Hurtig" fullname="Per Hurtig">
<organization>Karlstads Universitet, Sweden</organization>
</author>
<author initials="A.B." surname="Brunstrom" fullname="Anna Brunstrom">
<organization>Karlstads Universitet, Sweden</organization>
</author>
<date month="May" year="2010"/>
</front>
<seriesInfo name="Springer" value="Telecommunication Systems"/>
</reference>
<reference anchor="PBP09" target="">
<front>
<title>Improving SCTP Retransmission Delays for Time-Dependent Thin Streams</title>
<author initials="A.P." surname="Petlund" fullname="Andreas Petlund">
<organization>Simula Research Lab, Norway</organization>
</author>
<author initials="P.B." surname="Beskow" fullname="Paul Beskow">
<organization>Simula Research Lab, Norway</organization>
</author>
<author initials="J.P." surname="Pedersen" fullname="Jon Pedersen">
<organization>Simula Research Lab, Norway</organization>
</author>
<author initials="E.S.P." surname="Paaby" fullname="Espen Sogard Paaby">
<organization>Simula Research Lab, Norway</organization>
</author>
<author initials="C.G." surname="Griwodz" fullname="Carsten Griwodz">
<organization>Simula Research Lab, Norway</organization>
</author>
<author initials="P.H." surname="Halvorsen" fullname="Pal Halvorsen">
<organization>Simula Research Lab, Norway</organization>
</author>
<date year="2009"/>
</front>
<seriesInfo name="Springer" value="Multimedia Tools and Applications, 45(1-3)"/>
</reference>
<reference anchor="P09" target="">
<front>
<title>Improving latency for interactive, thin-stream applications over reliable transport</title>
<author initials="A.P." surname="Petlund" fullname="Andreas">
<organization>University of Oslo, Norway</organization>
</author>
<date month="Oct" year="2009"/>
</front>
<seriesInfo name="Unipub" value="PhD Thesis"/>
</reference>
<reference anchor="BPS98" target="">
<front>
<title>TCP Behavior of a Busy Web Server: Analysis and Improvements</title>
<author initials="H.B." surname="Balakrishnan" fullname="Hari Balakrishnan"></author>
<author initials="V.P." surname="Padmanabhan" fullname="Venkata Padmanabhan"></author>
<author initials="S.S." surname="Seshan" fullname="Srinivasan Seshan"></author>
<author initials="M.S." surname="Stemm" fullname="Mark Stemm"></author>
<author initials="R.K." surname="Katz" fullname="Randy Katz"></author>
<date month="March" year="1998"/>
<area>San Francisco, CA</area>
</front>
<seriesInfo name="Proc." value="IEEE INFOCOM Conf."/>
</reference>
<reference anchor="TLP" target="">
<front>
<title>TCP Loss Probe (TLP): An Algorithm for Fast Recovery of Tail Losses</title>
<author initials="N." surname="Dukkipati" fullname="N. Dukkipati"></author>
<author initials="N." surname="Cardwell" fullname="N. Cardwell"></author>
<author initials="Y." surname="Cheng" fullname="Y. Cheng"></author>
<author initials="M." surname="Mathis" fullname="M. Mathis"></author>
<date month="July" year="2012"/>
</front>
<seriesInfo name="Internet-draft" value="draft-dukkipati-tcpm-tcp-loss-probe-00.txt"/>
</reference>
</references>
<!--<section anchor="app-additional" title="Additional Stuff">
<t>This becomes an Appendix.</t>
</section>-->
<!-- Change Log
v00 2006-03-15 EBD Initial version
v01 2006-04-03 EBD Moved PI location back to position 1 -
v3.1 of XMLmind is better with them at this location.
v02 2007-03-07 AH removed extraneous nested_list attribute,
other minor corrections
v03 2007-03-09 EBD Added comments on null IANA sections and fixed heading capitalization.
Modified comments around figure to reflect non-implementation of
figure indent control. Put in reference using anchor="DOMINATION".
Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH Major changes: shortened discussion of PIs,
added discussion of rfc include.
v05 2007-03-10 EBD Added preamble to C program example to tell about ABNF and alternative
images. Removed meta-characters from comments (causes problems). -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:04:34 |