Re: [Lsr] Zaheduzzaman Sarker's Discuss on draft-ietf-lsr-isis-fast-flooding-08: (with DISCUSS and COMMENT)

[Zaheduzzaman Sarker <[e-mail]>]

Apologies for late response, I was on PTO.
See reflections below.
//Zahed

On Tue, Apr 9, 2024 at 6:05 PM Les Ginsberg (ginsberg) <[e-mail]>
wrote:

> Zahed -
>
> First, thanx to John - his replies are on point and I agree with all of
> them.
>
> As I mentioned in a previous reply to John, my post was simply to get your
> agreement on the revised text for that section - it was not intended to
> address other editorial issues (such as revising related section names) -
> which we will certainly do when generating an updated version.
> A few more comments inline.
>
> > -----Original Message-----
> > From: John Scudder <[e-mail]>
> > Sent: Tuesday, April 9, 2024 8:28 AM
> > To: Zaheduzzaman Sarker <[e-mail]>
> > Cc: Les Ginsberg (ginsberg) <[e-mail]>; The IESG <
> [e-mail]>;
> > [e-mail]; [e-mail];
> [e-mail];
> > [e-mail]
> > Subject: Re: Zaheduzzaman Sarker's Discuss on
> draft-ietf-lsr-isis-fast-flooding-
> > 08: (with DISCUSS and COMMENT)
> >
> > Hi Zahed,
> >
> > I’m sure Les will reply as soon as his TZ allows him adequate
> caffeination :-). To
> > jump-start things, though, a couple questions/comments below.
> >
> > > On Apr 9, 2024, at 5:49 AM, Zaheduzzaman Sarker
> > <[e-mail]> wrote:
> > >
> > > Thanks for taking the stab, it is a good start but no quite there yet.
> > >
> > > - Now 6.3 and 6.3.2 has the same section title. I would rename section
> 6.3
> > to "Transmitter side congestion control considerations" and 6.3.2 to
> > "Guidelines for transmitter side congestion controls". Note that here
> > "transmitter side" congestion control would particularly mean that the
> > transmitter is in sole change of doing congestion congestion control
> based on
> > say - performance measurements of any sort.
> > > - Rest of changes looks good to me, however, I am not sure we should
> use
> > normative text to describe guidelines, unless we say those are
> requirements
> > and then perhaps also describe how one should fulfill those
> requirements. My
> > understanding is we don't want that sort of details here. I would
> recommend
> > to remove all the normative SHOULD and relay on implementer doing the
> right
> > thing. We are anyway not doing standard algorithm (s) and accepting
> > implementation details would vary.
> >
> > To be clear, your suggestion is s/SHOULD/should/ throughout the text Les
> > sent? IMO that would be fine, and would not make the document any less
> fit
> > for purpose. Once we have accepted that these are guidelines and not a
> > statement of an algorithm, it’s very difficult to insist that RFC 2119
> keywords
> > have much power, doubly so when all of them are SHOULD and not MUST.
> >
> > One possible counterargument is that SHOULD makes the document more
> > useful to the future implementor than “should”. I would (and did!) also
> accept
> > that position.
> >
> > In short, I don’t much care if the SHOULD is changed, or kept, and I
> hope the
> > parties to this discussion don’t either.
> >
> [LES:] I also am not heavily invested in SHOULD vs should - but as the
> section is advisory (which is why I changed MUST to SHOULD) it seemed like
> SHOULD was still appropriate.
> However, if you feel this distinction is important, we can certainly use
> lowercase.
> Please let us know.
>
My point is if this is completely advisory and not comprehensively
described, then lets not use normative text. Changing from MUST to SHOULD
is already an improvement, and as none of you feels strongly about
s/SHOULD/should then let do that.

>
> > > - I am expecting this document to call out the algorithm 1 as the only
> one it is
> > defining/describing and 6.3.2 are guidelines for other approaches when
> > Algorithm 1 is not feasible. This should be reflected in the document.
> >
> > I didn’t think "when Algorithm 1 is not feasible” was implicit in the
> document,
> > it was just “here are two approaches” with no editorializing about a
> preference
> > between the two. (I haven’t read it recently so I *could* be wrong, but
> that’s
> > how I recall it.)
> >
> > Assuming my recollection is right, I think it would be unwise to change
> the
> > document to state a preference.
> >
> [LES:] John is completely correct.
> The history of this document is that originally there were two competing
> drafts. Some folks thought that algorithm 1 was the best way forward and
> some that approach #2 was the best way forward.
> We eventually decided to write a single draft describing both solutions
> and allow the user community to decide what they wanted to use.
> My expectation is that we will see implementations of both - and whether
> one approach or the other dominates deployments will be based on deployment
> experience and vendor/operator preference.
> But it is certainly incorrect to think of approach #2 as only applicable
> when algorithm #1 is not feasible - that is not the intent of the draft.
>
> HTH clarify.
>

It would be great if we can clarify that in the document. Now, the read is
like we have issues with algorithm 1 when we have multiple queues and hence
we can't get the rwin correctly which is required for the flow control
described above. Thus, we have the guideline for designing another
congestion control algorithm. We can clearly say that we are defining one
algorithm and providing guideline for another algorithm which would be more
suitable for a particular architecture with multiple queues and those two
can be completely separate.

The current description also comes without saying if a flow control is
necessary for algorithm 2 or not. This need to be clarified too as we have
now clearly separated flow control and congestion control. And if flow
control is not a thing for algorithm 2, then lets clearly say that only
algorithm 1 will require the flow control defined in this document.


>
>    Les
>
>
> > Thanks,
> >
> > —John
>