Talk:TCP global synchronization

Untitled

• it's missing a definition

I suggest the following definition: "TCP global synchronization is an event, in course of which several TCP streams start to send packets simultaneously." In other words, TCP global syncronization is a TCP equivalent of physical resonance, where time substitutes frequency, and number of packets arrived in one time unit substitutes amplitude. Unfortunately, I cannot provide a linkable source (lecture at Internet Technology course in university), and therefore do not put this definition directly into the article. —Preceding unsigned comment added by 83.254.61.172 (talk) 21:06, 18 October 2009 (UTC)

• an image would be helpful

Scale of problem

Is this problem a real problem that occurs on real diverse networks like the internet, or theoretical problem that only occurs on test networks specially designed to demonstarate this. 192.102.214.6 (talk) 14:04, 29 May 2008 (UTC)

I don't see any reasons to claim this problem is not likely to occur in "real diverse networks". Most importantly, the description of problem does not pose any special conditions on the environment, i.e it may happen in any network, where a router has to drop TCP packets across several links almost at the same time, which leads to a nearly simultaneous retransmission as soon as these packets timeout. It is true that different hosts may follow different TCP congestion avoidance algorithms, but there are just a few widespread versions of such algorithms, and only some of them (like in BSD) are implemented so that the timeout is slightly randomized. So, in practice if the router uses tail drop congestion avoidance, this setup is quite likely to occur in a network like the Internet. —Preceding unsigned comment added by 83.254.61.172 (talk) 23:59, 18 October 2009 (UTC)

Meaningless sentence about UDP

Connectionless protocols such as UDP do not experience global synchronization because they ignore (or are not aware of) packet loss

This is meaningless.

UDP does not deal with packet loss (it is packet-loss neutral). It is not unaware of, it simply does not care. OTOH, reliable higher-level protocols care, are aware of, and deal with packet loss. The way some higher protocol does may not be exactly the same as TCP, but it will have similarities, because the context (problem, goal, constraints...) is exactly the same.

Since the design of UDP is basically the opposite of the design of TCP (unconnected, datagram-based, un-acknowledged, no rate limiting vs connected, stream-based, packet acknowledgment, rate control), they can't be used interchangeably, their only common feature being that they are both user protocol (having user chosen ports).

Since they can't be used in the same context, it is particularly absurd to compare problems with TCP with problems with UDP. Even putting them on the same "level" is misleading.

So : removing this sentence. —Preceding unsigned comment added by 212.27.60.48 (talk) 00:49, 9 November 2008 (UTC)