Hi Zahed, Thanks for the discussion. I believe we are converging. Please see inline [Bruno3] -10 has been published and should cover those changes.
Given that the three parallel emails threads are becoming a bit long, once you have reviewed -10 and if you identify further/continuing issues, may be it would be simpler to restart a new fresh thread with the remaining points. Totally up to you of course. > > Orange Restricted > -----Original Message----- > From: Zaheduzzaman Sarker <[email protected]> > Sent: Sunday, April 14, 2024 10:52 PM > To: DECRAENE Bruno INNOV/NET <[email protected]> > Cc: [email protected]; John Scudder - Juniper ([email protected]) > <[email protected]>; Zaheduzzaman Sarker <[email protected]>; > [email protected]; [email protected]; > [email protected]; [email protected]; The IESG <[email protected]> > Subject: Re: 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. > -------------------------------------------------------------------------------------------------------------- > > On Thu, Apr 11, 2024 at 8:54 PM <[email protected]> wrote: > > > Hi Zahed, > > > > > > > > Please see inline [Bruno2] > > > > > > > > *From:* Zaheduzzaman Sarker <[email protected]> > > *Sent:* Thursday, April 11, 2024 11:33 AM > > > > Hi Bruno, > > > > > > > > My apologies too :-) , I was on PTO > > > > > > > > [Bruno2] No problem. I was also partly on PTO and I would also hope to > > be next week. > > > > > > > > My responses inline below. > > > > > > > > //Zahed > > > > > > > > On Tue, Apr 9, 2024 at 5:13 PM <[email protected]> wrote: > > > > Zahed, > > > > Thank you for your review and comments. > > Sorry for my delayed response. > > > > Les has already commented on the algo 2 section. > > > > Please see inline for other points [Bruno] > > > > > > > > -----Original Message----- > > > From: Zaheduzzaman Sarker via Datatracker <[email protected]> > > > Sent: Thursday, April 4, 2024 12:17 PM > > > To: The IESG <[email protected]> > > > Cc: [email protected]; [email protected]; > > [email protected]; [email protected]; [email protected] > > > Subject: 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. > > > > > ---------------------------------------------------------------------- > > ---------------------------------------- > > > > > > Zaheduzzaman Sarker has entered the following ballot position for > > > draft-ietf-lsr-isis-fast-flooding-08: Discuss > > > > > > When responding, please keep the subject line intact and reply to > > > all > > email addresses included in the To and CC lines. (Feel free to cut > > this introductory paragraph, however.) > > > > > > > > > Please refer to > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-positi > > ons%2F&data=05%7C02%7Cbruno.decraene%40orange.com%7C2a902926901748bc96 > > 2208dc5cc4ce17%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6384872475 > > 46249475%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL > > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=dB5qeiHyPkp0WuVg2EvRS > > l903dR7tqOQqAIzGqoq1E4%3D&reserved=0 > > > for more information about how to handle DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fda > > > tatracker.ietf.org%2Fdoc%2Fdraft-ietf-lsr-isis-fast-flooding%2F&data > > > =05%7C02%7Cbruno.decraene%40orange.com%7C2a902926901748bc962208dc5cc > > > 4ce17%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63848724754625828 > > > 6%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi > > > I6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Vkq2BkMsnkcroSf8f3tld%2B > > > YDXxhXlhLLiPK6IR8RuZY%3D&reserved=0 > > > > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > DISCUSS: > > > -------------------------------------------------------------------- > > > -- > > > > > > Thanks for working on this specification. Thanks for Mirja for the > > > TSVART review. > > > > > > I would like to discuss the following points as I believe some > > clarifications > > > would help - > > > > > > - Does the flow and congestion control algorithm 1 assume that there > > > is > > only on > > > (input)queue in a particular link? I understand that the motivation > > > for congestion control algorithm 2 is that there are multiple input > > > queues > > and > > > defining rwin is difficult. Why is that easy for the case of algorithm 1? > > > > [Bruno] > > Sorry it's not clear to me if by "multiple input queues" you mean in > > parallel (e.g. for different IS-IS neighbors or different incoming > > traffic) or serial (consecutive congestion points). > > > > > > > > I was considering 6.3.1 kind of setup. > > > > > > > > [Bruno2] Thank you for the clarification. That’s good as this is > > something that I can understand 😉 > > > > > > > > Also by " the flow and congestion control algorithm 1" is this > > specific to flow or congestion control? > > > > > > > > The fact is it was not clear to me if flow control in section 6.2.1 is > > an independent solution to the problem or is part of the Algorithm 1. > > Over all it is now not clear to me what should I implement from > > 6.2...Is implementing the flow control described in 6.2.1 is good > > enough? or do we need flow control and congestion control both to be > > implemented? > > > > > > > > [Bruno2] flow control in section 6.2.1 is part of Algorithm 1 which is > > section 6.2 > > > > Implementing flow control in 6.2.1 is good enough if your internal > > router implementation will not significantly drop IS-IS PDU > > (considering 6.3.1 setup). E.g., if you have congestion for IS-IS > > traffic, you are capable of buffering it. (IS-IS is typically treated > > as high priority). Otherwise, adding congestion control will help. (in > > our tests, we had a rather simplified router, more like pizza box than > > chassis, and flow control was enough. We had to deliberately create > > congestion with a deliberate small buffer to see benefit from > > congestion control) > > > > This details is good to add in the respective section. This will clarify my > confusion. [Bruno3] added in -10 > > > > > > > > > > > Regardless, I'll try an answer and please refocus me as needed. > > > > Flow control assume the existence of a control plane buffer e.g. in > > the socket. In the general case, there may be one per IS-IS neighbor > > or one shared by multiple neighbors. In the first case, the size of > > this buffer is advertised as the rwin. In the latter case, the size > > needs to be split across those neighbors. (In more details, some room > > need to be kept to handle some IS-IS traffic which is not flow > > controlled such as Hello and PSNP). > > > > > > > > Right and I am under the understanding that the first case is where > > the > > 6.2.1 is only valid, am I wrong? > > > > > > > > [Bruno2] 6.2.1 is valid in both cases. If multiple neighbhors share > > the same socket buffer one need to advertise rwin as buffer/number of > > neighbors. > > > > We should clarify this. [Bruno3] This seems a bit too implementation specific to me and could even confuse the reader. I'd rather propose to better specify the definition of rwin in §4.6 to state that the value is per neighbor/adjacency. OLD: The Receive Window (RWIN) sub-TLV advertises the maximum number of unacknowledged LSPs that the node can receive. NEW: The Receive Window (RWIN) sub-TLV advertises the maximum number of unacknowledged LSPs that the node can receive for this adjacency. > > > > > > > > On the shared queues what happens if Algorithm 1 is implemented by > > some and Algorithm 2 implemented by others? on a shared queue to get > > the goodput we need fairness among the competing algorithms. > > > > > > > > [Bruno2] Good question. > > > > To begin with, contrary to typical transport goal, I don’t think that > > we require fairness between IS-IS neighbors. For IS-IS, assuming a > > single IS-IS level/instance, all IS-IS neighbors will advertise me the > > same packets/LSP. It’s does not matter whether I receive all LSPs from > > neighbhor1 only while neighbhor2 has zero goodput. > > > > Then to answer your question, in your scenario, algorithm2 would > > typically be more aggressive and get all the bandwidth. (although we > > don’t have details about algo2). IMHO likely algo1 would be less > > aggressive as its flow control RWIN is aiming at proving control > > without loss while algo2 is reacting when it has exceeded the > > capability of the receiver. And for algo > > 1 LSP loss would temporarily reduce the usable RWIN and hence the > > throughput (if the throughput was limited by RTT and RWIN size). > > > > I was lacking this information, so thanks for explaining it that starvation > is not an issue in IS-IS. > > > > Finally, please consider that currently there is zero flow control or > > congestion control algorithm specified for IS-IS. It’s all proprietary > > and different. (Possibly with little consideration for interop from > > some implementation). So I believe this document is a step in the > > right direction. > > > > I see that and I appreciate the effort. It for the same reason important to > explain and describe the impacts the flow control and congestion controls > will have, so we all understand what we are implementing and benefit of it. [Bruno3] OK. > > > > > > > > Congestion control does not make much assumptions because it seems > > like router architectures may be quite different and for the complex > > cases (chassis with multiple line cards) the internal are a secret > > sauce. However during out test we only introduced a single and simple > > congestion point. > > > > > > > > Have you run any test with two different algorithms sharing same > > congestion point? > > > > > > > > [Bruno2] No in our lab. > > > > But as there is currently no specified algo, and different vendors > > have different behaviors, well I’d say that multiple vendors networks > > experience this in live networks for about 2 decade (and even for > > single vendor, some vendors have changed their algo over the time) > > > > If fairness is not any goal here then I think this test is not that important > here. > > > > > > > > On a side note, we have presented some tests results at IETF 111. If > > you want to have a look at them, please find below the slides. If you > > have some comments on the tests results, I would be obviously > > interested in your comments. Either on the list or of the list. > > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata > > tracker.ietf.org%2Fmeeting%2F111%2Fmaterials%2Fslides-111-lsr-22-flow- > > congestion-control-00.pdf&data=05%7C02%7Cbruno.decraene%40orange.com%7 > > C2a902926901748bc962208dc5cc4ce17%7C90c7a20af34b40bfbc48b9253b6f5d20%7 > > C0%7C0%7C638487247546265364%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD > > AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=yo > > Y4kzB8X8HlWSeTwB5uif27ouJaXE73DZkCIObAjnE%3D&reserved=0 > > > > As far as I understood it, the motivation for congestion control > > algorithm > > 2 is that: > > - determining rwin may be difficult when the same software runs on > > very different hardware and that no API exist to get that info; > > - the congestion control algorithm may cover the functionality of the > > flow control in which case implementing only the congestion control is > > simpler than implementing both > > > > > > > > This should be in the document and very important one. > > > > > > > > [Bruno2] The first point is an implementation specific point/issue. > > This may be completely irrelevant for another implementation. > > > > I’ll leave the second point to Les as this is my understanding but he > > may have a different opinion. > > > > > > > > - flow control requires both the sender and the receiver to be > > upgraded while congestion control algorithm 2 could cover existing > > implementation including in their various forms... > > > > > > > > This is also information to share. > > > > > > > > [Bruno2] > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata > > tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lsr-isis-fast-flooding-09%2 > > 3section-5&data=05%7C02%7Cbruno.decraene%40orange.com%7C2a902926901748 > > bc962208dc5cc4ce17%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638487 > > 247546271268%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM > > zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=AO%2B0yTO0GlwoZnh7V6KsLja5KYHiZOHrH%2B4HHDMFdTU%3D&reserved=0 > > already states that performance improvement on the receiver is needed in > > order to have a faster feedback (and more rythme) from the sender. I tend > > to believe that this is useful for both algo (as this looks difficult for > > the sender to adapt in the absence of feedback from the receiver) but I’m > > ok adding specific text in the Algo 1 flow control section. > > > I would propose to add the following text at the end of 6.2.1. Flow > > control (i.e., just after the discussion on the impact of RWIN value > > on the performance, which start with “The RWIN value is of importance > > when the RTT is the limiting factor for the throughput.”) > > > > > > > > “Equally RTT is of importance for the performance. That’s why the > > performance improvement on the receiver, described in section 5, are > > important to achieve good throughput. If the receiver does not support > > those performance improvement, in the worst case (small RWIN and high > > RTT) the throughput will be limited by the LSP Transmission Interval > > as defined in section 4.2.“ > > > > > > > > (text subject to review from my co-authors) > > > > Works for me. [Bruno3] done. > > > > > > > > > Why is that easy for the case of algorithm 1? > > > > [Bruno] In our implementation (Free Range Routing) determining rwin > > has not been found to be a problem. > > > > > > > - Can we really call congestion control algorithm 2 a congestion > > > control algorithm? We are are really solving the problem of flow > > > control, it > > sounded > > > more like a emergency break ( aka circuit breaker ) to me where you > > reduce or > > > even stop sending LSPs. My point is I am not sure how to interpret > > > the congestion control algorithm 2 with any sort of details. If I > > > replace > > section > > > 6.3.2 with - "if the routing architecture does not support > > > deterministic > > rwin, > > > the transmitter MUST adapts the transmission rate based on > > > measurement > > of the > > > actual rate of acknowledgments received." what harm would it cause? > > > > > > - For the congestion control algorithm 2, I am missing when the > > transmitter > > > should reduce or when it should stop sending as I am not sure > > > reducing > > the > > > transmission rate would solve the problem of not. This comes from > > > lack of details on the particular algorithm that will be implemented > > > eventually > > > > > > > > > - Section 6.3.2. says - > > > > > > The congestion control algorithm MUST NOT assume the receive > > performance of > > > a neighbor is static, i.e., it MUST handle transient conditions which > > > result in a slower or faster receive rate on the part of a neighbor. > > > > > > How to separate the persistent congestion from transient slower > > receive rate? > > > I am not sure how to fulfill the "MUST". > > > > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > I have some further questions or comments - > > > > > > - How does the implementers select between congestion control (CC) > > algorithm 1 > > > and 2? or is the intention that both gets implemented and after > > experiments we > > > pick one? As in my discuss point I am not sure about the CC algorithm 2 > > on how > > > to conclude on the experiments. > > > > [Bruno] My guess is that each implementation makes its choices based on > > its constrained. > > Algo 2 is supposed to adapt to any receiver but as you stated the detailed > > are not specified. > > Algo 1 flow control needs two things from the receiver: > > > > > > > > Again. does Algo 1 include both flow and congestion control? > > > > > > > > [Bruno2] already replied above (I believe) > > > > > > > > -a- the advertisement of the received window. > > -b- acknowledgements faster than the original ISO spec in order to get a > > feedback loop and to "release" the window. > > > > In the absence of "a" the value could be locally configured on the sender. > > This is covered in the document. > > In the absence of "b" the performance will be affected (but not worst than > > today) > > > > > > > > is b discussed in the document? > > > > > > > > [Bruno2] indirectly in 6.2.1 but the above proposed addition would make it > > more explicit. > > > > Right!! [Bruno3] Excellent. > > > > > > > > > > > > - It already says flow control and congestion control is a Layer-4 > > > responsibility, it would be great if we can say why that is not the > > preferred > > > layer for fast flooding even if it may be obvious for some of us. > > > > [Bruno] > > >From a protocol perspective, IS-IS does not even have a layer-3 (at least > > IP) so a layer-4 is not readily available. > > The LSR WG considered using TCP/IP with > > draft-hsmit-lsr-isis-flooding-over-tcp. In short, the requirement to use IP > > (with same version on both side) was seen as a significant change. > > Also, IS-IS only lacks flow and congestion control while layer-4 usually > > brings other functions. In particular, the "reliability delivery" is > > already covered by IS-IS and there would be duplication. Also we don't > > need/want ordered delivery. > > > > Surely, the ISO, which originally specified IS-IS, was aware of network > > layers and the benefit of layers, including layer 4. I was not there at > > this time so I don't know why precisely they didn't use a layer 4. I guess > > that at the time it was felt that using static constant would be good > > enough. Scaling and routing convergence requirements were much different > > though. Also IS-IS flooding is the hard part and it (really) needs to work > > so there is probably also a desire for control. (Also I've been told that > > for BGP -which uses TCP- it's not as simple as "just using TCP") > > > > > > > > I think a summery of what you wrote would be very useful to describe when > > we are doing congestion and flow control in this document. Currently it > > just says it is L4 job and we are defining flow control and congestion > > control, without answering why. > > > > > > > > [Bruno2] Well, I have large freedom to express myself in an email. Writing > > a summary of WG history in an RFC is a little bit more engaging... Also, > > although the perspective may be of interest, it’s less likely of little > > interest to an IS-IS implementor. > > > > I would propose the below addition in §6.1 “overview” but I’d very much > > welcome the opinion of chairs and responsible AD on this text. (both added > > in destination of this email) > > > > > > > > OLD: > > > > Ensuring the goodput between two entities is a layer-4 responsibility as > > per the OSI model. A typical example is the TCP protocol defined in > > [RFC9293] that provides flow control, congestion control, and reliability. > > > > > > > > NEW: > > > > Ensuring the goodput between two entities is a layer-4 responsibility as > > per the OSI model. A typical example is the TCP protocol defined in > > [RFC9293] that provides flow control, congestion control, and reliability. > > > > In order to improve the IS-IS goodput an option would be to carry IS-IS in > > a layer-4 protocol. However this creates challenges as IS-IS does not use > > IP so existing layer-4 stacks using IP are not readily available. Also > > IS-IS already have reliability mechanisms which would create duplication > > and possibly interference. Finally, many layer-4 providing flow control > > also provides ordered delivery which is not required for IS-IS and even > > harmful. > > > > I replied on this particular in an earlier email. [Bruno3] Ack. Moved to a different thread (and replied) Thanks, Regards, --Bruno > > > > > > > Thanks, > > > > Regards, > > > > --Bruno > > > > > > > > //Zahed > > > > > > > > > > Regards, > > --Bruno > > > > > - Section 6.3.2 says - > > > > > > When congestion control is necessary, it can be implemented based on > > > knowledge of the current flooding rate and the current > > acknowledgement rate. > > > > > > So, how do we know when the congestion control is necessary? > > > > > > > > > > > > > > > ____________________________________________________________________________________________________________ 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
