[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-jarvinen-tcpm-sack-recovery-entry) 00 01

Internet Engineering Task Force                              I. Jarvinen
INTERNET-DRAFT                                                   M. Kojo
draft-ietf-tcpm-sack-recovery-entry-00.txt        University of Helsinki
Intended status: Standards Track                         19 October 2009
Expires: April 2010



  Using TCP Selective Acknowledgement (SACK) Information to Determine
        Duplicate Acknowledgements for Loss Recovery Initiation


Status of this Memo

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

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.

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

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt.

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.

    This Internet-Draft will expire on April 2010.

Copyright Notice

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

    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents in effect on the date of
    publication of this document (http://trustee.ietf.org/license-info).
    Please review these documents carefully, as they describe your
    rights and restrictions with respect to this document.



Jarvinen/Kojo                                                   [Page 1]


INTERNET-DRAFT             Expires: April 2010              October 2009


Abstract

    This document describes a TCP sender algorithm to trigger loss
    recovery based on the TCP Selective Acknowledgement (SACK)
    information gathered on a SACK scoreboard instead of simply counting
    the number of arriving duplicate acknowledgements (ACKs) in the
    traditional way.  The given algorithm is more robust to ACK losses,
    ACK reordering, missed duplicate acknowledgements due to delayed
    acknowledgements, and extra duplicate acknowledgements due to
    duplicated segments and out-of-window segments. The algorithm allows
    not only a timely initiation of TCP loss recovery but also reduces
    false fast retransmits.  It has a low implementation cost on top of
    the SACK scoreboard defined in RFC 3517.






































Jarvinen/Kojo                                                   [Page 2]


INTERNET-DRAFT             Expires: April 2010              October 2009


                             Table of Contents

    1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   5
       1.1. Conventions and Terminology. . . . . . . . . . . . . . .   6
       1.2. Definitions. . . . . . . . . . . . . . . . . . . . . . .   6
    2. Algorithm Details . . . . . . . . . . . . . . . . . . . . . .   6
    3. Discussion. . . . . . . . . . . . . . . . . . . . . . . . . .   8
       3.1. Small Segment Sender . . . . . . . . . . . . . . . . . .   8
       3.2. One Segment is Small . . . . . . . . . . . . . . . . . .  10
       3.3. SACK Capability Misbehavior. . . . . . . . . . . . . . .  10
       3.4. Compatibility with Duplicate ACK based Loss
       Recovery Algorithms . . . . . . . . . . . . . . . . . . . . .  10
    4. Security Considerations . . . . . . . . . . . . . . . . . . .  10
    5. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
    6. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . .  11
    Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
    A. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . .  12
       A.1. Basic Case . . . . . . . . . . . . . . . . . . . . . . .  12
       A.2. Delayed ACK. . . . . . . . . . . . . . . . . . . . . . .  13
       A.3. ACK Losses . . . . . . . . . . . . . . . . . . . . . . .  14
       A.4. ACK Reordering . . . . . . . . . . . . . . . . . . . . .  14
       A.5. Packet Duplication . . . . . . . . . . . . . . . . . . .  15
       A.6. Mitigation of Blind Throughput Reduction
       Attack. . . . . . . . . . . . . . . . . . . . . . . . . . . .  15
    References . . . . . . . . . . . . . . . . . . . . . . . . . . .  16
    Normative References . . . . . . . . . . . . . . . . . . . . . .  16
    Informative References . . . . . . . . . . . . . . . . . . . . .  16
    AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . .  17























Jarvinen/Kojo                                                   [Page 3]


INTERNET-DRAFT             Expires: April 2010              October 2009


    TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION:

    Changes from draft-jarvinen-tcpm-sack-recovery-entry-01.txt

    * Clarified issues that based on feedback may cause confusion for
    the reader.

    * Incorporated handling of cumulative ACKs into the algorithm

    * 2581 refs -> 5681

    * Added early-rexmt ID as a related one, it uses SACK information
    similar to this algorithm (Thanks to Anna Brunstrom).

    * More cases added where this algorithm is beneficial in taking
    advantage of SACK block redundancy (thanks to Anna Brunstrom).

    * Discuss on differences how duplicate ACK counter is managed
    (traditional vs. this algorithm)

    * Added ref and couple of words about blind throughput reduction
    attack

    * Wrote SACK splitting attacks. These attacks are quite close to the
    edge in significance. Should consider just dropping (rather
    insignificant).

    Changes from draft-jarvinen-tcpm-sack-recovery-entry-00.txt

    * TODO items embedded: Improvements with window update, clarify
    dupack counting

    * Modified ACK reordering scenario in appendix, shows now a scenario
    where recovery is triggered in a more timely manner.

    * IDnits

    * Handle small segments case using duplicate ACKs counter paraller
    to the SACK blocks based detection.

    * Add a placeholder for SACK splitting

    * Mentioned FACK as some ideas are inherited from there

    END OF SECTION TO BE DELETED.






Jarvinen/Kojo                                                   [Page 4]


INTERNET-DRAFT             Expires: April 2010              October 2009


1.  Introduction

    The Transmission Control Protocol (TCP) [RFC793] has two methods for
    triggering retransmissions.  First, the TCP sender relies on
    incoming duplicate acknowledgements (ACKs) [RFC5681], indicating
    receipt of out-of-order segments at the TCP receiver. After
    receiving a required number of duplicate ACKs (usually three), the
    TCP sender retransmits the first unacknowledged segment and
    continues with a fast recovery algorithm such as Reno [RFC5681],
    NewReno [RFC3782] or SACK-based loss recovery [RFC3517].  Second,
    the TCP sender maintains a retransmission timer that triggers
    retransmission of segments, if the retransmission timer expires
    before the segments have been acknowledged.

    While the conservative loss recovery algorithm defined in [RFC3517]
    takes full advantage of SACK information during a loss recovery, it
    does not consider the very same information during the pre-recovery
    detection phase. Instead, it simply counts the number of arriving
    duplicate ACKs and leans on the number of duplicate ACKs in deciding
    when to enter loss recovery. However, this traditional heuristics of
    simply counting the number of duplicate ACKs to trigger a loss
    recovery fails in several cases to determine correctly the actual
    number of valid out-of-order segments the receiver has successfully
    received.  First, trusting on duplicate ACKs alone utterly fails to
    get hold of the whole picture in case of ACK losses and ACK
    reordering, resulting in delayed or missed initiation of fast
    retransmit and fast recovery. Similarly, the delayed ACK mechanism
    tends to conceal the first duplicate ACK as the delayed cumulative
    ACK becomes combined with the first duplicate ACK when the first
    out-of-order segment arrives at the receiver (in case of an enlarged
    ACK ratio such as with ACK congestion control [FARI08], even more
    significant portion is affected).  Second, segment duplication or
    out-of-window segments increase the risk of falsely triggering loss
    recovery as they trigger duplicate ACKs. At worst, this legitimate
    behavior on out-of-window segments can be turned into a blind
    throughput reduction attack [CPNI09].  Third, receiver window
    updates or opposite direction data segments cannot be counted as
    duplicate ACKs with the traditional approach but can still contain
    redundant SACK information that the sender could benefit from in a
    scenario where the actual duplicate ACKs where lost.

    The algorithm specified in this document uses TCP Selective
    Acknowledgement Option [RFC2018] to determine duplicate ACKs and to
    trigger loss recovery based on the information gathered on the SACK
    scoreboard [RFC3517]. It works in the pre-recovery state giving a
    more accurate heuristic for determining the number of out-of-order
    segments arrived at the TCP receiver.  The information gathered on
    the scoreboard reveals missing ACKs and allows detecting duplicate



Jarvinen/Kojo                                       Section 1.  [Page 5]


INTERNET-DRAFT             Expires: April 2010              October 2009


    events. Therefore, the algorithm enables a timely triggering of Fast
    Retransmit. In addition, it allows the use of Limited Transmit
    [RFC3042] regardless of lost ACKs and also in the cases where the
    SACK information is piggybacked to a cumulative ACK due to delayed
    ACKs.  This, in turn, allows keeping the ACK clock running more
    accurately.

    This algorithm is close to what Linux TCP implementation has used
    for a very long time when in conservative SACK mode. A similar
    approach is briefly mentioned along ACK congestion control [FARI08]
    but as the usefulness of the algorithm in this document is more
    general and not limited to ACK congestion control we specify it
    separately. We also note that the definition of a duplicate
    acknowledgement already suggests that an incoming ACK can be
    considered as a duplicate ACK if it "contains previously unknown
    SACK information" [RFC5681]. In addition, SACK information is used,
    whenever available, for similar purpose by Early Retransmit
    [AAA+09].

    This algorithm also resembles Forward Acknowledgement (FACK) [MM96]
    but they differ in how the quantity of data outstanding in the
    network is determined. FACK always assumes that every non-SACKed
    octet below the highest SACKed octet is lost which is only true if
    no reordering occurs. Thus it would simply trigger loss recovery
    whenever the highest SACKed octet is more than dupThresh segments
    above SND.UNA.


1.1.  Conventions and Terminology

    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 BCP 14, RFC 2119
    [RFC2119] and indicate requirement levels for protocols.


1.2.  Definitions

    The reader is expected to be familiar with the definitions given in
    [RFC5681], [RFC2018], and [RFC3517].


2.  Algorithm Details

    In order to use this algorithm, a TCP sender MUST have TCP Selective
    Acknowledgement Option [RFC2018] enabled and negotiated for the TCP
    connection. A TCP sender MUST maintain SACK information in an
    appropriate data structure such as scoreboard defined in [RFC3517].



Jarvinen/Kojo                                       Section 2.  [Page 6]


INTERNET-DRAFT             Expires: April 2010              October 2009


    This algorithm uses functions IsLost (SeqNum), Update(), and SetPipe
    () and variables DupThresh, HighData, HighRxt, Pipe, and
    RecoveryPoint, as defined in [RFC3517].

    A TCP sender using this algorithm MUST take following steps:

    1)  Upon the receipt of any ACK containing SACK information:

        If no previous loss event has occurred on the connection OR
        RecoveryPoint is less than SND.UNA (the oldest unacknowledged
        sequence number [RFC793]), continue with the other steps of this
        algorithm. Otherwise, continue the ongoing loss recovery.

    2)  Update the scoreboard via the Update () function as outlined in
        [RFC3517].

    3)  If ACK is a cumulative ACK, reset duplicate ACK counter to zero.

    4)  If ACK contains SACK blocks with previously unknown in-window
        (i.e., between SND.UNA and HighData, assuming SND.UNA has been
        updated from the acknowledgment number of the ACK) SACK
        information, increase duplicate ACK counter.

    5)  Determinate if a loss recovery should be initiated:

        If IsLost(SND.UNA) returns false AND the sender has received
        less than DupThresh duplicate ACKs, goto step 6A. Otherwise goto
        step 6B.

    6A) Invoke optional Limited Transmit:

        Set HighRxt to SND.UNA and run SetPipe(). The TCP sender MAY
        transmit previously unsent data segments according the
        guidelines of Limited Transmit [RFC3042], with the exception
        that the amount of octets that can be send is determined by Pipe
        and cwnd.

        If cwnd - pipe >= 1 SMSS, the TCP sender can transmit one or
        more segments as follows:

        Send Loop:

        a) If available unsent data exists and the receiver's advertised
           window allows, transmit one segment of up to SMSS octets of
           previously unsent data starting with sequence number
           HighData+1 and update HighData to reflect the transmission of
           the data segment. Otherwise, exit Send Loop.




