UDP packets loss at Israeli ISPs during peak hours
Nadav Har'El
nyh at math.technion.ac.il
Sun Jul 3 10:19:24 IDT 2011
On Sun, Jul 03, 2011, geoffrey mendelson wrote about "Re: UDP packets loss at Israeli ISPs during peak hours":
> That's 10 years old. Even then it was questionable, UDP packets were
> dropped by ISPs all over the world when congested. That's why I worded
The "expected" behavior is for the IP network to drop packets without regard
to what they are, so that a UDP datagram, a TCP frame, and an ICMP message
should be dropped with equal probability. For TCP this would mean an eventual
retransmission, and for UDP it would mean a lost packet - which protocols
built on UDP should know how to handle.
But there's a subtle and not often-discussed issue. Somehow, the world
managed to agree on a common and "fair" implementation of TCP congestion
avoidance algorithm, so that TCP streams always reduce their sending rate
when faced with packet drops. A "rogue" TCP implementation could obtain
more bandwidth by anyway trying to send more, but somehow (I could never
explain that) OS writers avoided this temptation. But UDP applications,
often don't - they often send packets as quickly as they can, ignoring
"complaints" (in the form of lost packets) from the network. So it's not
entirely suprising - even if annoying - that there is an "arms race"
between ISPs and UDP-based protocols :(
> With an uncrowded network, UDP makes more sense because there is a lot
> of overhead in TCP you don't need. In a crowded network, where UDP
> packets get dropped or delayed, like the are supposed to. TCP is a
> better option.
Unless you think that with UDP, you can use more than your fair share
that you'd get with a (single) TCP stream. To screw you back, the ISP
can deliberately drop UDP packets :(
> FTP was built on neither. The FTP protocol uses UDP, but includes a
> rudimentry implementation of the same functions as TCP (packet
> sequencing and replacements of bad/missing packets).
This is not quite true - FTP uses TCP, not UDP. It actually uses (in its
original design) two TCP connections - one for commands and one for data.
DNS is one of the few common protocols that can (optionally) use UDP.
Another is (again, optionally) NFS.
> IMHO it all depends upon what you are using the VPN for. For watching
> the "footie" on the "telly" then I would chose UDP with no problem,
> even when there would be significant drop outs. For a business VPN
> where I'm editing text or filling out forms, or whatever, TCP would be
> required as you want to see and send every packet of data. YMMV.
But what if you want to do VOIP over your VPN?
Sorry, but to me it indeed sounds more logical to send your VPN packets
over UDP (or, if you're brave, over straight IP), not TCP.
--
Nadav Har'El | Sunday, Jul 3 2011, 1 Tammuz 5771
nyh at math.technion.ac.il |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |He who dies with the most toys is still
http://nadav.harel.org.il |dead -- Citibank billboard, Manhattan 2001
More information about the Linux-il
mailing list