Packet delivery in TCP protocol [closed]

Question

Let us assume that station A of 1 Gbit/s wants to send the packets to station B of 100 Mbit/s. There are three routers with 10 Mbit/s, 1 Gbit/s and 10 Mbit/s respectively. How does the packet delivery take place?

Answer 1

TCP flow control will kick in since the speeds are different.

Another thing that could affect TCP in this situation, based on the link type, is if the 1 Gbit/s router is using jumbo frames, but it's no different than if the routers had different MTUs - either the packets would be dropped or fragmented.

Answer 2

In short, you will get 10 Mbit/s throughput.

Naively, one might think that TCP flow control will kick in as stated by LawrenceC, and this is generally the correct answer.

However, in your concrete example, it is not.

The 10 Mbit/s router connected to your 1GbE card will negotiate 10 Mbit/s. The same for the 10 Mbit/s router on the intermediate GbE router and on the B side. End of story.

Thus, the network adapter will only ever send and receive at that rate, never exceeding it. Indeed, from your point of view, the entire network is 10 Mbit/s.

The intermediate GbE router might receive and forward packets at 1 Gbit/s with the rest of the world, but will only do 10 Mbit/s on your particular route.

Let's assume the network topology is somewhat more complicated (Internet!), and there is some amount of gigabit routers, and one or several 10 Mbit/s routers somewhere in between. That case is a bit more interesting.

In this case, your computer A will send packets at 1 Gbit/s, but we know that only 10 Mbit/s can make it through (well, not really, with alternative routes, but let's forget that). How can that work?

In this case, indeed, TCP flow control will kick in. Station B will receive packets with 100 Mbit/s but they only come in sporadically. You will send packets with 1 Gbit/s, but you will have to take a pause regularly. This works on the TCP layer without you knowing.

TCP will send out a few packets as fast as it can (and maintain a "window"), and the network card will put them on the wire as fast as it's capable and allowed to, and then TCP will wait for acknowledgements to come in. If they do come in, all is fine and more stuff can be sent as fast as possible. If the ACKs do not come in, there was either an error (unlikely) or packets were sent too quickly. Therefore the window size is reduced. Once ACKs come in again, the window is gradually enlarged again. There are different algorithms for that, and they are rather elaborate, but in principle that's it.

Now... routers accept a limited number of packets, and forward them according to their ability to do so, as fast as they can. Eventually, they will however have to drop packets. This is not an error, but a normal condition.

Ironically, the presumably old 10 Mbit/s routers are likely to queue a lot of packets (since once upon a time, the belief was "more is always better", nowadays it is known that the opposite is the case, modern routers have very short queues).

The insight that more is not always better comes from the fact that if a router queues a lot of packets and then forwards them, the sender may assume the packets lost (because no ACKs came in) and resend. Which causes the receiver to receive duplicate packets that it must discard and it causes the router to become even more congested, pouring oil into the fire. Therefore, modern routers discard quickly.

Now, in the example of an old 10 Mbit/s router somewhere in the middle (and speed not negotiated), it is very likely that you get considerably less than 10 Mbit/s throughput due to this. You get resends and double deliveries. None of that is visible to the application, it's just slower for some weird reason.