Jarvinen/Kojo                                       Section 2.  [Page 7]


INTERNET-DRAFT             Expires: April 2010              October 2009


        b) Run SetPipe() to re-calculate the number of outstanding
           octets in the network. If cwnd - pipe >= 1 SMSS, go to step
           a) of Send Loop.  Otherwise, exit Send Loop.

    6B) Invoke Fast Retransmit and enter loss recovery:

        Initiate a loss recovery phase, per the fast retransmit
        algorithm outlined in [RFC5681] and continue with a fast
        recovery algorithm, such as the SACK-based loss recovery
        algorithm outlined in [RFC3517].


3.  Discussion

    In scenarios where no ACK losses nor reordering occur and the first
    acknowledgement with SACK information is not the ACK held due to
    delayed acknowledgements mechanism, the new SACK information with
    each duplicate ACK covers a single segment. In such a case, this
    algorithm will trigger loss recovery after three duplicate
    acknowledgements and will allow transmission of a single new segment
    using Limited Transmit on the first and second duplicate ACK. This
    is identical to the behavior that would occur without this algorithm
    (assuming DupThresh is 3 and that all segments are SMSS sized). This
    scenario together with other scenarios describing the behavior of
    the algorithm are depicted in Appendix A.

    This algorithm SHOULD be used also with an ACK that contains a
    window update or opposite direction data that could not be
    considered as a duplicate ACK in the traditional algorithm. Such
    behavior is safe because the SACK information can only add more
    information to the current state of the sender; at worst, all
    received information is just redundant.

    Setting HighRxt to SND.UNA in Step 6A has no direct relation to this
    algorithm. Yet it is included in the algorithm to avoid confusion in
    how to implement SetPipe() correctly because it depends on having a
    valid HighRxt value [RFC3517].


    A set of potential issues to consider with the algorithm are
    discussed in the following.


