Loading ...
Sorry, an error occurred while loading the content.

Re: NAT2NAT & TCP -- useful for P2P?

Expand Messages
  • egroup@omegapoint.com
    ... Because of flexibility of when, how and what to ack. For example, in almost any larger data transfer the sender (at some level) does know upfront how much
    Message 1 of 69 , Mar 1, 2001
    View Source
    • 0 Attachment
      > Lastly, why would UDP acks (which you'd need for a
      > reliable UDP protocol) be less costly than TCP ones?

      Because of flexibility of when, how and what to ack. For example,
      in almost any larger data transfer the sender (at some level)
      does know upfront how much the request will contain. Similarly,
      the sender and the receiver know fairly well how much buffers
      they can dedicate to the task. Once all such information is
      shared upfront with the destination(s), they can set up
      a schedule for the entire transfer with, say a fixed fragment
      sizes and known number of fragments, known receivers' buffer
      sizes,...etc, so that much less ack-ing, flow control and packet
      header overhead is needed for the bulk of transfers (including
      any _future_ transfers, since the peers can keep the mutual
      information & arrangements over any length of time, with or
      without being 'online' in every intermediate moment).

      With that type of arrangement the receivers can request, in
      accordance with the pre-arranged ack/job schedule, which
      individual packets, from anywhere in the job, they need
      resent, instead of dropping everything onward from the
      point of a bad packet. If you also include multipoint
      connections (beyond the binary), a whole universe of other
      useful possibilities of optimization opens up (e.g. things
      like 'swarmcast').

      Many more things are possible, once you recognize that a
      protocol doesn't have to model its task as 1-dimensional
      tape-like octet stream between the two points only and no
      more, and that the entire shared control info and the state
      diagram have to be small enough to fit entirely in the
      CPU registers of a typical mini from the late 1970s and
      that the total number of possible states must be enumerable
      with the fingers of two hands in radix 1. But if, for
      some peculiar reason, you have set out to satisfy all
      the constraints listed, then you're right -- the TCP is
      probably just about the best you can do.


      > I still suspect routers drop UDP packets before TCP.
      > Anybody have any hard data on this?

      That's my impression, too, especially for the larger
      bursts of packets. But in many cases, where I initially
      blamed the outside routers, a close inspection with a
      packet monitor had showed that it was the local Microsoft's
      stack which failed to follow the best effort delivery
      guideline, and had failed to reassemble and deliver many
      perfectly good sets of IP packets to the UDP socket
      (after they have reached their destination and there
      were more than enough internal receive buffers to hold
      them).
    • Tim Dorcey
      ... Some of this happens automatically in that new packet transmissions are triggered by the receipt of acks, which will be delayed if queues are growing in
      Message 69 of 69 , Mar 2, 2001
      View Source
      • 0 Attachment
        Justin Chapweske wrote:

        > interesting techniques used in the (I think) TCP-Reno implementation where
        > it can guestimate congestion w/o packet loss based off of latencies.

        Some of this happens automatically in that new packet transmissions are
        triggered by the receipt of acks, which will be delayed if queues are growing
        in the network.

        Tim
      Your message has been successfully submitted and would be delivered to recipients shortly.