Re: [tcpm] A question about PTO/RTO rescheduling in RACK draft

[Neal Cardwell <[e-mail]>]

On Wed, Apr 17, 2019 at 5:15 PM hiren panchasara
<[e-mail]> wrote:
> I'll keep this to the point I thought got missed.
>
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rack-04.txt
>
> Is where we can see `Scheduling a loss probe` getting changed.
> Specifically, following condition has been removed from -04:
>
>    3.  The connection is either limited by congestion window (the data
>        in flight matches or exceeds the cwnd) or application-limited
>        (there is no unsent data that the receiver window allows to be
>        sent).
>
> And afaict, Linux code still has this condition in. If you can provide
> some rationale behind this change, it'd be great.

We removed the code for that condition from Linux around 2017-12-13,
in this commit (GPLv2 patch in this link):
  https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/net/ipv4/tcp_output.c?id=b4f70c3d4ec32a2ff4c62e1e2da0da5f55fe12bd

The commit description explains the rationale for removing that
condition, but here is a paraphrased description of the rationale for
removing that code and that condition in the draft:

---

Disallowing TLP when there is unused cwnd had the primary effect of
disallowing TLP when there is TSO deferral, Nagle deferral, or we hit
the receiver window limit. Why? Because basically every application
write() or incoming ACK will cause us to run the TCP transmit loop to
see if we can send more. And then if we sent something we then see if
we should schedule a TLP. At that point, there are a few common
reasons why some cwnd budget  could still be unused:

    (a) receiver window limits
    (b) Nagle deferral
    (c) TSO deferral (deferring with the hope of sending a bigger TSO
offload burst later)
    (d) intra-send-host flow control (in Linux, TCP small queues, aka TSQ)

For (d), after the next packet tx completion the TSQ mechanism will
allow us to send more packets, so we don't really need a TLP (in
practice it shouldn't matter whether we schedule one or not). But for
(a), (b), or (c) the sender won't send any more packets until it
receives another ACK. But if the whole flight of data was lost, or all
the ACKs for the flight were lost, then the sender won't get any more
ACKs, and so in this case ideally we should schedule and send a TLP to
get more feedback.

---

best,
neal