3.1.  Small Segment Sender

    If a TCP sender is sending small segments (usually intentionally
    overriding Nagle algorithm [RFC896]), the IsLost(SND.UNA) used in
    step 5 of the algorithm might fail to detect the need for loss



Jarvinen/Kojo                                     Section 3.1.  [Page 8]


INTERNET-DRAFT             Expires: April 2010              October 2009


    recovery on the third duplicate acknowledgement because not enough
    octets have been SACKed to cover DupThresh * SMSS bytes above
    SND.UNA.  Therefore, the traditional duplicate ACK algorithm is
    needed as a fallback. Steps 3, 4 and the latter condition of step 5
    implement the traditional algorithm in paraller to the SACK block
    based detection.

    The number of duplicate ACKs is an artificial metric to estimate the
    number of segments the receiver has already in its receive buffer.
    How accurately they match depends on the scenario. Because of that,
    the goal of the duplicate ACK counter included into this algorithm
    is not to achieve bug-to-bug compatibility with the plain duplicate
    ACK counter but to estimate how many out-of-order segments the
    receiver has already queued in a more accurate way. Therefore, the
    duplicate ACK counter used as a fallback mechanism in this algorithm
    differs from the plain duplicate ACK counter. However, such
    differences indicate a scenario where the plain counter was not able
    to accurately keep track of the receiver state.

    While the fallback algorithm itself does not look into
    acknowledgment field in order to make a decision whether ACK is a
    "duplicate ACK", the duplicate ACK counter is not renamed in this
    document as in practice most of ACKs that increment the counter
    would still contain a duplicate acknowledgment number.  In contrast
    to the traditional approach, only condition that must be satisfied
    to increment the duplicate ACK counter with this algorithm is that
    the acknowledgement MUST contain at least one in-window SACK block
    that covers octets that where not previously SACKed [RFC5681]. In
    cases with ACK losses or delayed ACKs this condition can also match
    to cumulative ACKs, receiver window updates and opposite direction
    data segments but still the counter can safely be incremented.

    Alternatively to the fallback algorithm, a TCP sender that is able
    to discern segment boundaries accurately can consider full segments
    in IsLost() regardless of segment size.  Therefore, such a TCP
    sender can avoid the problem with small segments using
    IsLost(SND.UNA) check alone which means that Steps 3, 4 and the
    latter condition of step 5 are redundant and do not have to be
    implemented.

    Note: the small segments problem is not unique to this algorithm but
    also the SACK-based loss recovery [RFC3517] encounters it because of
    how IsLost() is defined.








