Subject: [tcpm] Another question about cubic

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 29 Sep 2016 08:13:13 +0200

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 29 Sep 2016 07:49:40 -0700

On 9/28/2016 11:13 PM, marcelo bagnulo braun wrote:
> couldnt find how is the packet loss detected i.e. via duplicated ACKs
> or via timeout. 

A duplicate ACK does not necessarily imply a loss - the Internet is not
guaranteed to avoid duplication.

Joe

---

From: David Borman <[email-masked]>
Date: Thu, 29 Sep 2016 10:05:59 -0500

> On Sep 29, 2016, at 9:49 AM, Joe Touch <[email-masked]> wrote:
> 

More commonly, reordering of packets will cause dup acks to be generated.
That’s why implementations require multiple duplicate ACKs before inferring
that there was a packet loss.
			-David Borman

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

---

From: marcelo bagnulo <[email-masked]>
Date: Thu, 29 Sep 2016 17:24:47 +0200

> guaranteed to avoid duplication.

:-)
I know that much.

Clearly, i failed to formulate my question properly. Let me try again.

RFC5681 defines two different behaviour when a "loss" is detected/inferred.

If the loss is detected by a timeout, the cwnd is set to 1 MSS

If the loss is detected via a number of dup ACKS, the cwnd is set to 
about half its value (omitting the specific details, can be found in 
fast retransmit and fast recovery, section 3.2 of RFC5681)

Now, draft-ietf-tcpm-cubic mentions generically a packet loss event 
(unless i missed something), so i was wondering if it means a packet 
loss detected by the means of dup acks or a packet loss detected by the 
means of a timeout.
I assume it is based on dup acks, but i couldnt find it stated 
explicitly. I understand the the reaction of a cubic sender to a timeout 
is still the same as the one described in rfc5681, i.e. cwnd is set to 1 
mss, but i wanted to confirm that (and possibly suggest that it should 
be mentioned explicitly in the document)

Hope this clarifies and apologies for the poorly phrased question before.
Regards, marcelo

---

From: Joe Touch <[email-masked]>
Date: Thu, 29 Sep 2016 09:59:35 -0700

> fast retransmit and fast recovery, section 3.2 of RFC5681)

This is part of the point, though - these two indications are not quite
the same, and might not be treated the same.

I appreciate your question, but I'm pointing out that there might be two
answers.

Joe

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 29 Sep 2016 19:21:10 +0200

> I appreciate your question, but I'm pointing out that there might be two

Right, agree and that i why i think that simply stating packet loss in 
the cubic draft without indicating how it is detected, may be less 
specified than what is needed.
So i think we are aligned.

---

From: Joe Touch <[email-masked]>
Date: Thu, 29 Sep 2016 11:38:06 -0700

> So i think we are aligned.

Agreed - a protocol should describe behaviors based on directly observed
events, not inferences.

I.e., it can say why three dupacks is treated as inferred loss, but it
needs to go back to the observable events.

Joe

---

From: Lisong Xu <[email-masked]>
Date: Fri, 30 Sep 2016 13:11:09 -0500

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:
> 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?
>

---

From: Yuchung Cheng <[email-masked]>
Date: Fri, 30 Sep 2016 12:22:15 -0700

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:
>> 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?
>>

---

From: Lisong Xu <[email-masked]>
Date: Fri, 30 Sep 2016 14:28:23 -0500

Hi Marcelo,

Please see my replies below. Thanks

> starts? i.e. slow start? It may be worthwhile stating this explicitly?

Yes, there is still the slow start phase.

> it reduces the window to 1 MSS and enters in slow start if the loss is 
Yes, it refers to a packet loss event inferred by dup acks. In this 
case, both the slow start threshold (ssthresh) and the congestion window 
set (cwnd) are set to cwnd*(1-beta), and then CUBIC increases cwnd 
according to a cubic function described in the draft.

In case of a timeout, ssthresh is set to cwnd*(1-beta), and cwnd is set 
to 1 (CUBIC does not change this value).

Thanks
Lisong

---

From: Yuchung Cheng <[email-masked]>
Date: Fri, 30 Sep 2016 15:31:22 -0700

btw, the emails of some authors are invalid. please update.

---------- Forwarded message ----------
From: Mail Delivery Subsystem <[email-masked]>
Date: Fri, Sep 30, 2016 at 12:23 PM
Subject: Returned mail: see transcript for details
To: [email-masked]

The original message was received at Fri, 30 Sep 2016 12:23:17 -0700 (PDT)
from vmwexchts01-prd.hq.netapp.com [10.122.105.12]

   ----- The following addresses had permanent fatal errors -----
"|/usr/local/bin/mreject srichard"
    (reason: 1)
    (expanded from: srichard)
"|/usr/local/bin/mreject alexandz"
    (reason: 1)
    (expanded from: alexandz)

   ----- Transcript of session follows -----
451 4.0.0 putbody: write error: Broken pipe
sh: /usr/local/bin/mreject: not found
554 5.3.0 unknown mailer error 1
sh: /usr/local/bin/mreject: not found
554 5.3.0 unknown mailer error 1

Final-Recipient: RFC822; [email-masked]
X-Actual-Recipient: X-Unix; |/usr/local/bin/mreject srichard
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Unix; 1
Last-Attempt-Date: Fri, 30 Sep 2016 12:23:17 -0700 (PDT)

Final-Recipient: RFC822; [email-masked]
X-Actual-Recipient: X-Unix; |/usr/local/bin/mreject alexandz
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Unix; 1
Last-Attempt-Date: Fri, 30 Sep 2016 12:23:17 -0700 (PDT)

---------- Forwarded message ----------
From: Yuchung Cheng <[email-masked]>
To: Lisong Xu <[email-masked]>
Cc: marcelo bagnulo braun <[email-masked]>, tcpm IETF list
<[email-masked]>, <[email-masked]>
Date: Fri, 30 Sep 2016 12:22:15 -0700
Subject: Re: [tcpm] Another question about cubic
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.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 30 Sep 2016 16:13:12 -0700

Hmm. a simple work around might be to not include draft-ietf-tcpm-cubic@
ietf.org for the time being and wait for updating authors' mail addresses
in a new version.
--
Yoshi

On Fri, Sep 30, 2016 at 3:31 PM, Yuchung Cheng <[email-masked]> wrote:

> or via

---

From: Lisong Xu <[email-masked]>
Date: Fri, 30 Sep 2016 22:00:31 -0500

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?

Thanks
Lisong