Re: The beauty of TCP/IP

E.J. Pitt <esmond.not.pitt@xxxxxxxxxxxxxxx> wrote:
> Roedy Green <my_email_is_posted_on_my_website@xxxxxxxxxxxxxx> writes in
> his Glossary:
> >
> > However, if I were writing an
> > application that needed to wait for acknowledgement from the other
> > side, I would almost certainly be using TCP. Hence, on average,
> > UDP (datagram) applications probably get better performance
> > (in terms of bandwidth) than TCP applications...

No, he didn't. That was me, suggesting to Roedy how I would change the
statement from his glossary, which I believe is incorrect.

> Roedy, I don't follow the logic here at all. (a) The 'hence' does not
> follow from what precedes; (b) if you needed to wait for an
> acknowledgement you would probably not be taking advantage of windowing,
> so why would you 'almost certainly be using TCP'?

The logic is as follows:

Applications with round-trips (i.e., they wait on a response from the
remote host) get lower bandwidth than applications that do not do so.
Since waiting for a response assumes that it matters whether the
response comes, such applications also need a reliable transport
protocol and almost certainly would be implemented with TCP.

So applications that stream large amounts of data (and get better
bandwidth) may be written in TCP or UDP. Applications that do frequent
round trips, on the other hand, are written almost exclusively in TCP.
On average, TCP will see lower bandwidth because it includes
applications that do round-tripping.

> > ... but because of the
> > nature of the problems they solve, not because TCP is somehow
> > inherently inferior. The median is probably about the same."
>
> I don't know who said TCP is 'inferior'

It was pre-empting a conclusion that seemed likely from the kind of
logic in the original article.

> ; I still don't know who is comparing apples and oranges;

It's my believe that Roedy is.

> I don't know what this 'median' could possibly be measured with;

It's a guess. Jeez, I'm not defending a dissertation here. Do you have
any reason to believe it's a bad guess?

> and I still don't know why you refuse to add
> up latencies over a path. Your oft-repeated statement that the number of
> hops in UDP is critical assumes that all hops have the same latency,
> which is untrue.

I don't think Roedy really does refuse to add latencies over a path.
I've been reading this thread, and I've never seen him refuse.

Roedy is also not defending a dissertation. So yeah, of course latency
at each hop differs. Nevertheless, as a general trend, an IP packet
sent over more hops is going to experience higher latency than an IP
packet sent over fewer hops. That's a _perfectly_ reasonable statement,
in absence of specific reason to believe that the longer path has
significantly lower latency per hop.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
.

Relevant Pages

  • Re: Internal TCP/IP send buffer?
    ... and that has to be decided at your proxy server. ... UDP or a separate TCP connection to the target and periodically ... connections) constitutes a completely different source of latency. ...
    (microsoft.public.win32.programmer.networks)
  • Re: Old TCP connections after IP address change
    ... > applications can enable TCP keepalive probes and TCP on the server ... linux box to establish the PPPoE connection. ... > is a change might work, depending on how the applications react ...
    (comp.os.linux.networking)
  • Re: Old TCP connections after IP address change
    ... the function not the script). ... applications can enable TCP keepalive probes and TCP on the server ... /* Bluffing in a poker game can win big; ...
    (comp.os.linux.networking)
  • TCP works but the UDP doesnt
    ... Till now I have been running TCP applications over it and they have ... I get and I am getting 70-80 Mega bytes per second at TCP level. ... Now I have shifted to test UDP applications, ... I am confused because with TCP burst of 16000 bytes do not fail and the ...
    (comp.os.vxworks)
  • Linux TCP - unexpected retransmissions
    ... small messages using TCP. ... This latency occurs randomly ... time (segment 5 and 6 below), for unknown reasons, the second TCP does ... three instances of a retransmission. ...
    (comp.os.linux.networking)