Re: [tcpm] Linux doesn’t implement RFC3465

[Mark Allman <[e-mail]>]

> If I understand the current document state correctly, the current ABC
> guidance we have is
>
> RFC3465 (Experimental): L=2
> RFC5681 (PS): L=1

Yep.

> 1. The most comprehensive solution would be a 3465bis PS doc that
>    obsoletes 3465 and updates 5681 with L= Infinity, 8, or
>    whatever number the group decides on. If we agree this is the
>    right thing to do and someone has the energy to drop
>    3465bis-00, then let's do so to have a basis of discussion.

Approach-wise this is OK.  But, there are issues here ...

  - First, we could probably move to L=2 pretty easily (as
    standard).  We have been using byte counting with standard
    delayed ACKs for a long time in stacks that do not use an L.
    So, we have effectively been living with this.

  - Moving to L > 2 (5, 10, \infinity) would seem to me to require
    someone to make the case that we have experience that suggests
    this is OK.  Or, that we have some suggestions that we could run
    at experimental L>2 for a while.  There have been a bunch of
    folks saying that we understand L > 2 works fine, but in pretty
    hand-wavy, mailing list sorts of ways.  I.e., there are stretch
    ACKs.  Or, there is an implementation with an L.  Or, there are
    offload systems that aggregate packets/ACKs.  When we haven't
    seen---that I am aware of---is a discussion that shows L
    > 2 is a good idea.  Or, that it isn't a bad idea.  It seems to
    me that the usual way these things get advanced is to offer some
    tangible / concrete assessment that says "hey, this is perhaps a
    reasonable thing to change".

  - I am not saying we shouldn't change L.  Perhaps we should.
    E.g., with pacing it seems like a no-brainer.  I am just saying
    that the case hasn't even been attempted.

> 3. There might be interest in a more generalized 5681bis, but my
>    instinct is that this is a bigger job that will delay the most
>    urgently needed update -- which is not to say that we shouldn't
>    do that document too.

I think a very scoped 5681bis could be done quickly.  If it is a
change to L and/or a change to IW we can use the 6298 model and make
the very tiny text change and add an appendix that justifies the
change.  So, the normative text of the RFC changes very little.

> 4. However, I don't think it would be too much of a stretch to rope in an
> IW update (6928bis) in 3465bis, if it doesn't add too much time. It all
> fits in with the general theme of the maximum allowable burst on the
> internet in the absence of any sort of pacing (ack-driven or
> stack-enforced).

Hm.  Well.  Hm.  I'd have to think about that one.  I do think that
just defining some general burst limit could prove to be thorny.
E.g., if you said the max burst size was 10 so IW=10 would be fine
then would a stretch ACK that covered 20 packets only be able to
liberate 10 packets?  Or, if we said a stretch ACK could liberate 20
packets would that imply an IW of 20 packets?  And, do we really
draw no distinction between what we can send into an unknown network
and what we can send into a network we have probed enough to have
some idea about?  This seems difficult.

allman