Robert – Sure – we can add some text in this area.
Implementations which don’t do well at current flooding speeds clearly won’t do well at faster flooding speeds unless they are enhanced. And such implementations won’t do well at scale even w/o faster flooding. As always with these kinds of improvements, deployment has to be done carefully. I suppose this argues for more discussion of deployment considerations. Added to the list… Les From: Robert Raszuk <[email protected]> Sent: Wednesday, February 19, 2020 10:55 AM To: Les Ginsberg (ginsberg) <[email protected]> Cc: [email protected] Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed Hi Les, Yes this "small delay" of ACK aggregation is something which I am a bit worried here from SNPs sender side. Now as indeed draft mentioned prioritizing SNPs on reception let me indicate that some platforms I have not so long ago dealt with do not even prioritize any IGP packet over other packets at neither ingress LC nor queue to RE/RP. If that channel takes 100s of ms within the box I am afraid all bets for flooding improvement are off. Thx R,. On Wed, Feb 19, 2020 at 6:48 PM Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>> wrote: Robert – Thanx for your input. Note that one of the suggestions in https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-flooding-scale/ is to prioritize the reception of SNPs over LSPs so that we are less likely to drop ACKs. It is not clear to me why you think SNP generation would be an issue. Once a received LSP is processed one of the outputs is to set a per interface flag indicating that an ACK (PSNP) needs to be sent (SSN flag). Implementations usually implement some small delay so that multiple ACKs can be sent in a single PSNP – but I do not see why this should be viewed as a bottleneck. If your concern is that we need to emphasize the importance of sending timely ACKs, I think we could look at text that makes that point. Les From: Lsr <[email protected]<mailto:[email protected]>> On Behalf Of Robert Raszuk Sent: Wednesday, February 19, 2020 1:07 AM To: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed Hi Les & all, Watching this discussion I would like to state that IMO going with transmitter based rate limiting (I would not call it flow control) is much easier option to deploy and operate. It also has no dependency across other side of p2p adj which is a very important factor. The only issue here is if generation of [P|C]SNPs is fast enough. Receiver based flow control is simple in flow theory however I have a feeling that if we are to go that path we would be much better to actually run ISIS flooding over DC-TCP and avoid reinventing the wheel. Thx, Robert.
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
