From: gtaylor@tnetconsulting.net   
      
   On 3/20/20 11:20 AM, groovee@cyberdude.com wrote:   
   > Now the first router on the hop outwards from the EU server will CHECK   
   > which way the route is less congested, right, before it picks one of   
   > these 2 paths, without which the net would have been unworkable by now?   
      
   Most likely not.   
      
   > Now my question is, how does IT, sitting in the *EU*, know whether   
   > the link between *TAJIKISTAN* and Mumbai is free, as opposed to the   
   > link between *Iran* and Mumbai?   
      
   It very likely doesn't.   
      
   > Is this info constantly shared between routers like, per MILLISECOND   
   > or something??   
      
   Nope.   
      
   > Also, I heard that CISCO somehow (!!) knows how WORLD internet traffic   
   > is moving - is this somehow because CISCO routers "send something back"   
   > to them or "call home"?   
      
   No they don't.   
      
   > Otherwise how could they know this?? HIGHLY disturbing!   
      
   Which is one of the reasons that they don't.   
      
   Cisco, and other vendors, sell products that fall under the broad   
   category of "Software Defined Networking".  One of the key tenants of   
   SDN is that each forwarding device sends this information back to a   
   (redundant) central control point, called an "SDN Controller".  This SDN   
   Controller does have visibility of the flows that are passing through   
   the devices connected to it.  As such, this SDN Controller can direct   
   each attached router what to do with a given flow.   
      
   This control point is private and each enterprise network has their own.   
      
   > I'm also curious about what exactly happens if a *faster moving   
   > packet*, say segment 2 of a stream arrives at the client in Mumbai   
   > before a slower, segment 1 (say via the Tajikistan link, while segment   
   > 2 came via Quicker Iran)? Will the Linux kernel just HOLD  segment   
   > 2 forever inside RAM or something while waiting for the rest to turn   
   > up? (that's not a good thing, is it?) What about Windows?   
      
   You're closer than you might realize.  Research TCP's "segmentation and   
   reassembly".   
      
   TL;DR:  Yes, the kernel will hold onto out of order TCP packets for a   
   while in the hopes that the earlier packets come in so that it can give   
   an ordered stream to the client.   
      
   Note:  How long and how many packets are buffered is implementation   
   specific.   
      
   I believe all contemporary TCP/IP stacks; Linux, Windows, macOS, etc.,   
   do this.  Most of the older TCP/IP stacks did this too.  You have to go   
   back to the '80s to find TCP/IP stacks that either didn't do this or   
   didn't do so properly (evolving / bad design).  We periodically see bugs   
   in various implementations.   
      
   > Thanks.   
      
   You're welcome.   
      
      
      
   --   
   Grant. . . .   
   unix || die   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)