Tony, Thanks for engaging. Please inline [Bruno2]
From: Tony Przygienda [mailto:tonysi...@gmail.com] Sent: Wednesday, April 22, 2020 9:25 PM To: DECRAENE Bruno TGI/OLN Cc: lsr@ietf.org; Les Ginsberg (ginsberg) Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed On Wed, Apr 22, 2020 at 11:03 AM <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> wrote: Tony, all, Thanks Tony for the technical and constructive feedback. Please inline [Bruno] From: Tony Przygienda [mailto:tonysi...@gmail.com<mailto:tonysi...@gmail.com>] Sent: Wednesday, April 22, 2020 1:19 AM To: Les Ginsberg (ginsberg) Cc: DECRAENE Bruno TGI/OLN; lsr@ietf.org<mailto:lsr@ietf.org> Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed neither am I aware of anything like this (i.e. per platform/product flooding rate constants) in any major vendor stack for whatever that's worth. It's simply unmaintanable, point. All major vendors have extensive product lines over so many changing hardware configuration/setups it is simply not viable to attempt precise measurements (and even then, user changing config can throw the stuff off in a millisecond). There may have been here and there per deployment scenario some "recommended config" (not something I immediately recall either) but that means very fixed configuration of things & how they go into networks and even then I'm not aware of anyone having had a "precise model of the chain in the box". yes, probes to measure lots and lots of stuff in the boxes exist but again, those are chip/linecard/backplane/chassis/routing engine specific and mostly used in complex test/peformance scenarios and not to derive some kind of equations that can predict anything much ... [Bruno] Good points. Yet, one of the information that we propose to advertise by the LSP receiver to the LSP sender is the Receive Window. - This is a very common parameter and algorithm. Nothing fancy nor reinvented. In particular it’s a parameter used by TCP. - I would argue that TCP implementations also run on a variety of hardware and systems, must wider range than IS-IS platform. And those TCP implementations on all those platform manage to advertise this parameter (TCP window) - I fail to understand that when some WG contributors proposed the use of TCP, nobody said that determining and advertising a Receive Window would be an issue, difficult or even impossible. But when we propose to advertise a Receive Window in an IS-IS TLV, this becomes difficult or even impossible for some platforms. Can anyone help me understand the technical difference? Bruno, I was waiting for that ;-) [Bruno2] Good ;-) Discounted for the fact that I'm not a major TCP expert: TCP is a very different beast. it has a 100-200msec fast timer & 500msec slow (which have to be quite accurate, it's really one timer for all connections + mbuf and other magic) and it sends a _lot_ of packets back and forth with window size indications so the negotiation can happen very quickly. Also, TCP can detect losses based on sequence number received contrary to routing protocols (that's one of the things we added in RIFT BTW) and it can retransmit quickly when it sees a "hole". Contrary to that in ISIS ACKs may or may not come, they may be bundled, hellos may or may not come and we can't retransmit stuff on 100msec timers either. It's an utterly different transport channel. [Bruno2] I would distinguish two things, which I think we have done in https://tools.ietf.org/html/draft-decraene-lsr-isis-flooding-speed-03 - How fast you can adapt the sending rate. This seems mostly dependent on the speed of the feedback loop, rather than the format of message. E.g. In IS-IS the receiver can give a feedback more or less quickly (e.g. depending on how fast/bundled it sends the PSNP). In theory, I don’t see a major different. From an in implementation standpoint, I’m guessing that the difference is probably bigger (e.g. TCP is probably lower level/closer to the system/hardware, than IS-IS which is more user space and possibly Platform Independent in some organizations)) - How fast you can detect packet loss. I agree that TCP & IS-IS are very different on this. We have proposed to improve this by allowing the receiver to advertise to the sender how fast it will ack the LSP. Currently the timer/behavior is known to receiver but no to the sender. Hence the sender needs to assume the wort case (ISO default). In more abstract terms, TCP is a sliding N-window protocol (where N is adjusted all the time & losses can be efficiently detected) whereas LSR flooding is not a windowing protocol (or rather LSDB-size window protocol with selective retransmission but no detection of loss [or only very slow based on lack of ACK & CSNPs]). Disadvantage of something like TCP (I think I sent out the RFC with UDP control protocol work to make it more TCP like) [Bruno2] If you are referring to DCCP (Datagram Congestion Control Protocol) (RFC 4340), yes you did and thank you for this. Constructive feedback. - Regarding flow control, I’ve quickly looked at DCCP and it does not provides flow control. - Regarding congestion control, possibly the algorithm part may be reused. There are two algo and DCCP is open to others. May be one question is how much we want IS-IS to be fair to TCP (control plane TCP, not dataplane/user plane TCP). To me, IS-IS is more important than BGP traffic, given their relative importance to the network, their delay requirements, their typical volume of traffic. But that is probably a “detail” down the road. This is also depends on whether TCP & IS-IS compete for the same resources (e.g. same queue) or not (ideally TCP and IS-IS have different queues). is that you are stuck when you put something into the pipe, no prioritization possible and if receiver is slow you may have multiple obsolete copies in the pipe waiting & lots retransmission BW when holes are punched into the data through loss. And plain TCP is actually quite bad for control protocol traffic @ scale, almost all vendor run special version of it for BGP for that reason. Why that is is out of scope of this list I think ... Flooding is really good to send lots of data prioritized/in parallel but on losses re-TX is slow. [Bruno2] Good that we seem to make the same distinction between the control loops for the sending rate vs the retransmission. Regarding clarifying distinctions, draft may need to better introduce the distinction between flow control and congestion control, at least to structure the work and the discussion. Thanks --Bruno Bruno, if you're so deeply interested in that stuff we can talk 1:1 off-line about implementation work on rift towards adapatable flooding rate [Bruno] Sure. My pleasure. Please propose me some timeslot offline. Please note that I’m based in Europe (CEST), so a priori during your morning and my evening. If you can also extend the offer to discuss the implementation work on the IS-IS implementation of your employer with regards to adaptable flooding rate, and/or how network operator can configure the CLI parameters of the LSP senders so as to improve flooding rate without overloading the Juniper receiver (possibly depending on the capability of the receiver, its number of IS-IS neighbors… and/or whatever parameter that you feel are relevant) that would be most appreciated. And if you believe that the Juniper LSP receiver can handle any rate from any reasonable (e.g. 50) number of IGP neighbors, without (significantly) dropping the received LSPs, that would be even simpler, please advise. ping me for that 1:1 on company email pls -- tony _________________________________________________________________________________________________________________________ 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
