[wplug] Verizon DSL service downgrade

[Michael Semcheski]

Zach wrote:
> Is this 10% overhead for TCP documented in any literature I can read?
>  Also do you know there is any overhead associated with UDP.

Alas, the 10% overhead I spoke of is not necessarily due to TCP but
probably ATM.

http://maxolasersquad.com/network/chapter18.html


There is an overhead with TCP due to the syn-syn/ack-ack set up. 
There's also the issue of window sizes.  If you don't acknowledge that
you've received data quickly enough, the window will be filled up and
the server will be waiting for you to tell it to send more.  So sending
requires some downstream bandwidth (to receive ack's) and receiving
requires some upstream (to send ack's).  I know that in the bsd tool pf,
you can set up bandwidth queues, and add different types of packets to
different queues.  Thus, you can assure that you have room to send
ack's.  (This only works in one direction, since you can't prioritize
what you receive, only what you send.)

UDP has less overhead and less reliability.  The sender just sends the
packets and doesn't really care if you receive them or not.  In some
cases, such as for control of a real-time system, this is more
important.  I might send status updates over UDP, because to the
receiver, its not important what the state was, just what the state is. 
If a packet gets dropped, I don't want to bother holding up the stream
to find out what the value was at some previous time.  I just want to
know what it is _now_.  If you have a system where end-to-end, you know
there won't be any packet loss, and all packets will arrive in the
correct order, then the overhead of TCP might make UDP more attractive. 
(Even if, as the article I cited states, TCP's overhead is only 1.5%.)

I'm hardly an expert in this field, so I suggest you don't rely on what
I say too heavily, but use it to refine your own information gathering
as appropriate.  Or, if anyone sees anything inaccurate in what I've
written, do correct me.


Mike