Re: [tcpm] Linux doesn’t implement RFC3465

[Mark Allman <[e-mail]>]

I just inhaled notes from Vidhi, Yuchung and Neal.  And, I am trying
to page the recesses of my brain back in ... :-)

I have a few thoughts ...

  - I sort of agree with Yuchung & Neal in spirit, if not
    particulars.

  - During the initial slow start phase I think it'd be fine to say
    either:

    (a) If you use some sort of burst mitigator/pacing, an
        implementation can increase cwnd by the number of bytes
        ACKed on each ACK (i.e., no L).

    (b) If there is no burst mitigation then we have to figure out
        if L is still useful for this purpose and whether we want to
        retain it.  Seems like perhaps L=2 is sensible here.  L was
        never meant to be some general burst mitigator.  However,
        ABC clearly *can* aggravate bursting and so perhaps it makes
        sense to have it also try to limit the impact of the
        aggravation (in the absence of some general mechanism).

  - During slow starts that follow RTOs there is a general problem
    that just because the window slides by X bytes doesn't say
    anything about the *network*, as that sliding can happen because
    much of the data was likely queued for the application on the
    receiver.  So, e.g., you can RTO and send one packet and get an
    ACK back that slides the window 10 packets.  That doesn't mean
    10 packets left.  It means one packet left the network and nine
    packets are eligible to be sent to the application.  So, it is
    not OK to set the cwnd to 1+10 = 11 packets in response to this
    ACK.  Here L should exist and be 1.

  - It is possible that someone could work out a SACK-based scheme
    to try to figure out how much of the ACK is data leaving the
    network and how much of it was data sitting in the buffer at the
    receiver.  And, if we could do that then we could say "L=1
    unless you use a fancy algorithm".  My guess, however, is this
    is likely a fool's errand for two reasons.  First, on an RTO the
    scoreboard is supposed to be cleared and while SACK information
    will slowly get built back up we lose a bunch of state that we
    could perhaps use to differentiate between "left network" and
    "left buffer".  Second, receivers are supposed to ACK out of
    order segments and those that fill in holes immediately.  If
    they do that, it means that every ACK received actually does
    convey one segment leaving the network and therefore L=1 is
    correct and even an accurate SACK-based algorithm wouldn't let
    one increase cwnd more than L=1 would.  (One caveat here is I am
    not sure how this thinking would play with the offload stuff.)

allman