Zahed, Bruno, and Les, Thanks for bringing this issue to completion.
Acee > On May 2, 2024, at 8:46 AM, [email protected] wrote: > > 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]> > Sent: Thursday, April 11, 2024 2:00 AM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: John Scudder <[email protected]>; The IESG <[email protected]>; > [email protected]; [email protected]; > [email protected];[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]> > 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]> > > Sent: Tuesday, April 9, 2024 8:28 AM > > To: Zaheduzzaman Sarker <[email protected]> > > Cc: Les Ginsberg (ginsberg) <[email protected]>; The IESG <[email protected]>; > > [email protected]; [email protected]; > > [email protected]; > > [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]> 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
