On Tue, Mar 10, 2020 at 9:43 AM <[email protected]> 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
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