Jarvinen/Kojo                                     Section 3.1.  [Page 9]


INTERNET-DRAFT             Expires: April 2010              October 2009


3.2.  One Segment is Small

    A variant of small segment sender case is the case where only one of
    the SACKed segments is smaller than SMSS (possible even with Nagle
    enabled).  If TCP sender lacks ability to use the improved method by
    discerning segment boundaries but still wants robustness against ACK
    losses in this case, it MAY extend the condition in Step 5 with the
    test:

        SACKed octets > SMSS * (DupThresh - 1)


3.3.  SACK Capability Misbehavior

    If the receiver represents such a SACK misbehavior that it
    advertises SACK capability but never sends any SACK blocks when it
    should, this algorithm fails to enter loss recovery and
    retransmission timeout is required for recovery. However, such
    misbehavior does not allow SACK-based loss recovery [RFC3517] to
    work either, and a TCP sender will anyway require a timeout to
    recover.


3.4.  Compatibility with Duplicate ACK based Loss Recovery Algorithms

    This algorithm SHOULD NOT be used together with a fast recovery
    algorithm that determines the segments that have left the network
    based on the number of arriving duplicate acknowledgements (e.g.,
    NewReno [RFC3782]), instead of the actual segments reported by SACK.
    In presence of ACK reordering such an algorithm will count the
    delayed duplicate acknowledgements during the fast recovery
    algorithm as extra while determining the number of packets that have
    left the network.

    In general there should be very little reason to combine this
    algorithm with a loss recovery algorithm that is based on inferior,
    non-SACK based information only.


