Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[Tony Przygienda <[e-mail]>]

On Wed, Apr 22, 2020 at 11:03 AM <[e-mail]> wrote:

> Tony, all,
>
>
>
> Thanks Tony for the technical and constructive feedback.
>
> Please inline [Bruno]
>
>
>
> *From:* Tony Przygienda [mailto:[e-mail]]
> *Sent:* Wednesday, April 22, 2020 1:19 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* DECRAENE Bruno TGI/OLN; [e-mail]
> *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 ;-) 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.

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)
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.


> 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