One document matched: draft-tuexen-tsvwg-sctp-multipath-02.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- $Id: draft-tuexen-tsvwg-multipath-sctp.xml,v 1.27 2010/12/27 19:25:03 tuexen Exp $ -->
<?rfc toc="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc strict="yes" ?>
<?rfc symrefs="yes" ?>
<rfc category="exp"
ipr="trust200902"
docName="draft-tuexen-tsvwg-sctp-multipath-02.txt">
<front>
<title abbrev="Loadsharing for SCTP">
Load Sharing for the Stream Control Transmission Protocol (SCTP)
</title>
<author initials="M." surname="Becke" fullname="Martin Becke">
<organization abbrev="University of Duisburg-Essen">
University of Duisburg-Essen,
Institute for Experimental Mathematics</organization>
<address>
<postal>
<street>Ellernstrasse 29</street>
<city>45326 Essen</city>
<region>Nordrhein-Westfalen</region>
<country>Germany</country>
</postal>
<phone>+49-201-183-7667</phone>
<facsimile>+49-201-183-7673</facsimile>
<email>martin.becke@uni-due.de</email>
</address>
</author>
<author initials="T." surname="Dreibholz" fullname="Thomas Dreibholz">
<organization abbrev="University of Duisburg-Essen">
University of Duisburg-Essen,
Institute for Experimental Mathematics</organization>
<address>
<postal>
<street>Ellernstrasse 29</street>
<city>45326 Essen</city>
<region>Nordrhein-Westfalen</region>
<country>Germany</country>
</postal>
<phone>+49-201-183-7637</phone>
<facsimile>+49-201-183-7673</facsimile>
<email>dreibh@iem.uni-due.de</email>
<uri>http://www.iem.uni-due.de/~dreibh/</uri>
</address>
</author>
<author initials="J." surname="Iyengar" fullname="Janardhan Iyengar">
<organization abbrev="Franklin and Marshall College">
Franklin and Marshall College,
Mathematics and Computer Science</organization>
<address>
<postal>
<street>PO Box 3003</street>
<city>Lancaster</city>
<region>Pennsylvania</region>
<code>17604-3003</code>
<country>USA</country>
</postal>
<phone>+1-717-358-4774</phone>
<email>jiyengar@fandm.edu</email>
<uri>http://www.fandm.edu/jiyengar/</uri>
</address>
</author>
<author initials="P." surname="Natarajan" fullname="Preethi Natarajan">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>425 East Tasman Drive</street>
<city>San Jose</city>
<region>California</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>prenatar@cisco.com</email>
</address>
</author>
<author initials="M." surname="Tuexen" fullname="Michael Tuexen">
<organization abbrev="Muenster Univ. of Applied Sciences">
Muenster University of Applied Sciences</organization>
<address>
<postal>
<street>Stegerwaldstrasse 39</street>
<city>48565 Steinfurt</city>
<country>Germany</country>
</postal>
<email>tuexen@fh-muenster.de</email>
</address>
</author>
<date day="3" month="July" year="2011"/>
<keyword>Internet-Draft</keyword>
<abstract>
<t>The Stream Control Transmission Protocol (SCTP) supports multi-homing for
providing network fault tolerance. However, mainly one path is used for data
transmission. Only timer-based retransmissions are carried over other paths
as well.</t>
<t>This document describes how multiple paths can be used simultaneously for
transmitting user messages.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>One of the important features of the Stream Control Transmission Protocol
(SCTP), which is currently specified in <xref target="RFC4960"/>, is network
fault tolerance. This feature is for example required for Reliable Server
Pooling (RSerPool, <xref target="RFC5351"/>). Therefore, transmitting
messages over multiple paths is supported, but only for redundancy. So
<xref target="RFC4960"/> does not specify how to use multiple paths
simultaneously.</t>
<t>This document overcomes this limitation by specifying how multiple paths
can be used simultaneously. This has several benefits:
<list style="symbols">
<t>Improved bandwidth usage.</t>
<t>Better availability check with real user messages compared to
HEARTBEAT-based information.</t>
</list></t>
</section>
<section title="Conventions" anchor="conv">
<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"/>.</t>
</section>
<section title="Load Sharing" anchor="CMT-SCTP">
<t>Basic requirement for applying SCTP load sharing is the Concurrent
Multipath Transfer (CMT) extension of SCTP, which utilises multiple
paths simultaneously. We denote CMT-enabled SCTP as CMT-SCTP throughout
this document. CMT-SCTP is introduced in <xref target="IAS06"/>
and in more detail in <xref target="I06"/>,
some illustrative examples of chunk handling are provided in
<xref target="DBP+10a"/>.
CMT-SCTP provides three modifications to standard SCTP (split Fast
Retransmissions, appropriate congestion window growth and delayed
SACKs), which are described in the following subsections.</t>
<section title="Split Fast Retransmissions" anchor="splitfastrtx">
<t>Paths with different latencies lead to overtaking of DATA chunks.
This leads to gap reports, which are handled by Fast Retransmissions.
However, due to the fact that multiple paths are used simultaneously,
these Fast Retransmissions are usually useless and furthermore lead to a
decreased congestion window size.</t>
<t>To avoid unnecessary Fast Retransmissions, the sender has to keep
track of the path each DATA chunk has been sent on and consider
transmission paths before performing Fast Retransmissions. That is, on
reception of a SACK, the sender MUST identify the highest acknowledged
TSN on each path. A chunk SHOULD only be considered as missing if its
TSN is smaller than the highest acknowledged TSN on its path. Section
3.1 of <xref target="DBP+10a"/> contains an illustrated example.</t>
</section>
<section title="Appropriate Congestion Window Growth" anchor="cwndupdate">
<t>The congestion window adaptation algorithm for SCTP <xref target="RFC4960"/>
allows increasing the congestion window only when a new cumulative ack (CumAck)
is received by a sender. When SACKs with unchanged CumAcks are generated (due to
reordering) and later arrive at a sender, the sender does not modify its
congestion window. Since a CMT-SCTP receiver naturally observes reordering, many
SACKs are sent containing new gap reports but not new CumAcks. When these gaps
are later acked by a new CumAck, congestion window growth occurs, but only for
the data newly acked in the most recent SACK. Data previously acked through gap
reports will not contribute to congestion window growth, in order to prevent
sudden increases in the congestion window resulting in bursts of data being
sent.</t>
<t>To overcome the problems described above, the congestion window growth has to
be handled as follows <xref target="IAS06"/>:
<list style="symbols">
<t>The sender SHOULD keep track of the earliest non-retransmitted outstanding
TSN per path.</t>
<t>The sender SHOULD keep track of the earliest retransmitted
outstanding TSN per path.</t>
<t>The in-order delivery per path SHOULD be deduced.</t>
<t>The congestion window of a path SHOULD be increased when the earliest
non-retransmitted outstanding TSN of this path is advanced
("Pseudo CumAck") OR when the earliest retransmitted outstanding TSN of this
path is advanced ("RTX Pseudo CumAck").</t>
</list>
</t>
<t>Section 3.2 of <xref target="DBP+10a"/> contains an illustrated
example of appropriate congestion window handling for CMT-SCTP.</t>
</section>
<section title="Appropriate Delayed Acknowledgements" anchor="delayedack">
<t>Standard SCTP <xref target="RFC4960"/> sends a SACK as soon as an
out-of-sequence TSN has been received. Delayed Acknowledgements are only
allowed if the received TSNs are in sequence. However, due to the load
balancing of CMT-SCTP, DATA chunks may overtake each other. This leads
to a high number of out-of-sequence TSNs, which have to be acknowledged
immediately. Clearly, this behaviour increases the overhead traffic
(usually nearly one SACK chunk for each received packet containing a
DATA chunk).</t>
<t>Delayed Acknowledgements for CMT-SCTP are handled as follows:
<list style="symbols">
<t>In addition to <xref target="RFC4960"/>, delaying of SACKs SHOULD
*also* be applied for out-of-sequence TSNs.</t>
<t>A receiver MUST maintain a counter for the number of DATA chunks
received before sending a SACK. The value of the counter is stored
into each SACK chunk (FIXME: add details; needs reservation of flags
bits by IANA). After transmitting a SACK, the counter MUST be reset
to 0. Its initial value MUST be 0.</t>
<t>The SACK handling procedure for a missing TSN M is extended as follows:
<list style="symbols">
<t>If all newly acknowledged TSNs have been transmitted
over the same path:
<list style="symbols">
<t>If there are newly acknowledged TSNs L and H so that L
‹= M ‹= H, the missing count of TSN M SHOULD
be incremented by one (like for standard SCTP according to
<xref target="RFC4960"/>).</t>
<t>Else if all newly acknowledged TSNs N satisfy the
condition M ‹= N, the missing count of TSN M SHOULD
be incremented by the number of TSNs reported in the SACK
chunk.</t>
</list></t>
<t>Otherwise (that is, there are newly acknowledged TSNs on
different paths), the missing count of TSN M SHOULD be
incremented by one (like for standard SCTP according to
<xref target="RFC4960"/>).</t>
</list>
</t>
</list>
</t>
<t>Section 3.3 of <xref target="DBP+10a"/> contains an illustrated
example of Delayed Acknowledgements for CMT-SCTP.</t>
</section>
</section>
<section title="Buffer Blocking Mitigation" anchor="blocking">
<t>TBD. See <xref target="ADB+11"/>, <xref target="DBR+10"/>.</t>
<section title="Sender Buffer Splitting"
anchor="sndbufsplitting">
<t>TBD. See <xref target="ADB+11"/>, <xref target="DBR+10"/>.</t>
</section>
<section title="Receiver Buffer Splitting"
anchor="rcvbufsplitting">
<t>TBD. See <xref target="ADB+11"/>, <xref target="DBR+10"/>.</t>
</section>
<!--
<section title="Chunk Rescheduling"
anchor="chrescheduling">
<t>This algorithm ensures quick blocking resolution for ordered data.
[TBD]. <xref target="DBR+10"/></t>
</section>
-->
<section title='Problems during Path Failure' anchor='pf'>
<t>This section discusses CMT's receive buffer related problems during
path failure, and proposes a solution for the same.</t>
<section title='Problem Description'>
<t> Link failures arise when a router or a link connecting two routers
fails due to link disconnection, hardware malfunction, or software
error. Overloaded links caused by flash crowds and denial-of-service
(DoS) attacks also degrade end-to-end communication between peer hosts.
Ideally, the routing system detects link failures, and in response,
reconfigures the routing tables and avoids routing traffic via the
failed link. However, existing research highlights problems with
Internet backbone routing that result in long route convergence times.
The pervasiveness of path failures motivated us to study their impact on
CMT, since CMT achieves better throughput via simultaneous data
transmission over multiple end-to-end paths.</t>
<t> CMT is an extension to SCTP, and therefore
retains SCTP's failure detection process. A CMT sender uses a tunable
failure detection threshold called Path.Max.Retrans (PMR). When a sender
experiences more than PMR consecutive timeouts while trying to reach an
active destination, the destination is marked as failed. With PMR=5, the
failure detection takes 6 consecutive timeouts or 63s. After every
timeout, the CMT sender continues to transmit new data on the failed
path increasing the chances of receive buffer (rbuf) blocking and
degrading CMT performance during permanent and short-term path failures
<xref target="NEA+08"/>.</t>
</section>
<section title='Solution: Potentially-failed Destination State'>
<t>To mitigate the rbuf blocking, we introduce a new destination state
called "potentially-failed" state in SCTP (and CMT's) failure detection
process <xref target="I-D.nishida-tsvwg-sctp-failover"/>.
This solution is based on the rationale that loss detected by a timeout
implies either severe congestion or failure en route.
After a single timeout on a path, a sender is unsure, and marks the
corresponding destination as "potentially-failed" (PF).
A PF destination is not used for data transmission or retransmission.
CMT's retransmission policies are augmented to include the PF state.
Performance evaluations prove that the PF state significantly reduces
rbuf blocking during failure detection <xref target="NEA+08"/>.</t>
</section>
</section>
<section title='Non-Renegable SACK' anchor='nrsack'>
<t> This section discusses problems with SCTP's SACK mechanism and how
it affects the send buffer and CMT performance.</t>
<section title='Problem Description'>
<t> Gap-acks acknowledge DATA chunks that arrive out-of-order to a
transport layer data receiver. A gap-ack in SCTP is advisory, in that,
while it notifies a data sender about the reception of indicated DATA
chunks, the data receiver is permitted to later discard DATA chunks that
it previously had gap-acked. Discarding a previously gap-acked DATA
chunk is known as "reneging". Because of the possibility of reneging in
SCTP, any gap-acked DATA chunk MUST NOT be removed from the data
sender's retransmission queue until the DATA chunk is later
CumAcked.</t>
<t>Situations exist when a data receiver knows that reneging on a
particular out-of-order DATA chunk will never take place, such as (but
not limited to) after an out-of-order DATA chunk is delivered to the
receiving application. With current SACKs in SCTP, it is not possible
for a data receiver to inform a data sender if or when a particular
out-of-order "deliverable" DATA chunk has been "delivered" to the
receiving application. Thus the data sender MUST keep a copy of every
gap-acked out-of-order DATA chunk(s) in the data sender's retransmission
queue until the DATA chunk is CumAcked. This use of the data sender's
retransmission queue is wasteful. The wasted buffer often degrades CMT
performance; the degradation increases when a CMT flow traverses via
paths with disparate end-to-end properties <xref target="NEY+08"/>.</t>
</section>
<section title='Solution: Non-Renegable SACKs'>
<t>Non-Renegable Selective Acknowledgments (NR-SACKs)
<xref target="I-D.natarajan-tsvwg-sctp-nrsack"/> are a new kind of
acknowledgements, extending SCTP's SACK chunk functionalities. The
NR-SACK chunk is an extension of the existing SACK chunk. Several fields
are identical, including the Cumulative TSN Ack, the Advertised Receiver
Window Credit (a_rwnd), and Duplicate TSNs. These fields have the same
semantics as described in <xref target="RFC4960"/>.</t>
<t>NR-SACKs also identify out-of-order DATA chunks that a receiver either:
(1) has delivered to its receiving application, or
(2) takes full responsibility to eventually deliver to its receiving application.
These out-of-order DATA chunks are "non-renegable."
Non-Renegable data are reported in the NR Gap Ack Block field of the
NR-SACK chunk as described <xref target="I-D.natarajan-tsvwg-sctp-nrsack"/>.
We refer to non-renegable selective acknowledgements as "nr-gap-acks."</t>
<t> When an out-of-order DATA chunk is nr-gap-acked, the data sender no
longer needs to keep that particular DATA chunk in its retransmission
queue, thus allowing the data sender to free up its buffer space sooner
than if the DATA chunk were only gap-acked. NR-SACKs improve send
buffer utilization and throughput for CMT flows
<xref target="NEY+08" />.</t>
</section>
</section>
</section>
<section title="Handling of Shared Bottlenecks" anchor="bottlenecks">
<section title="Introduction" anchor="rpintro">
<t>CMT-SCTP assumes all paths to be disjoint. Since each path
independently uses a TCP-like congestion control, an SCTP association
using N paths over the same bottleneck acquires N times the bandwidth of
a concurrent TCP flow. This is clearly unfair. A reliable detection of
shared bottlenecks is impossible in arbitrary networks like the
Internet. Therefore, <xref target="DBA+11"/>, <xref target="DBP+10b"/> apply the idea of
Resource Pooling to CMT-SCTP. Resource Pooling (RP) denotes "making a
collection of resources behave like a single pooled resource"
<xref target="WHB09"/>. The modifications of RP-enabled CMT-SCTP, further
denoted as CMT/RP-SCTP, are described in the following subsections.
A detailed description of CMT/RP-SCTP, including congestion control
examples, can be found in <xref target="DBA+11"/>, <xref target="DBP+10b"/>.</t>
</section>
<section title="Initial Values" anchor="rpinitial">
<t>TDB.</t>
</section>
<section title="Congestion Window Growth" anchor="rpcwndgrowth">
<t>TDB. See <xref target="DBA+11"/>.</t>
</section>
<section title="Congestion Window Decrease" anchor="rpcwnddecrease">
<t>TDB. See <xref target="DBA+11"/>.</t>
</section>
</section>
<section title="Chunk Scheduling" anchor="schedule">
<t>TDB. See <xref target="DST+10"/>.</t>
</section>
<section title="Application Programming Interface" anchor="API">
<t>
See <xref target="I-D.dreibholz-tsvwg-sctpsocket-multipath"/> and
<xref target="I-D.dreibholz-tsvwg-sctpsocket-sqinfo"/>.
</t>
</section>
<section title="IANA Considerations" anchor="IANA">
<!-- <t>This document requires no actions from IANA.</t> -->
<t>TBD.</t>
</section>
<section title="Security Considerations" anchor="sec">
<t>This document does not add any additional security considerations
in addition to the ones given in <xref target="RFC4960"/>.</t>
</section>
<!--
<section title="Acknowledgments"
anchor="acks">
<t>The authors wish to thank
*** and
***
for their invaluable comments.</t>
</section>
-->
<!--
<appendix title="Congestion Window Update Algorithm" anchor="CUCv2">
<t>
<figure>
<artwork>
...
</artwork>
</figure>
</t>
</appendix>
-->
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.4960"?>
<?rfc include="reference.RFC.5351"?>
<?rfc include="reference.I-D.nishida-tsvwg-sctp-failover"?>
<?rfc include="reference.I-D.natarajan-tsvwg-sctp-nrsack.xml"?>
<?rfc include="reference.I-D.dreibholz-tsvwg-sctpsocket-multipath"?>
<?rfc include="reference.I-D.dreibholz-tsvwg-sctpsocket-sqinfo"?>
</references>
<references title="Informative References">
<reference anchor="I06">
<front>
<title>End-to-End Concurrent Multipath Transfer Using Transport Layer Multihoming</title>
<author initials="J." surname="Iyengar" fullname="Janardhan Iyengar"/>
<date month="April" year="2006"/>
</front>
<seriesInfo name="PhD Dissertation" value="Computer Science Dept., University of Delaware"/>
<format type="PDF" target="http://web1.fandm.edu/jiyengar/papers/iyengar-dissertation.pdf"/>
</reference>
<reference anchor="IAS06">
<front>
<title>Concurrent Multipath Transfer Using SCTP Multihoming Over Independent End-to-End Paths</title>
<author initials="J." surname="Iyengar" fullname="Janardhan Iyengar"/>
<author initials="P. D." surname="Amer" fullname="Paul D. Amer"/>
<author initials="R. R." surname="Stewart" fullname="Randall R. Stewart"/>
<date month="October" year="2006"/>
</front>
<seriesInfo name="Journal" value="IEEE/ACM Transactions on Networking"/>
<format type="PDF" target="http://web1.fandm.edu/jiyengar/papers/cmt-ton2006.pdf"/>
</reference>
<reference anchor="NEA+08">
<front>
<title>Concurrent Multipath Transfer Using Transport Layer Multihoming: Introducing the Potentially-failed Destination State</title>
<author initials="P." surname="Natarajan" fullname="Preethi Natarajan"/>
<author initials="N." surname="Ekiz" fullname="Nasif Ekiz"/>
<author initials="J." surname="Iyengar" fullname="Janardhan Iyengar"/>
<author initials="P." surname="Amer" fullname="Paul Amer"/>
<author initials="R." surname="Stewart" fullname="Randall Stewart"/>
<date month="May" year="2008"/>
</front>
<seriesInfo name="Proceedings" value="of the IFIP Networking"/>
<format type="PDF" target="http://www.cis.udel.edu/~nataraja/papers/networking2008.pdf"/>
</reference>
<reference anchor="NEY+08">
<front>
<title>Non-Renegable Selective Acknowledgments (NR-SACKs) for SCTP</title>
<author initials="P." surname="Natarajan" fullname="Preethi Natarajan"/>
<author initials="N." surname="Ekiz" fullname="Nasif Ekiz"/>
<author initials="E." surname="Yilmaz" fullname="Ertugrul Yilmaz"/>
<author initials="P." surname="Amer" fullname="Paul Amer"/>
<author initials="J." surname="Iyengar" fullname="Janardhan Iyengar"/>
<author initials="R." surname="Stewart" fullname="Randall Stewart"/>
<date month="October" year="2008" />
</front>
<seriesInfo name="Proceedings" value="of the 16th IEEE International Conference on Network Protocols (ICNP)"/>
<format type="PDF" target="http://www.ieee-icnp.org/2008/papers/Index19.pdf"/>
</reference>
<reference anchor="WHB09">
<front>
<title>The Resource Pooling Principle</title>
<author initials="D." surname="Wischik" fullname="Damon Wischik"/>
<author initials="M." surname="Handley" fullname="Mark Handley"/>
<author initials="M. B." surname="Braun" fullname="Marcelo Bagnulo Braun"/>
<date month="October" year="2009"/>
</front>
<seriesInfo name="Journal" value="ACM SIGCOMM Computer Communication Review"/>
<format type="PDF" target="http://www.adastral.ucl.ac.uk/staff/M.Handley/papers/respool-ccr.pdf"/>
</reference>
<reference anchor="DBP+10a">
<front>
<title>Implementation and Evaluation of Concurrent Multipath Transfer for SCTP in the INET Framework</title>
<author initials="T." surname="Dreibholz" fullname="Thomas Dreibholz"/>
<author initials="M." surname="Becke" fullname="Martin Becke"/>
<author initials="J." surname="Pulinthanath" fullname="Jobin Pulinthanath"/>
<author initials="E.P." surname="Rathgeb" fullname="Erwin P. Rathgeb"/>
<date month="March" year="2010"/>
</front>
<seriesInfo name="Proceedings" value="of the 3rd ACM/ICST OMNeT++ Workshop"/>
<format
type="PDF"
target="http://www.tdr.wiwi.uni-due.de/fileadmin/fileupload/I-TDR/SCTP/Paper/OMNeT__Workshop2010-SCTP.pdf"/>
</reference>
<reference anchor="DBP+10b">
<front>
<title>Applying TCP-Friendly Congestion Control to Concurrent Multipath Transfer</title>
<author initials="T." surname="Dreibholz" fullname="Thomas Dreibholz"/>
<author initials="M." surname="Becke" fullname="Martin Becke"/>
<author initials="J." surname="Pulinthanath" fullname="Jobin Pulinthanath"/>
<author initials="E. P." surname="Rathgeb" fullname="Erwin P. Rathgeb"/>
<date month="April" year="2010" />
</front>
<seriesInfo name="Proceedings" value="of the IEEE 24th International Conference on Advanced Information Networking and Applications (AINA)"/>
<format type="PDF" target="http://www.tdr.wiwi.uni-due.de/fileadmin/fileupload/I-TDR/SCTP/Paper/AINA2010.pdf"/>
</reference>
<reference anchor="DBR+10">
<front>
<title>On the Use of Concurrent Multipath Transfer over Asymmetric Paths</title>
<author initials="T." surname="Dreibholz" fullname="Thomas Dreibholz" />
<author initials="M." surname="Becke" fullname="Martin Becke" />
<author initials="E. P." surname="Rathgeb" fullname="Erwin P. Rathgeb" />
<author initials="M." surname="Tuexen" fullname="Michael Tuexen" />
<date month="December" year="2010" />
</front>
<seriesInfo name="Proceedings" value="of the IEEE Global Communications Conference (GLOBECOM)"/>
<format type="PDF" target="http://www.tdr.wiwi.uni-due.de/fileadmin/fileupload/I-TDR/SCTP/Paper/Globecom2010.pdf"/>
</reference>
<reference anchor="DST+10">
<front>
<title>Transmission Scheduling Optimizations for Concurrent Multipath Transfer</title>
<author initials="T." surname="Dreibholz" fullname="Thomas Dreibholz" />
<author initials="R." surname="Seggelmann" fullname="Robin Seggelmann" />
<author initials="M." surname="Tuexen" fullname="Michael Tuexen" />
<author initials="E. P." surname="Rathgeb" fullname="Erwin P. Rathgeb" />
<date month="November" year="2010" />
</front>
<seriesInfo name="Proceedings" value="of the 8th International Workshop on Protocols for Future, Large-Scale and Diverse Network Transports (PFLDNeT) " />
<format type='PDF' target='http://www.tdr.wiwi.uni-due.de/fileadmin/fileupload/I-TDR/ReliableServer/Publications/PFLDNeT2010.pdf' />
</reference>
<reference anchor="ADB+11">
<front>
<title>Evaluation of Concurrent Multipath Transfer over Dissimilar Paths</title>
<author initials="H." surname="Adhari" fullname="Hakim Adhari" />
<author initials="T." surname="Dreibholz" fullname="Thomas Dreibholz" />
<author initials="M." surname="Becke" fullname="Martin Becke" />
<author initials="E. P." surname="Rathgeb" fullname="Erwin Paul Rathgeb" />
<author initials="M." surname="Tüxen" fullname="Michael Tüxen" />
<date month="March" year="2011" />
</front>
<seriesInfo name="Proceedings" value="of the 1st International Workshop on Protocols and Applications with Multi-Homing Support (PAMS)" />
<format type="PDF" octets="681374" target="http://www.tdr.wiwi.uni-due.de/fileadmin/fileupload/I-TDR/SCTP/Paper/PAMS2011.pdf" />
</reference>
<reference anchor="DBA+11">
<front>
<title>On the Impact of Congestion Control for Concurrent Multipath Transfer on the Transport Layer</title>
<author initials="T." surname="Dreibholz" fullname="T. Dreibholz" />
<author initials="M." surname="Becke" fullname="M. Becke" />
<author initials="H." surname="Adhari" fullname="H. Adhari" />
<author initials="E. P." surname="Rathgeb" fullname="E. P. Rathgeb" />
<date month="June" year="2011" />
</front>
<seriesInfo name="Proceedings" value="of the 11th IEEE International Conference on Telecommunications (ConTEL)" />
<format type="PDF" target="http://www.tdr.wiwi.uni-due.de/fileadmin/fileupload/I-TDR/SCTP/Paper/ConTEL2011.pdf" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:29:23 |