4.  Security Considerations

    A malicious TCP receiver may send false SACK information for
    sequence number ranges which it has not received in order to trigger
    Fast Retransmit sooner. Such behavior would only be useful when out-
    of-order segments have arrived because otherwise the flow undergoes
    a loss recovery with a window reduction. This kind of lying involves
    guessing which segments will arrive later. In case the guess was
    wrong, the performance of the flow is ruined because the TCP sender



Jarvinen/Kojo                                      Section 4.  [Page 10]


INTERNET-DRAFT             Expires: April 2010              October 2009


    will need a retransmission timeout as it will not retransmit the
    segments until it assumes SACK reneging. On a successful guess the
    attacker is able to trigger the recovery slightly earlier. The later
    segments would have allowed reporting the very same regions with
    SACK anyway. Therefore, the gain from this attack is small, hardly
    justifiable considering the drastic effect of a misguess. Also, a
    similar attack can be made with the duplicate acknowledgment based
    algorithm (even if the new SACK information rule is applied) by
    sending false duplicate acknowledgements with false SACK ranges, and
    trivially without the new SACK information rule.

    A variation of the lying attack discards reliability of the flow but
    as soon as the reliability is not a concern of the receiver, a
    number of simpler ways exist to attack TCP independently of this
    algorithm. Thus this algorithm is not considered to weaken TCP
    security properties against false information.

    Splitting SACK blocks into a smaller than the received segment sized
    chunks allows the receiver to enable recovery to start sooner
    because of IsLost() discontiguous check. However, by doing so the
    receiver neglects the possiblity of reordering for a little gain. If
    the segment was just reordered, the sender performs unnecessary
    window reduction and unnecessary retransmission of the reordered
    segment. Another variant of SACK block splitting simply tries to
    increase consumption of bandwidth but with small dupThresh value
    such as three the difference between sending three duplicate ACKs
    (traditional algorithm) and a single ACK with SACK blocks will not
    offer significant benefits to make such attack practical. In case
    the sender keeps track of segment boundaries and applies them in
    IsLost(), these attack will not succeed as the sender cannot be
    mislead to believe that a segment was split into multiple chunks.


