Re: [tcpm] AD Review of draft-ietf-tcpm-hystartplusplus-09

[[e-mail]]

> On 3. Sep 2022, at 00:52, Martin Duke <[e-mail]> wrote:
> 
> Thank you for this concise and very readable document.
> 
> My only major concern is the old subject of RFC3465 (ABC) being Informative, but a downref if we make it Normative. In my opinion, the document as written is not implementable without 3465 and it should be a normative reference.
> 
> If I am correct about the status quo, the only part of 3465 that is not in 5681 (and therefore still Experimental) is the use of L > 1 in slow start.
> 
> There are three approaches to handling this problem.
> 
> 1. Eliminate L from the spec, and use the RFC5681 slow start formula. What's bad about this is that IIUC we have no data with L=1. But we could say in Section 5 that the tests also used RFC 3465 with L=8 and the market decide what to do with that.
> 
> 2. Send to the RFC Editor with a normative reference; the doc will be "done", but will not publish until ABC goes to PS (which is not imminent, to say the least).
> 
> 3. What I think you've actually done here is standardized RFC3465 behavior only when combined with CSS (i.e. a partial promotion of ABC). I think this is the best course of action, but if we're going to do that, we should go all the way:
> 
> (a) Add a definition of L and a discussion of how to set it -- basically Sec 2.3 of RFC3465 but presumably with no L=2 limit. If we're going to publish a standard with a higher cap on L we really ought to have that discussion.
> 
> (b) It can "update" or "obsolete" 3465 depending on whether or not the WG cares to keep the experimental status of ABC-without-CSS.
> 
> The community apparently has consensus that L > 1, even L >  2, *in this context* is safe, so I don't see it as reckless to make this change.
> 
> I'm happy to have a dialogue about this.
Hi Martin,

I think the intention was (3), at least it was my intention.

What about only doing (a) by:

i) Remove
   The following pseudocode integrates Appropriate Byte Counting as
   described in [RFC3465].  In particular, see [RFC3465] for the
   definition of the variable L.
ii) After the first usage of L:
    Update the cwnd:
      cwnd = cwnd + min (N, L * SMSS)
    Add:
    The positive integer L SHOULD be 1 and MAY be larger than 1.
    See [RFC3465] for details of choosing L.

That way we are  consistent with RFC 5681 and allow for higher values.
The text in Section 5 gives a clear hint that L > 1 has been used.
At least we used the above text in RFC 9260.
We could also use
See [RFC3465] for a discussion related to the choice of the value of L.
or just leave out the reference to RFC3465 at all. I guess people are
setting L differently anyway.

What do you think?

Best regards
Michael
> 
> NITS:
> (3) s/definition/definitions
> 
> (4.1) "The Inter Packet Arrival algorithm does not perform well." If there's a useful citation here (or for the results discussed in Section 5) that would be nice to include.
> 
> (4.1) s/it's concluded that/the algorithm concludes
> 
> Thanks again!
> Martin