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

["Les Ginsberg (ginsberg)" <[e-mail]>]

Zahed –

Just a heads up – both Bruno and I will be away next week (for unrelated reasons 😊)  – so there will be some delay in responses and likely an updated version won’t be available until after we return.
Thanx for your patience.

Some responses inline. Look for LES2:

From: Zaheduzzaman Sarker <[e-mail]>
Sent: Thursday, April 11, 2024 2:00 AM
To: Les Ginsberg (ginsberg) <[e-mail]>
Cc: John Scudder <[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)

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]<mailto:[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]<mailto:[e-mail]>>
> Sent: Tuesday, April 9, 2024 8:28 AM
> To: Zaheduzzaman Sarker <[e-mail]<mailto:[e-mail]>>
> Cc: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>; The IESG <[e-mail]<mailto:[e-mail]>>;
> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[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]<mailto:[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.

[LES2:] Sure – we will make that change.

> > - 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.

[LES2:]  The draft is an experimental draft. And the abstract states (emphasis added):

“This document discusses the need for faster
   flooding, the issues around faster flooding, and SOME EXAMPLE
   APPROACHES to achieve faster flooding.”

It isn’t clear to me what text suggests to you that there is a relationship between the two algorithms – where each algorithm is intended for certain deployment scenarios.
What is presented are two different approaches – developed by different subsets of the authors. There could be others.
I think the abstract sets the correct tone.
There is no intent to recommend one algorithm over another based on deployment scenario.


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.

[LES2:]  Section 6.3 now reads:

“6.3.  Transmitter Based Congestion Control Approach

   This section describes an approach to congestion control algorithm
   based on performance measured by the transmitter without dependance
   on signaling from the receiver.”

Is this not clear that flow control is not being used?
We can add an explicit statement “Flow control is not used by this approach.” If you really think it is necessary.

   Les

   Les


> Thanks,
>
> —John