5.  IANA Considerations

    This document has no actions for IANA.


6.  Acknowledgements

    The authors would like to thank Alexander Zimmermann and Anna
    Brunstrom for the comments on this document.


Appendix






Jarvinen/Kojo                                                  [Page 11]


INTERNET-DRAFT             Expires: April 2010              October 2009


A.  Scenarios


A.1.  Basic Case

    In this scenario no Delayed ACK, ACK losses, reordering or other
    "abnormal" behavior happens. For simplicity all the segments are
    SMSS sized.

    Once the TCP receiver gets first out-of-order segment, it sends a
    duplicate ACK with SACK information about the received octets. The
    following two out-of-order segments trigger a duplicate ACK each,
    with the corresponding range SACKed in addition to the previously
    know information. The sender gets those duplicate ACKs in-order,
    each of them will SACK a new previously unknown segment.

    This algorithm triggers loss recovery on third duplicate ACK because
    IsLost returns true as DupThresh * SMSS bytes became SACKed above
    the SND.UNA on the same acknowledgement, thus the behavior is
    identical to that of a sender which is using duplicate
    acknowledgments.  If Limited Transmit is in use, two first duplicate
    ACKs allow a single segment to be sent with either of the algorithms
    (Pipe is decremented by SMSS by the SACKed octets per ACK allowing
    SMSS worth of new octets).

        ACK           Transmitted    Received    ACK Sent
        Received      Segment        Segment     (Including SACK Blocks)

        1000
                      3000-3499      3000-3499   (delayed ACK)
                      3500-3999      3500-3999   4000
        2000
                      4000-4499      (dropped)
                      4500-4999      4500-4999   4000, SACK=4500-5000
        3000
                      5000-5499      5000-5499   4000, SACK=4500-5500
                      5500-5999      5500-5999   4000, SACK=4500-6000
        4000
                      6000-6499      6000-6499   4000, SACK=4500-6500
                      6500-6999      6500-6999   4000, SACK=4500-7000
        4000, SACK=4500-5000
                      7000-7499      7000-7499   4000, SACK=4500-7500
        4000, SACK=4500-5500
                      7500-7999      7500-7999   4000, SACK=4500-8000
        4000, SACK=4500-6000
                      4000-4499      4000-4499   8000
        4000, SACK=4500-6500




Jarvinen/Kojo                                    Section A.1.  [Page 12]


INTERNET-DRAFT             Expires: April 2010              October 2009


A.2.  Delayed ACK

    A basic case with delayed ACK send the first ACK with SACK
    information but since the previous ACK was sent with a lower
    sequence number because an acknowledgment is held by delayed ACK,
    the sender will not considered it as duplicate ACK. Because the
    segment contains SACK information that is identical to the basic
    case, the sender can use Limited Transmit with the same segments as
    in the basic case and will start loss recovery at the third
    acknowledgment, i.e., with the second duplicate acknowledgment. In
    the same situation the duplicate ACK based sender will have to wait
    for one more duplicate ACK to arrive to do the same as the first
    acknowledgment is fully "wasted".

    Technically an acknowledgement with a sequence number higher than
    what was previously acknowledged is not a duplicate acknowledgement
    but a presence of the SACK block tells another story revealing the
    receiver which used delayed ACK, and thus the missing duplicate
    acknowledgement in between. The response of a TCP sender taking
    advantage of such inferred duplicate acknowledgements is well within
    the guidelines of packet conservation principle [Jac88] as it still
    sends only when segments have left the network.

        ACK           Transmitted    Received    ACK Sent
        Received      Segment        Segment     (Including SACK Blocks)

        1500
                      3000-3499      3000-3499   3500
                      3500-3999      3500-3999   (delayed ACK)
        2500
                      4000-4499      (dropped)
                      4500-4999      4500-4999   4000, SACK=4500-5000
        3500
                      5000-5499      5000-5499   4000, SACK=4500-5500
                      5500-5999      5500-5999   4000, SACK=4500-6000
        4000, SACK=4500-5000
                      6000-6499      6000-6499   4000, SACK=4500-6500
                      6500-6999      6500-6999   4000, SACK=4500-7000
        4000, SACK=4500-5500
                      7000-7499      7000-7499   4000, SACK=4500-7500
        4000, SACK=4500-6000
                      4000-4499      4000-4499   7500
        4000, SACK=4500-6500








