1. Forum
  2. Usenet
  3. COMP.PROTOCOLS.TCP-IP

  • Questions about routing and congestion

    From [email protected]@21:1/5 to All on Fri Mar 20 10:20:35 2020
    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)
  • From Jorgen Grahn@21:1/5 to [email protected] on Fri Mar 20 18:43:04 2020
    On Fri, 2020-03-20, [email protected] 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)
  • From Grant Taylor@21:1/5 to [email protected] on Fri Mar 20 17:55:27 2020
    On 3/20/20 11:20 AM, [email protected] 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)
  • From Grant Taylor@21:1/5 to Jorgen Grahn on Fri Mar 20 18:01:50 2020
    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)
  • From Barry Margolin@21:1/5 to Grant Taylor on Sun Mar 22 17:10:18 2020
    In article <r53l8c$b7i$[email protected]>,
    Grant Taylor <[email protected]> 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)