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

[Tony Przygienda <[e-mail]>]

On Tue, Mar 10, 2020 at 9:43 AM <[e-mail]> wrote:

> With regards to punting to TCP, I think that TCP (stacks) enforce packet
> ordering.
>
> i.e. if you receive packets 1, 3,4, …,N, then you can only use packet 1
> until you receive packet 2. In the meantime, you cannot use the (N-2)
> packets that you did received.
>
> That seems like a regression for IS-IS which doesn’t requiring LSPs
> ordering. (vs BGP).
>

well, TCP is a windowing protocol and they're hard and very
bandwidth*delay/loss/jitter sensitive and yes, TCP is reliable transport
and not unreliable like ISIS flooding is ... Having said that, insane
amount of work has been done on TCP variants in all kind of stacks &
flavors coming full circle from fast start to slow start to fast start
again ;-)

Stepping back a bit, what we have in ISIS is basically a DHT and the
fastest way to synchronize that AFAIS is bittorrent transport ;-) When
doing RIFT I looked @ their transport & one can learn a lot from that but
it's a brave new world compared to the esteemed 10589 ;-) If one does that
kind of transport well, it blows TCP perf away in good scenario but then,
if we look for something 'download-open-source-and-plugin' kind except some
10 years old DCCP code you ain't gonna find anything massively hardened,
small or easily pluggable into an ISIS implementation. modulo open source
quic i didn't check the state off for last year or so or some secret sauce
someone found or maybe some of the p2p code got modularized and documented
;-) ...


>
> Also, from what I’ve been told from BGP implementers, TCP is not magic and
> can’t be treated as a black box (if you want scale/performance).
>

that's a mild understatement if you ask me after having lived in the
trenches since 1995 or so ;-)  On the other hand, the work has been done
often already and could be piggy-backed on but then, we buy ourselves
mandatory IP addressing into ISIS transport and lots of other interesting,
undesirable things TCP does since it's not a hop-by-hop transport but
"something that always tries to find a way". And next thing we'll need
TCP-AO so beware what you wish for ;-)

--- tony