Jarvinen/Kojo                                    Section A.2.  [Page 13]


INTERNET-DRAFT             Expires: April 2010              October 2009


A.3.  ACK Losses

    This case with ACK loss shares much behavior with the case with
    delayed ACK. If hole at rcv.nxt is filled, the sender will notice
    that cumulative ACK advanced.  In case of out-of-order segments the
    first ACK which gets through to the sender includes SACK blocks up
    to the quantity the SACK block redundancy is able to cover.  With
    this algorithm the sender immediately takes use of all the
    information that is made available by the incoming ACK.

        ACK           Transmitted    Received    ACK Sent
        Received      Segment        Segment     (Including SACK Blocks)

        1000
                      3000-3499      3000-3499   (delayed ACK)
                      3500-3999      3500-3999   4000
        2000
                      4000-4499      (dropped)
                      4500-4999      4500-4999   4000, SACK=4500-5000
                                                 (dropped)
        3000
                      5000-5499      5000-5499   4000, SACK=4500-5500
                      5500-5999      5500-5999   4000, SACK=4500-6000
        4000
                      6000-6499      6000-6499   4000, SACK=4500-6500
                      6500-6999      6500-6999   4000, SACK=4500-7000
        4000, SACK=4500-5500 (two segments left the network)
                      7000-7499      7000-7499   4000, SACK=4500-7500
                      7500-7999      7500-7999   4000, SACK=4500-8000
        4000, SACK=4500-6000
                      4000-4499      4000-4499   8000
        4000, SACK=4500-6500


A.4.  ACK Reordering

    With ACK reordering an ACK is postponed.  Due to redundancy the next
    ACK after postponed one contains not only its own information but
    also the information of the reordered ACK (similar to the ACK losses
    case). Then when the reordered ACK arrives, the sender already knows
    about the information it provides and therefore no actions are taken
    with this algorithm.

        ACK           Transmitted    Received    ACK Sent
        Received      Segment        Segment     (Including SACK Blocks)

        1000
                      3000-3499      3000-3499   (delayed ACK)



Jarvinen/Kojo                                    Section A.4.  [Page 14]


INTERNET-DRAFT             Expires: April 2010              October 2009


                      3500-3999      3500-3999   4000
        2000
                      4000-4499      (dropped)
                      4500-4999      4500-4999   4000, SACK=4500-5000
                                                 (delayed)
        3000
                      5000-5499      5000-5499   4000, SACK=4500-5500
                      5500-5999      5500-5999   4000, SACK=4500-6000
        4000
                      6000-6499      6000-6499   4000, SACK=4500-6500
                      6500-6999      6500-6999   4000, SACK=4500-7000
        4000, SACK=4500-5500
                      7000-7499      7000-7499   4000, SACK=4500-7500
                      7500-7999      7500-7999   4000, SACK=4500-8000
        4000, SACK=4500-6000
                      4000-4499      4000-4499   8000
        4000, SACK=4500-5000 (has only redundant information)
        4000, SACK=4500-6500


