Subject: Re: [tcpm] Another question about cubic

From: Neal Cardwell <[email-masked]>
Date: Sat, 1 Oct 2016 16:12:30 -0400

On Fri, Sep 30, 2016 at 11:00 PM, Lisong Xu <[email-masked]> wrote:

> Hi Yuchung,
>
> A quick clarification about your example "3 packet drops in round trip 1
> plus 6
> packet drops in round trip 2 mean 2 loss events."
>
> If the 6 packet drops happen during the fast recovery of the 3 packet
> drops, TCP stays in the fast recovery until all lost packets are
> successfully recovered. In this case (assuming no retransmissions are
> lost), ssthresh is reduced only once, and there is only one loss event.
> Right?
>

If we're talking about the Linux implementation, then (sadly) I'm pretty
sure the answer is that it depends on the sequence number of the packets
lost in the second round. :-) If the losses in the second round are above
high_seq (high_seq = snd_nxt at the start of a recovery episode) then
tcp_fastretrans_alert() should finish the first recovery event and then
start a second recovery event (if tcp_time_to_recover() is true it will
fall through to  tcp_enter_recovery()). If the losses in the second round
(or further rounds) are all below high_seq then when all the holes are
filled and snd_una passes high_seq there should be no need for a second
recovery event.

IMHO this is a tricky problem with many specifications of loss-based
congestion control. On the one hand, if consecutive rounds with loss are
treated as a single recovery event and do not cut ssthresh again, then a
flow could be sending too fast and losing thousands of packets every round,
for an unbounded time. On the other hand, if consecutive rounds with loss
are *not* treated as a single recovery event, and instead are separate
recovery events with consecutive multiplicative reductions of ssthresh,
then throughput would quickly collapse into the ground in many situations.

So perhaps the Linux TCP stack is striking a reasonable balance in that
trade-off. I don't know what other TCP stacks do.

neal

>
> Thanks
> Lisong
>
>
>
> On 9/30/2016 2:22 PM, Yuchung Cheng wrote:
>
>> A small suggestion: the loss event may imply one single packet drop.
>> But AFAIK about Cubic, N>0 packet drops in one round trip is 1 loss
>> event, not N loss events. And 3 packet drops in round trip 1 plus 6
>> packet drops in round trip 2 mean 2 loss events. A fast recovery can
>> span across many round trips if retransmission is lost again.
>>
>> It might be worth clarifying that otherwise the (incorrect)
>> implementation will be a lot slower.
>>
>> On Fri, Sep 30, 2016 at 11:11 AM, Lisong Xu <[email-masked]> wrote:
>>
>>> Thanks, Marcelo!
>>>
>>> We will revise the draft to more clearly explain the protocol behavior
>>> according to your discussion with Joe yesterday.
>>>
>>> Thanks
>>>
>>> Lisong
>>>
>>>
>>>
>>> On 9/29/2016 1:13 AM, marcelo bagnulo braun wrote:
>>>
>>>> Hi,
>>>>
>>>> Does cubic assumes that there is a different phase when the connection
>>>> starts? i.e. slow start? It may be worthwhile stating this explicitly?
>>>>
>>>> In the current draft, it always reffers to a packet loss event, but I
>>>> couldnt find how is the packet loss detected i.e. via duplicated ACKs
>>>> or via
>>>> timeout. Is the reaction of cubic the same in both cases? Does it
>>>> reduces
>>>> the window to 1 MSS and enters in slow start if the loss is detected
>>>> via a
>>>> timeout?
>>>>
>>>> Sorry if this is already in the draft and i missed it.
>>>>
>>>> Regards, marcelo
>>>>
>>>>
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>
>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>
>>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Yuchung Cheng <[email-masked]>
Date: Sat, 1 Oct 2016 15:19:47 -0700

Thanks Neal on the detail of the Linux's approach, here is the standard way:

RFC5681, end of section 4.
""Loss in two successive windows of data, or the loss of a
   retransmission, should be taken as two indications of congestion and,
   therefore, cwnd (and ssthresh) MUST be lowered twice in this case."

If I understand the Cubic design correctly, the loss of a retransmission
in  subsequent rounds during fast recovery, should be treated as
additional loss events, because its design does not have recovery
state or open state. This matches the current draft as well.

On Sat, Oct 1, 2016 at 1:12 PM, Neal Cardwell <[email-masked]> wrote:
>> successfully recovered. In this case (assuming no retransmissions are lost),
>> ssthresh is reduced only once, and there is only one loss event. Right?
>
>
> start a second recovery event (if tcp_time_to_recover() is true it will fall
> through to  tcp_enter_recovery()). If the losses in the second round (or
> further rounds) are all below high_seq then when all the holes are filled
> and snd_una passes high_seq there should be no need for a second recovery
> event.
>
> recovery events with consecutive multiplicative reductions of ssthresh, then
> throughput would quickly collapse into the ground in many situations.
>

---

From: Lisong Xu <[email-masked]>
Date: Mon, 3 Oct 2016 14:16:26 -0500

Thanks, Neal and Yuchung.

Lisong

On 10/1/2016 3:12 PM, Neal Cardwell wrote:
> On Fri, Sep 30, 2016 at 11:00 PM, Lisong Xu <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Yuchung,
>
>     A quick clarification about your example "3 packet drops in round
>     trip 1 plus 6
>     If the 6 packet drops happen during the fast recovery of the 3
>     packet drops, TCP stays in the fast recovery until all lost
>     packets are successfully recovered. In this case (assuming no
>     retransmissions are lost), ssthresh is reduced only once, and
>     there is only one loss event. Right?
>
>
> If we're talking about the Linux implementation, then (sadly) I'm 
> pretty sure the answer is that it depends on the sequence number of 
> the packets lost in the second round. :-) If the losses in the second 
> round are above high_seq (high_seq = snd_nxt at the start of a 
> recovery episode) then tcp_fastretrans_alert() should finish the first 
> recovery event and then start a second recovery event (if 
> tcp_time_to_recover() is true it will fall through to 
>  tcp_enter_recovery()). If the losses in the second round (or further 
> rounds) are all below high_seq then when all the holes are filled and 
> snd_una passes high_seq there should be no need for a second recovery 
> event.
>
> congestion control. On the one hand, if consecutive rounds with loss 
> are treated as a single recovery event and do not cut ssthresh again, 
> then a flow could be sending too fast and losing thousands of packets 
> every round, for an unbounded time. On the other hand, if consecutive 
> rounds with loss are *not* treated as a single recovery event, and 
> instead are separate recovery events with consecutive multiplicative 
> reductions of ssthresh, then throughput would quickly collapse into 
> the ground in many situations.
>
> So perhaps the Linux TCP stack is striking a reasonable balance in 
> that trade-off. I don't know what other TCP stacks do.
>
> neal
>
>
>     Thanks
>     Lisong
>
>
>
>         On Fri, Sep 30, 2016 at 11:11 AM, Lisong Xu <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>             Thanks, Marcelo!
>
>                 couldnt find how is the packet loss detected i.e. via
>                 duplicated ACKs or via
>                 timeout. Is the reaction of cubic the same in both
>                 cases? Does it reduces
>                 the window to 1 MSS and enters in slow start if the
>                 loss is detected via a
>                 timeout?
>
>                 [email-masked] <mailto:[email-masked]>
>                 <https://www.ietf.org/mailman/listinfo/tcpm>
>
>
>             [email-masked] <mailto:[email-masked]>
>             <https://www.ietf.org/mailman/listinfo/tcpm>
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/tcpm>
>
>