Re: [tcpm] TLP questions

[Neal Cardwell <[e-mail]>]

On Thu, May 10, 2018 at 7:08 PM Yoshifumi Nishida <[e-mail]>
wrote:

> Hi Neal,

> On Wed, May 9, 2018 at 1:27 PM, Neal Cardwell <[e-mail]>
wrote:
> > On Wed, May 9, 2018 at 2:29 PM Praveen Balasubramanian <
[e-mail]>
...
> >> “If a previously unsent segment exists AND
> >>
> >>          the receive window allows new data to be sent:
> >>
> >>            Transmit that new segment
> >>
> >>            FlightSize += SMSS
> >>
> >>        Else:
> >>
> >>            Retransmit the last segment”
> >>
> >> This needs to be crisper about what is meant by “previously unsent” and
> >> “last segment”. For example the sender could have sent a large amount
of
> >> data and then taken a full RTO. In this case if PTO fires, do
“previously
> >> unsent” and “last segment” refer to MSS size segments straddling just
before
> >> and  after SND.NXT? OR do they straddle around the largest sent
sequence
> >> number ever in the connection lifetime?
> >
> >
> > Very good questions. I like your suggestion to be crisper in this
section.
> > The Linux TCP stack does not "rewind" SND.NXT upon RTO, so in the Linux
TCP
> > stack the SND.NXT point and "largest sent sequence number ever in the
> > connection lifetime" are basically the same point. That is the
framework in
> > which we were thinking for those lines.
> >
> > In my mind...
> >
> > By "a previously unsent segment" we mean basically "the next segment
(of MSS
> > or fewer bytes) that the sender would normally send if it had available
cwnd
> > at this time." That is something that presumably every
production-quality
> > TCP stack has very quick access to.
> >
> > By "the last segment" we mean "the highest-sequence segment (of MSS or
fewer
> > bytes) that has already been transmitted and not ACKed or SACKed." I
imagine
> > this should also be generally very quick to access (at least it can be
> > quickly accessed in two generations of the Linux TCP write queue). Let
us
> > know if not, and we can discuss.
> >
> > Does that help clarify those parts? If so, we can update the text to
> > incorporate something like that (suggestions?).

> I am thinking that we can just say "send one (SMSS or smaller) segment
> that contains up to highest sequence number it has sent."
> I am a bit wondering if not ACKed or SACKed requirement should be
> mandatory, although it will be a bit redundant.

Yes, good point; the "not ACKed or SACKed" I added in my email message was
redundant.

So we could replace:
   "Retransmit the last segment"
with:
   "Retransmit the highest-sequence segment sent so far"

> > A sender should schedule a PTO only if all of the following conditions
are
> > met:
> >
> > The connection supports SACK [RFC2018]

> Do we need to check this? I mean RACK already presumes SACK nodes. I
> thought TLP does as well.
> Or, do we want to use TLP with non-SACK nodes?

Yes, both RACK and TLP require SACK. I agree that it could be considered
redundant to specify the SACK dependency in the TLP section, given that we
have already  mentioned in section "3. Requirements" that RACK depends on
SACK. But IMHO it is worthwhile to keep this dependency separately listed
here for TLP, to try to make it clear/explicit that the TLP algorithm has
its own dependency on SACK.

> > The connection has no SACKed sequences in the SACK scoreboard
> >
> > The connection is not in loss recovery
> >
> > The most recently transmitted data was not itself a TLP probe (i.e. a
sender
> > MUST NOT send consecutive or back-to-back TLP probes).

> I think the third condition might be a bit ambiguous and may require
> another variable. If we check TLPRtxOut and TLPHighRxt, might it be
> sufficient?

Yes, I agree this condition is not as clear as it should be. There are
really several considerations:

(a) we don't want an unterminating chain of TLPs, where after sending a TLP
probe we rearm the PTO timer and send another TLP

(b) we can't allow multiple outstanding TLP retransmissions

(Checking TLPRxtOut would cover (b) but not (a). And checking TLPRxtOut is
discussed elsewhere in the draft.)

The way the Linux TCP TLP code handles this as follows:

For (a), we ensure this structurally in the call sequence: after sending a
TLP probe, we rearm the RTO timer, not the TLP timer. This is already
discussed in the section "Phase 2: Sending a loss probe".

For (b), before sending a TLP retransmission we effectively check TLPRxtOut
and do not send a TLP at all if there is an outstanding TLP retransmission.
This is already discussed in "Recording loss probe states".

Given that those issues are already discussed elsewhere, I'd propose to
remove that line "The most recently transmitted data was not itself a TLP
probe (i.e. a sender MUST NOT send consecutive or back-to-back TLP
probes).". Instead in the -04 draft I'd propose we just add a brief note at
the end of the "Phase 2: Sending a loss probe" section:

   Note that after transmitting a TLP, the sender MUST arm an RTO timer,
   and not the PTO timer. This ensures that the sender does not send
repeated,
   back-to-back TLP probes.

Thank you, Yoshifumi!

neal