The beauty of TCP/IP

The throughput does not depend on how many hops it takes to get to
you. It depends on the speed of the slowest hop, which would normally
be the one next to you or next to the server. TCP/IP is like a very
long train of packets with many in flight at once. There is no fixed
path for packets.

A highspeed middle link could be the bottleneck if it were the most
congested.

On the other hand if you send a datagram and send a datagram in
return, the response time depends on the number of hops.

So even though the Internet is designed at the fundamental level
around delivery of individual packets, it is most efficient when
delivering streams.
--
Canadian Mind Products, Roedy Green.http://mindprod.com Java custom programming, consulting and coaching.

Advertisements

"Roedy Green" <> wrote in
message news:...
>I was thinking about a pleasing feature of TCP/IP.
>
> The throughput does not depend on how many hops it takes to get to
> you. It depends on the speed of the slowest hop, which would normally
> be the one next to you or next to the server. TCP/IP is like a very
> long train of packets with many in flight at once. There is no fixed
> path for packets.
>
> A highspeed middle link could be the bottleneck if it were the most
> congested.
>
> On the other hand if you send a datagram and send a datagram in
> return, the response time depends on the number of hops.
>
> So even though the Internet is designed at the fundamental level
> around delivery of individual packets, it is most efficient when
> delivering streams.

Yes - now come up with a way for me to explain to my grandma the difference
between latency and throughput - because thus far people just don't get it.

Advertisements

On Fri, 23 Dec 2005 15:50:08 -0700, "Luc The Perverse"
<> wrote, quoted or indirectly
quoted someone who said :
>Yes - now come up with a way for me to explain to my grandma the difference
>between latency and throughput - because thus far people just don't get it.

The difference between one guy with a bucket and a bucket brigade. The
bucket does not get there much faster by brigade, but more buckets per
minute do.
--
Canadian Mind Products, Roedy Green.http://mindprod.com Java custom programming, consulting and coaching.

"Roedy Green" <> wrote in
message news:...
> On Fri, 23 Dec 2005 15:50:08 -0700, "Luc The Perverse"
> <> wrote, quoted or indirectly
> quoted someone who said :
>
>>Yes - now come up with a way for me to explain to my grandma the
>>difference
>>between latency and throughput - because thus far people just don't get
>>it.
>
> The difference between one guy with a bucket and a bucket brigade. The
> bucket does not get there much faster by brigade, but more buckets per
> minute do.

"E.J. Pitt" <> wrote in message
news:UJ7sf.114266$...
> Luc The Perverse wrote:
>
>> Yes - now come up with a way for me to explain to my grandma the
>> difference between latency and throughput - because thus far people just
>> don't get it.
>
> The difference between a truckload of tapes and a modem. The truck has
> high bandwidth, long latency, the modem has low bandwidth, short latency.

While I appreciate your effort - I have more faith in the bucket brigade
idea Maybe it's just cause I know my grandma.

On Tue, 27 Dec 2005 08:26:24 GMT, "E.J. Pitt"
<> wrote, quoted or indirectly quoted
someone who said :
>> On the other hand if you send a datagram and send a datagram in
>> return, the response time depends on the number of hops.
>
>Not really. Datagrams are routed the same way as TCP segments, so
>consecutive datagrams can take different paths through the network, just
>as TCP segments can.

Even if each packet goes a different route, by slightly different
numbers of hops, the round trip time for the entire packet bundle
depends on the number of hops and the time of each hop, or more
precisely the case for the worst subpacket.

She doesn't - she was never interested, and that is likely why she just
couldn't grasp it.

It came up once a long time ago in a conversation with her.

The question has come up multiple times though; I remember once trying to
explain to a friend why a modem might be superior to a satelite connection
for playing games. I got through to him, but it was harder than I expected
it to be to explain. The concept seems intuitive to me, so it is my belief
that an example to which someone can relate should aid in making it
intuitive to other people.

Roedy Green wrote:
>>>On the other hand if you send a datagram and send a datagram in
>>>return, the response time depends on the number of hops.
>> [I wrote:]
>>Not really. Datagrams are routed the same way as TCP segments, so
>>consecutive datagrams can take different paths through the network, just
>>as TCP segments can.
>[Roedy Green wrote:]
> Even if each packet goes a different route, by slightly different
> numbers of hops, the round trip time for the entire packet bundle
> depends on the number of hops and the time of each hop, or more
> precisely the case for the worst subpacket.

(a) Subpackets have nothing to do with it. A fragemented UDP datagram
will never be reassembled.

(b) Even if it was, why is this different from TCP/IP? RTT depends on
the total latency between endpoints. It doesn't really depend on the
number of hops, just one hop with a large latency will mostly determine
the RTT.

On Wed, 28 Dec 2005 08:20:04 GMT, "E.J. Pitt"
<> wrote, quoted or indirectly quoted
someone who said :
>(b) Even if it was, why is this different from TCP/IP? RTT depends on
>the total latency between endpoints. It doesn't really depend on the
>number of hops, just one hop with a large latency will mostly determine
>the RTT.

Performance in TCP/IP depends on throughput, packets per second
arriving. That roughly depends on the time to traverse the worst hop.
One hop becomes the bottleneck in the train. Speeding up the other
hops won't help, same a traffic. So, oddly, having many hops won't
necessarily hurt performance.

Performance in UDP depends on end-to-end time. It is the sum of all
the hops. The more hops you have the slower it will be.

The definitive source is RFC 791. My reading is that fragmentation
and reassembly happen at the IP layer, below UDP, and therefore
fragmented UDP packets will always be reassembled. Some features
present in the UDP protocol (RFC 768), such as checksums, wouldn't
work without reassembly, suggesting this is a correct interpretation.

