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

[[e-mail]]

> On 7. Sep 2022, at 21:40, Martin Duke <[e-mail]> wrote:
> 
> I would be happier with some sort of limit on L. Maybe: the positive integer L SHOULD be 2 and MUST be no more than 8(?) But whatever numbers the community is comfortable with are fine with me.
Hi Martin,

the crucial point here is that we know that MS used L = 8. But we don't have any information,
whether other values of L are worse or better, what the tradeoffs are and in particular
what traffic patterns impact the choice of L. Wouldn't we need such an analysis / results
from an experiment for selecting an upper limit L_MAX? I would assume that it might
have an impact whether pacing is used or not.
> 
> I'd also be happier with a cut-and-paste of those considerations from 3465, which should not be a lot of work.
> 
> The lower-effort approach is just to strike L from the document and let people do what they've doing, which is use Ls well in excess of 2. But I'd prefer we'd actually write it down because
> (1) our standards are better if they reflect widespread behavior in the internet; and
I agree with the above.
> (2) it means we can finally make 3465 historic, as we have standards-track documents that cover virtually all of its material.
> 
> If the community really cannot converge on sensible limits for L, then I'd rather publish with no L than wait for a deadlock to resolve.
In my view, the selection of L is not part of the core of the document.
> 
> But as a way forward, I'd suggest:
> 1) the authors propose text that sets bounds on L (a SHOULD and a MUST) and cut-and-pastes the considerations.
Aren't the consideration in RFC 3465 coming to the conclusion: L SHOULD be 1, MAY be 2, MUST NOT be larger than 2?
How to use the same considerations to come to a different conclusion: L SHOULD be 2, MUST NOT be larger than L_MAX
for L_MAX > 2?

Best regards
Michael (as an individual)
> 2) We do a consensus call on that in TCPM
> 
> if we have less than rough consensus, we can consider next steps.
> 
> 
> On Sat, Sep 3, 2022 at 2:50 AM <[e-mail]> wrote:
> > 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
>