Re: NAT2NAT & TCP -- useful for P2P?
> Lastly, why would UDP acks (which you'd need for aBecause of flexibility of when, how and what to ack. For example,
> reliable UDP protocol) be less costly than TCP ones?
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
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.That's my impression, too, especially for the larger
> Anybody have any hard data on this?
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
- Justin Chapweske wrote:
> interesting techniques used in the (I think) TCP-Reno implementation whereSome of this happens automatically in that new packet transmissions are
> it can guestimate congestion w/o packet loss based off of latencies.
triggered by the receipt of acks, which will be delayed if queues are growing
in the network.