What UDP/IP stacks do in real life may be another story, so the real
definitive answer might come from sending some test packets across a
network and seeing what comes out the other side. Or from a network
guru, if any are handy.

Scott W Gifford wrote:
> Roedy Green <> writes:
>
>
>>On Wed, 28 Dec 2005 08:20:04 GMT, "E.J. Pitt"
>><> wrote, quoted or indirectly quoted
>>someone who said :
>>
>>
>>>(a) Subpackets have nothing to do with it. A fragemented UDP datagram
>>>will never be reassembled.
>>
>>You and Gordon disagree on this. Where is the definitive
>>documentation?
>
>
> The definitive source is RFC 791. My reading is that fragmentation
> and reassembly happen at the IP layer, below UDP, and therefore
> fragmented UDP packets will always be reassembled. Some features
> present in the UDP protocol (RFC 768), such as checksums, wouldn't
> work without reassembly, suggesting this is a correct interpretation.
>
> What UDP/IP stacks do in real life may be another story, so the real
> definitive answer might come from sending some test packets across a
> network and seeing what comes out the other side. Or from a network
> guru, if any are handy.

Well I thought I was one ;-) but Gordon is correct. Reassembly takes
place at the IP layer as the RFC and Stevens vol I & II make clear. So
UDP datagrams can be reassembled. What *won't* happen is retransmission
of a component part if it is lost, unlike TCP.

Roedy Green wrote:
> Performance in TCP/IP depends on throughput, packets per second
> arriving. That roughly depends on the time to traverse the worst hop.
> One hop becomes the bottleneck in the train. Speeding up the other
> hops won't help, same a traffic. So, oddly, having many hops won't
> necessarily hurt performance.
>
> Performance in UDP depends on end-to-end time. It is the sum of all
> the hops. The more hops you have the slower it will be.

I'm sorry, I still don't understand what the difference you are talking
about actually is. Performance *is* throughput, surely? bytes per
second? and surely this is a linear function of delay at each hop and
number of hops? in both cases?

On Thu, 29 Dec 2005 08:18:04 GMT, "E.J. Pitt"
<> wrote, quoted or indirectly quoted
someone who said :
>I'm sorry, I still don't understand what the difference you are talking
>about actually is. Performance *is* throughput, surely? bytes per
>second? and surely this is a linear function of delay at each hop and
>number of hops? in both cases?

No. Let me try once again. What counts with TCP/IP doing a long file
download is how many bytes per second come through the spigot. If
would not matter if each individual packet took 60 seconds to wend its
way through the packet net. Thus the number of hops is not critical.
What is critical is the bottleneck hop. (which varies since packets
don't take the precise same route). The response time of the server is
not critical either, so long as it can keep the pipeline filled.

For a Datagram, what counts is the round trip time for one packet to
make it to the server and for a response to be formulated and a packet
send back. Thus every hop is critical, and the number of hops are
critical.

Roedy Green wrote:
> No. Let me try once again. What counts with TCP/IP doing a long file
> download is how many bytes per second come through the spigot. If
> would not matter if each individual packet took 60 seconds to wend its
> way through the packet net. Thus the number of hops is not critical.
> What is critical is the bottleneck hop. (which varies since packets
> don't take the precise same route). The response time of the server is
> not critical either, so long as it can keep the pipeline filled.
>
> For a Datagram, what counts is the round trip time for one packet to
> make it to the server and for a response to be formulated and a packet
> send back. Thus every hop is critical, and the number of hops are
> critical.

So you are comparing apples and oranges: bandwidth in TCP and latency in
UDP. So?

I also don't see how this justifies your original statements that the
Internet 'is most efficient when delivering streams' or that the number
of hops is the critical element in UDP timings.

E.J. Pitt <> wrote:
> So you are comparing apples and oranges: bandwidth in TCP and latency in
> UDP. So?
>
> I also don't see how this justifies your original statements that the
> Internet 'is most efficient when delivering streams' or that the number
> of hops is the critical element in UDP timings.

It was phrased in a confusing way. However, I'd agree that the Internet
is most efficient when delivering "streams"... that is, when delivering
large amounts of one-way data whose transfer time with the available
bandwidth dwarfs the communication latency. Whether these streams are
delivered via TCP or UDP is, of course, pretty much irrelevant to the
fact being discussed. I think that's led to a little confusion here.

I think Roedy's logic is that streams of large amounts of data are most
likely to be done via TCP rather than UDP, and therefore there exists
some correlation between TCP and more efficient applications. I'm not
so sure that correlation is real, though. Downloading of FILES for
local storage and later use would be done with TCP. However, online
viewing of real-time media such as video or audio is more commonly done
with UDP (and, confusingly, in a way that's also known as "streaming")
because a late packet is no good... if I miss a frame of the video,
that's fine; and I don't want to delay the receipt of the later frames
until the server can retransmit that frame that was missed. Hence,
streaming live audio/video is a counterexample to pushing this into the
TCP/UDP division.

On Fri, 30 Dec 2005 08:58:47 -0700, Chris Smith <>
wrote, quoted or indirectly quoted someone who said :
>I think Roedy's logic is that streams of large amounts of data are most
>likely to be done via TCP rather than UDP, and therefore there exists
>some correlation between TCP and more efficient applications

I was not trying to make any such statement. I was trying to point
out that UDP and TCP/IP stream performance depend on different
characteristics of the connection. Either you have a continuous
stream of data or you have intermittent packets. Even if you were to
use TCP/IP for exchanging intermittent packets, it will behave from a
performance point of view like UDP.

I thought I was stating something almost too obvious to mention, but
apparently it is not.
--
Canadian Mind Products, Roedy Green.http://mindprod.com Java custom programming, consulting and coaching.

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!