RE: [PATCH net-next] TLP: Don't reschedule PTO when there's one outstanding TLP retransmission.

-----Original Message-----
From: Neal Cardwell [mailto:ncardwell@google.com]
Sent: Tuesday, July 25, 2017 9:30 PM
To: maowenan
Cc: Netdev; David Miller; weiyongjun (A); Chenweilong; Yuchung Cheng;
Nandita Dukkipati
Subject: Re: [PATCH net-next] TLP: Don't reschedule PTO when there's one
outstanding TLP retransmission.

On Tue, Jul 25, 2017 at 4:35 AM, Mao Wenan [off-list ref]
wrote:

quoted

If there is one TLP probe went out(TLP use the write_queue_tail packet
as TLP probe, we assume this first TLP probe named A), and this TLP
probe was not acked by receive side.

Then the transmit side sent the next two packetes out(named B,C), but
unfortunately these two packets are also not acked by receive side.

And then there is one data packet with ack_seq A arrive, in tcp_ack()
will call tcp_schedule_loss_probe() to rearm PTO, the handler
tcp_send_loss_probe() pass if(tp->tlp_high_seq)(because there is one
outstanding TLP named A,tp->tlp_high_seq is not zero), so the new TLP
probe can't be went out and need to rearm the RTO timer(timeout is
relative to the transmit time of the write queue head).

After this, another data packet with ack_seq A is received, if the
tlp_time_stamp is after rto_time_stamp, it will reset the TLP timeout
with delta value, which is before previous RTO timeout, so PTO is
rearm and previous RTO is cleared. This TLP probe also can't be sent
out because of tp->tlp_high_seq != 0, so there is no way(or need very
long time)to retransmit the packet because of TLP A is lost.

This fix is not to pass the if(tp->tlp_high_seq) in
tcp_schedule_loss_probe() when TLP PTO is after RTO, It is no need to
reschedule PTO when there is one outstanding TLP retransmission, so if
the TLP A is lost then RTO can retransmit that packet, and
tp->tlp_high_seq will be set to 0. After this TLP will go to the normal work

process.

quoted

Signed-off-by: Mao Wenan <redacted>

Thanks for posting this. This is a pretty involved scenario. To help
document/test precisely what the behavior is before and after your patch,
would you be able to post a packetdrill ( https://github.com/google/packetdrill )
test case for this scenario?

Can I ask if you saw this scenario in an actual trace, or noticed this by
inspection?

[Mao Wenan] It is my actual product scenario, from some debug trace info 
I found that PTO is always rescheduled before RTO, this is PTO is trigged 
by receiving one tcp_ack packets. After this patch, the product works well and 
there is no previous issue happen. The packet can retransmit with RTO if TLP probe 
is lost. 
I will say sorry that my local test can't reproduce because i can't build successfully the same 
complex scenario, I don't have mature test case to reproduce now but I will do my best to try
in local test environment. 
Thank you.

thanks,
neal