Subject: [tcpm] Partial ack during sack recovery

From: hiren panchasara <[email-masked]>
Date: Thu, 20 Oct 2016 14:29:10 -0700

Hi All,

In FreeBSD stack, we don't really let respective congestion control
algo decide the cwnd and ssthresh specially during loss.
I am attempting to fix it such that we really follow what the CC algo dictates.

For regular acks, in FreeBSD, we check for ABC/RFC3465 and let CC algo
know about the ack with bytes acked and it decides the cwnd.

I am not sure what's the correct way when a partial ack is received
within sack recovery period.

RFC6675 '5. Algorithm Details' has the section on if a packet is allowed
to be sent based on pipe and cwnd in this situation. (We, FreeBSD, don't
have full rfc implementation but I can see and add this case).

My question is, who should decide cwnd on such an ack and how? And the
guidance from RFC6675 (above) be followed after the cwnd is set?

May be I am missing something obvious. Thanks for your time.
Cheers,
Hiren

---

From: Yuchung Cheng <[email-masked]>
Date: Thu, 20 Oct 2016 17:52:41 -0700

RFC6675 section 5.

   (4) Invoke fast retransmit and enter loss recovery as follows:

       (4.1) RecoveryPoint = HighData

             When the TCP sender receives a cumulative ACK for this data
             octet, the loss recovery phase is terminated.

       (4.2) ssthresh = cwnd = (FlightSize / 2)

             The congestion window (cwnd) and slow start threshold
             (ssthresh) are reduced to half of FlightSize per [RFC5681
<https://tools.ietf.org/html/rfc5681>].
             Additionally, note that [RFC5681
<https://tools.ietf.org/html/rfc5681>] requires that any
             segments sent as part of the Limited Transmit mechanism not
             be counted in FlightSize for the purpose of the above
             equation.

AFAIU cwnd and ssthresh remain const during recovery. in other words,
during recovery you are sending 50% slower (than before recovery)

On Thu, Oct 20, 2016 at 2:29 PM, hiren panchasara <
[email-masked]> wrote:

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>
>