Questions about routing and congestion

[g***@cyberdude.com]

I heard about the EU telling Netflix to stop HD streaming to stop the net from collapsing, that got me thinking about congestion. For example, say there's a server in Europe streaming stuff to India. There are (say) 2 links into India from EU, one via Iran, one via Tajikistan. 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? 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? Is this info constantly shared between routers like, per MILLISECOND or something??
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"? Otherwise how could they know this?? HIGHLY disturbing!

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?



Thanks.

[Jorgen Grahn]

On Fri, 2020-03-20, ***@cyberdude.com wrote:
...

Post by g***@cyberdude.com
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)?

Generally you try not to let related packets go different paths,
for reasons like this one.

Post by g***@cyberdude.com
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 must be talking about TCP now.

I don't know, but it could either
- discard #2 and ack #1, forcing the sender to retransmit
- ack #0, but keep #2 around in case #1 shows up

I suspect the latter happens.

"Forever" sounded like a bad thing, but I don't think it is. If the
local application is alive, if it hasn't requested any timeouts, if it
doesn't tell the socket to die, and if there's no explicit evidence
that the other side is dead, then the socket should be kept. Even if
you're without network for a week.

/Jorgen

[Grant Taylor]

Post by Jorgen Grahn
I don't know, but it could either
- discard #2 and ack #1, forcing the sender to retransmit
- ack #0, but keep #2 around in case #1 shows up

There is also an option to ack #0 and #2 while waiting for #1. This is
called Selective ACKnowledgement, a.k.a. SACK. Contemporary TCP/IP
stacks implement SACK.

Post by Jorgen Grahn
I suspect the latter happens.

Yes, that's largely correct when SACK is not used.

Post by Jorgen Grahn
"Forever" sounded like a bad thing, but I don't think it is.

Yes, "forever" /is/ a bad thing.

What if I send you packets #2, #3, #4, #5, #6, #7, #8, #9, #10, #11,
#12, #13, #14, #15, #16, #17, #18, … #3,985, … #1,234,567,890.

Do you still want to hold onto the billion packets that I've sent you?
Probably not.

This is a form of Denial of Service (DoS). Hence one of the reasons why
you want to NOT hold onto the out of order packets /forever/.

Post by Jorgen Grahn
If the local application is alive, if it hasn't requested any timeouts,
if it doesn't tell the socket to die, and if there's no explicit
evidence that the other side is dead, then the socket should be kept.

A socket is not the same thing as a packet. The socket can be kept open
even while dropping packets.

Post by Jorgen Grahn
Even if you're without network for a week.

That's all the more reason to not keep all packets. DoS protection.

[Barry Margolin]

Post by Grant Taylor
What if I send you packets #2, #3, #4, #5, #6, #7, #8, #9, #10, #11,
#12, #13, #14, #15, #16, #17, #18, 
 #3,985, 
 #1,234,567,890.
Do you still want to hold onto the billion packets that I've sent you?
Probably not.

Note that this can't really happen because of TCP's "window size"
feature. The receiver tells the sender how far ahead of acknowlegements
it can go. Any segments outside the window will be discarded. The window
size corresponds to the amount of buffer space that the receiver will
reserve for the out-of-order segments.

[Grant Taylor]

Post by Barry Margolin
Note that this can't really happen because of TCP's "window size"
feature. The receiver tells the sender how far ahead of acknowlegements
it can go. Any segments outside the window will be discarded. The
window size corresponds to the amount of buffer space that the receiver
will reserve for the out-of-order segments.

You are correct. The window size does put an upper bound on the example
that I gave. But the DoS is still a problem. Especially if I'm able to
establish multiple connections and send up to the window size.

However you go about it, you don't want to indefinitely hold onto all
packets.

[Grant Taylor]

Post by g***@cyberdude.com
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.

Post by g***@cyberdude.com
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.

Post by g***@cyberdude.com
Is this info constantly shared between routers like, per MILLISECOND
or something??

Nope.

Post by g***@cyberdude.com
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.

Post by g***@cyberdude.com
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.

Post by g***@cyberdude.com
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.

Post by g***@cyberdude.com
Thanks.

You're welcome.