Hi Zahed, Top posting as I believe Les and you came to a conclusion. The below thread will be reflected in -10.
In short, for the second approach: * :s/SHOULD/should * “Flow control is not used by this approach.” --Bruno Orange Restricted From: Lsr <[email protected]> On Behalf Of Les Ginsberg (ginsberg) Sent: Friday, April 12, 2024 6:42 PM To: Zaheduzzaman Sarker <[email protected]> Cc: John Scudder <[email protected]>; The IESG <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [Lsr] Zaheduzzaman Sarker's Discuss on draft-ietf-lsr-isis-fast-flooding-08: (with DISCUSS and COMMENT) CAUTION : This email originated outside the company. Do not click on any links or open attachments unless you are expecting them from the sender. ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur. 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 <[email protected]<mailto:[email protected]>> Sent: Thursday, April 11, 2024 2:00 AM To: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>> Cc: John Scudder <[email protected]<mailto:[email protected]>>; The IESG <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> 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) <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> > Sent: Tuesday, April 9, 2024 8:28 AM > To: Zaheduzzaman Sarker > <[email protected]<mailto:[email protected]>> > Cc: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>>; > The IESG <[email protected]<mailto:[email protected]>>; > [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]> > 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 > <[email protected]<mailto:[email protected]>> 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 ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
