Inline… Mitchell Erblich Implementation of IS-IS for Extreme Networks in what seems Eons ago… [email protected]
> On May 3, 2020, at 11:12 PM, [email protected] wrote: > > > Mitchell, > >> I think we/you are looking at two different problems: >> 1) a hop count of 1 or maybe two between the two end points 2) and the >> multiple / many hop count between the two end points. > > > IS-IS adjacencies are always between immediate L3 neighbors, ignoring strange > things like tunneling. IS-IS has two levels of neighbors via hello level 1s (LSAs) and hello level 2s :, so immediate is somewhat relative.. > > >> Thus, I think that your issue is mostly the #2 problem >> and the problem that most CA algorithms IMO always try to increase capacity >> and thus at some point must exceed capacity. TCP must find a range of >> capacity per flow (assuming a consistent a number of packets per sec). >> However, what is maybe missed (I missed it in the document) is the ability >> not to overshoot the TCP threshold point and trigger multiple initial >> congestion events in/exiting the slow-start phase. > > > Modern router designs have interface bandwidths from 10-400Gb/s. The CPU > would be hard pressed to supply 1Gb/s, therefore for most of the > circumstances that we’re concerned about, the link capacity is never the > issue. Sorry, I disagree ,, Link capacity is always an issue.. wrt to video we now have 4k/8.3mpixels video streams with 8k support at the TV in the near future. And as you mentioned 400Gb via Link Aggregation… Whether a single or multiple 1 core, 4core or more is used and the speed of the Eth interface(s) is based on the platform. I would assume that hello 2 level neighbors / adjacencies would be more WAN based and thus stresses a router’s link capacity more than a standard neighbors via hello 1s… Even more grey scale or the number of different colors of pixels require more link capacity… Pixelation on your TV is based on either link capacity or not being able to process the packets, and thus either get dropped or just skipped. Even compression consumes CPU processing a requires an “entire frame” / partial frame to be recieved before the frame can be processed. If we jump to OSPF it is the DRs and BDRs, I would assume consume more link capacity, than DRothers (note; does not use TCP). So, link capacity and/or packet-per-sec processing Will always be an issue in some/many environments, and is more so with IPv4 due to fragmentation given fixed input queue/fifos sizes, and whether the router then does tail drops, or REDS (random early discards), or does delay of dropping an adjacency because it is processing a massive number of LSAs and has not processed the hello,,, Please tell me 1 router can process say 1GByte of min sized packets at wire speeds of say 400Gb/sec, via echo requests/responses… aka 1 million pings as a quick stress test.. Even with long enough FIFOs, don’t we have longer latencies as we queue up the packets? This is a side effect of link capacity… Even limiting the number of routers in a area and having slower or faster convergence, is based on link capacity and CPU capacity,,, aka the platform > > Tony > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
