[p2p-hackers] p2p-hackers Digest, Vol 51, Issue 8

[Ray Dillinger]

On Sun, 2010-11-28 at 01:38 +0700, Jirtme Prudent wrote:
> Hi!
> 
> Sorry for the off topic (and the stupidity of the question), but could
> you briefly explain me what's wrong with the use of UDP?
> 
> Thanks!

HTTP is not specified as a UDP protocol and extant browsers don't 
generally speak UDP.  Aside from that, most of the things 
transmitted by HTTP (coded webpages, client-side programs, and 
compressed graphics) are prone to catastrophic failure from small 
errors, and UDP is prone to small errors. 

UDP does not contain any provision for correction of transmission
errors.  When a packet is transmitted over the internet, there is 
a chance that it will be corrupted en route.  Electrical noise at 
a switch, a radio station too near a cable, cosmic rays, etc...  
these are all things which can cause a bit or byte or word to be 
different at the recieving end than it was at the transmitting end. 

TCP/IP is an error-correcting protocol that uses incremental 
checksums to detect transmission errors, so that the recieving 
end can say, "wait a minute, could you resend packet number 12?"
or something when it realizes that it missed something or got 
a bad copy of something.  This is a good thing because it reduces 
or eliminates errors, but it introduces roundtrip delays as the 
sender and receiver negotiate to make sure all the checksums and 
so on are correct.

HTTP is a TCP/IP protocol that introduces several other mechanisms
to try to deal with its intensive usage of bandwidth, and one of 
these was (is) "slow-start."  "slow-start" says you don't transmit
more than 4 packets before the receiver notifies you about whether 
the first one was received intact.  After the receiver has 
acknolwedged the first 4 packets, you can assume that it's okay 
to have 5 packets "in flight" out there.  After the receiver has 
acknowledged the next 5 packets, you can assume that it's okay to 
have 6 packets "in flight" out there.  And so on.  This whole thing
was an effort not to overrun buffers along the way, not to transmit
faster than the receiver could buffer and process the data, and 
so on.

Slow-start was a good thing when it was developed, because at the 
time network latency was usually a small fraction of transmission
time.  Waiting for the acknowledgement to arrive usually didn't 
noticeably delay the transmission of additional packets.  But 
things have changed.  The bandwidth of our pipes, the size of our 
buffers, and the speed of our transmission has gone way up, 
switching speeds have gone up but have not kept pace, the number 
of hops on the trip from transmitter to receiver is now one or 
two jumps longer which eats the gains from faster switching times, 
and the speed of light has remained obnoxiously constant.  So at 
this point the servers are sending four packets, then twiddling 
their thumbs for a *LONG* time (relative to the time it takes to 
transmit them) before the acknowledgement packet gets back and 
they can send the next packets.  

Google wants to change slow-start by increasing the initial number 
of packets to compensate for the increases in buffering capability
and pipe length relative to transmission speed.  I think this is 
probably a good idea.  

				Bear


_______________________________________________
p2p-hackers mailing list
p2p-hackers at lists.zooko.com
http://lists.zooko.com/mailman/listinfo/p2p-hackers

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE