UDP packets loss at Israeli ISPs during peak hours

[shimi]

On Sun, Jul 3, 2011 at 8:25 AM, geoffrey mendelson <
geoffreymendelson at gmail.com> wrote:

>
> On Jul 3, 2011, at 8:02 AM, shimi wrote:
>
>>
>> There's a very good reason of using UDP and not TCP for tunneling.
>> http://sites.inka.de/bigred/**devel/tcp-tcp.html<http://sites.inka.de/bigred/devel/tcp-tcp.html>
>>
>
>
>
> 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 my
> answer the way I did. If you understand what the differences are between TCP
> and UDP, you understand the risks, costs and benefits.
>
>
Not sure I follow the "10 years ago" reasoning; Is it your claim that TCP of
10 years ago, and UDP of 10 years ago, are working _differently_ than the
way they work today? (I hope not, I still believe Operating Systems from 10
years ago work Just Fine on today's "Internet")

Or is it your claim that UDP packets are not dropped by ISPs? (If not, read
again what the thread opener complained about: just that!)


> 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.
>
>
That's right, but if you're encapsulating TCP within UDP, and UDP is
unreliable, this is just as bad as sending normal TCP over IP. IP is
unreliable, and so is UDP. You don't need to run TCP with its' overhead
*twice*, with the exponential growth of timeouts as explained in the
article. The encapsulated TCP would do what's needed (retransmission,
reordering, etc) - why would you need to retransmit and reorder _twice_ ? It
doesn't make sense.


> It depends upon what you want. Fast performace with drop outs, or slower
> more reliable performance. For example, VoIP normally uses UDP as the
> desingers prefered to drop packets that arrived out of sequence or late, a
> little sound glitch was worth it for better streaming performance.
>
> HTTP was built around TCP because the designers wanted 100% reliablilty
> instead of (possible) better performance.
>
> 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).
>
> 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.
>
>
Again, you *are* using TCP for the 'reliable' protocols, even on UDP. The
tunnelled TCP would do what's expected from it to do; You don't need to do
it twice. My opinion, at least.


> As for dealing with your ISP, if you want dedicate bandwidth, buy dedicated
> bandwidth. If you want random performance based on the low price plan, don't
> expect them to make it better.
>
>
You would think that a circuit that costs thousands of dollars a month would
have such a reliability build in, no? (and it doesn't, not in our
country...)

-- Shimi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20110703/b634dcce/attachment-0001.html>