A.5.  Packet Duplication

    Packet duplication happens either due to unnecessary retransmission
    or hardware duplication.  It adds a redundant ACK which has only
    redundant information or a data segment to the stream which will
    triggers a redundant duplicate ACK (possibly with SACK and/or DSACK
    [RFC2883] information).  Because neither adds any new SACKed octets
    at the sender, this algorithm will not do anything while duplicate
    ACK based receiver would falsely consider it as a duplicate ACK.

    If one of the redundant ACKs is lost, the effect of duplication is
    just negated.

    It is possible for the sender to detect this case using DSACK alone.


A.6.  Mitigation of Blind Throughput Reduction Attack

    In case an attacker knows or is able to guess 4-tuple of a TCP
    connection, it may apply a blind throughput reduction attack
    [CPNI09].  In this attack TCP is tricked to send duplicate ACK to
    the other endpoint using out-of-window segments which it is
    considerably easier to achieve than a match with sequence numbers.
    If more than dupThresh duplicate ACKs can be triggered in row
    without any legimate segment that advances acknowledged sequence
    number, the other end acts according that false congestion signal
    and halves the window.




Jarvinen/Kojo                                    Section A.6.  [Page 15]


INTERNET-DRAFT             Expires: April 2010              October 2009


    With this algorithm such duplicate ACKs are filtered because they do
    not have any new in-window SACK blocks (DSACK [RFC2883] might be
    present though).


References


Normative References


    [RFC793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, September 1981.

    [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow,
              "TCP Selective Acknowledgment Options", RFC 2018,
              October 1996.

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

    [RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing
              TCP's Loss Recovery Using Limited Transmit", RFC 3042,
              January 2001.

    [RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang,
              "A Conservative Selective Acknowledgment (SACK)-based
              Loss Recovery Algorithm for TCP", RFC 3517, April 2003.

    [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
              Control", RFC 5681, September 2009.


Informative References

    [AAA+09]  Allman, M., Avrachenkov, K., Ayesta, U., Blanton, J.,
              and P. Hurtig, "Early Retransmit for TCP and SCTP",
              Internet-Draft, draft-ietf-tcpm-early-rexmt-01, January
              2009.

    [CPNI09]  Security Assessment of the Transmission Control Protocol
              (TCP).  Available at:
              http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-
              TCP.pdf

    [FARI08]  Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding
              Acknowledgement Congestion Control to TCP",
              Internet-Draft, draft-floyd-tcpm-ackcc-06, July 2009.



Jarvinen/Kojo                                                  [Page 16]


INTERNET-DRAFT             Expires: April 2010              October 2009


    [Jac88]   Jacobson, V., "Congestion Avoidance and Control", In
              Proc. ACM SIGCOMM 88.

    [MM96]    M. Mathis, J. Mahdavi, "Forward Acknowledgment: Refining
              TCP Congestion Control," Proceedings of SIGCOMM'96, August
              1996, Stanford, CA.

    [RFC896]  Nagle, J., "Congestion Control in IP/TCP Internetworks",
              RFC 896, January 1984.

    [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An
              Extension to the Selective Acknowledgement (SACK) Option
              for TCP", RFC 2883, July 2000.

    [RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno
              Modification to TCP's Fast Recovery Algorithm", RFC 3782,
              April 2004.


AUTHORS' ADDRESSES


    Ilpo Jarvinen
    University of Helsinki
    P.O. Box 68
    FI-00014 UNIVERSITY OF HELSINKI
    Finland
    Email: ilpo.jarvinen@helsinki.fi

    Markku Kojo
    University of Helsinki
    P.O. Box 68
    FI-00014 UNIVERSITY OF HELSINKI
    Finland
    Email: kojo@cs.helsinki.fi
















Jarvinen/Kojo                                                  [Page 17]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/