The beauty of TCP/IP

Discussion in 'Java' started by Roedy Green, Dec 23, 2005.

  1. Roedy Green

    Roedy Green Guest

    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.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
     
    Roedy Green, Dec 23, 2005
    #1
    1. Advertising

  2. "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.

    --
    LTP

    :)
     
    Luc The Perverse, Dec 23, 2005
    #2
    1. Advertising

  3. Roedy Green

    Roedy Green Guest

    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, Dec 24, 2005
    #3
  4. "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.


    Ah thanks - that works well.

    --
    LTP

    :)
     
    Luc The Perverse, Dec 24, 2005
    #4
  5. Roedy Green

    E.J. Pitt Guest

    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.


    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.
     
    E.J. Pitt, Dec 27, 2005
    #5
  6. Roedy Green

    E.J. Pitt Guest

    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.
     
    E.J. Pitt, Dec 27, 2005
    #6
  7. "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.

    --
    LTP

    :)
     
    Luc The Perverse, Dec 27, 2005
    #7
  8. Roedy Green

    Roedy Green Guest

    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.


    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
     
    Roedy Green, Dec 27, 2005
    #8
  9. Roedy Green

    Roedy Green Guest

    On Tue, 27 Dec 2005 03:04:49 -0700, "Luc The Perverse"
    <> wrote, quoted or indirectly
    quoted someone who said :

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


    Why does Grandma want to know this?
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
     
    Roedy Green, Dec 27, 2005
    #9
  10. "Roedy Green" <> wrote in
    message news:...
    > On Tue, 27 Dec 2005 03:04:49 -0700, "Luc The Perverse"
    > <> wrote, quoted or indirectly
    > quoted someone who said :
    >
    >>While I appreciate your effort - I have more faith in the bucket brigade
    >>idea :) Maybe it's just cause I know my grandma.

    >
    > Why does Grandma want to know this?



    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.

    --
    LTP

    :)
     
    Luc The Perverse, Dec 27, 2005
    #10
  11. Roedy Green

    E.J. Pitt Guest

    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.
     
    E.J. Pitt, Dec 28, 2005
    #11
  12. Roedy Green

    Roedy Green Guest

    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.

    Here is a typical local tracert:


    1 <10 ms <10 ms <10 ms router [192.168.0.1]
    2 43 ms 23 ms 23 ms shawgateway [24.69.120.1]
    3 25 ms 23 ms 23 ms rd1cv-ge3-1-2.gv.shawcable.net
    [64.59.166.98]
    4 27 ms 24 ms 23 ms rd2cv-pos0-0.gv.shawcable.net
    [66.163.72.1]
    5 27 ms 29 ms 30 ms rc1wt-pos2-1.wa.shawcable.net
    [66.163.77.21]
    6 28 ms 29 ms 29 ms rc2wt-pos1-0.wa.shawcable.net
    [66.163.68.2]
    7 27 ms 29 ms 29 ms rx0wt-abovenet.wa.shawcable.net
    [66.163.68.22]
    8 29 ms 29 ms 30 ms 209.249.11.173.data-fortress.com
    [209.249.11.173
    ]
    9 31 ms 35 ms 29 ms a.cust.65-110-0-2.van.data-fortress.com
    [65.110.
    0.2]
    10 43 ms 38 ms 34 ms mindprod.com [65.110.20.44]
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
     
    Roedy Green, Dec 28, 2005
    #12
  13. Roedy Green

    Roedy Green Guest

    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?
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
     
    Roedy Green, Dec 28, 2005
    #13
  14. 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. :)

    ----Scott.
     
    Scott W Gifford, Dec 29, 2005
    #14
  15. Roedy Green

    E.J. Pitt Guest

    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.
     
    E.J. Pitt, Dec 29, 2005
    #15
  16. Roedy Green

    E.J. Pitt Guest

    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?
     
    E.J. Pitt, Dec 29, 2005
    #16
  17. Roedy Green

    Roedy Green Guest

    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.

    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
     
    Roedy Green, Dec 29, 2005
    #17
  18. Roedy Green

    E.J. Pitt Guest

    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, Dec 30, 2005
    #18
  19. Roedy Green

    Chris Smith Guest

    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.

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

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
     
    Chris Smith, Dec 30, 2005
    #19
  20. Roedy Green

    Roedy Green Guest

    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.
     
    Roedy Green, Dec 30, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Frank
    Replies:
    1
    Views:
    397
    Aleksander Straczek
    Nov 22, 2004
  2. Sharp Tool

    Solve this beauty

    Sharp Tool, Oct 27, 2005, in forum: Java
    Replies:
    19
    Views:
    619
    Roedy Green
    Oct 28, 2005
  3. Replies:
    1
    Views:
    1,707
    Paul McGuire
    Sep 19, 2006
  4. Replies:
    0
    Views:
    316
  5. Replies:
    0
    Views:
    286
Loading...

Share This Page