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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

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.

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

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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: fsxNet Usenet Gateway (21:1/5)

On 3/20/20 12:43 PM, Jorgen Grahn wrote:

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.

I suspect the latter happens.

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

"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/.

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.

Even if you're without network for a week.

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



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <r53l8c$b7i$1@tncsrv09.home.tnetconsulting.net>,
Grant Taylor <gtaylor@tnetconsulting.net> wrote:

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.

--
Barry Margolin
Arlington, MA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)