Re: UDP packets loss at Israeli ISPs during peak hours
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 n...@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 ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: UDP packets loss at Israeli ISPs during peak hours
We are all familiar with UDP vs. TCP tradeoff, but I think it is quite irrelevant in the context. The OP sees 50% packet loss through ISP#1 and zero packet loss through ISP#2. I do not think that one can claim that 50% loss is "normal" for UDP and the network works "as designed". The "upper" TCP will be able to cope with a relatively small loss rate in the lower layer, but 50% is not reasonable. What to do may depend on several factors (in no particular order): 1) Is VPN over TCP significantly slower (higher latency) off-peak? 2) Does changing the UDP ports (if at all possible) help? 3) Is ISP#1 a lot cheaper than ISP#2? 4) ISP#1 does not even provide reasonably reliable DNS? Hmm... 5) Can the exact reason for the loss be determined? If it is shaping then there may be a chance that after a determined complaint things will get better for a specific customer. If it is overcommitment and general lack of resources any improvement is unlikely, IMHO. This may be discovered by playing with ports. -- Oleg Goldshmidt | o...@goldshmidt.org ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: UDP packets loss at Israeli ISPs during peak hours
On Jul 3, 2011, at 10:25 AM, Oleg Goldshmidt wrote: We are all familiar with UDP vs. TCP tradeoff, but I think it is quite irrelevant in the context. The OP sees 50% packet loss through ISP#1 and zero packet loss through ISP#2. I do not think that one can claim that 50% loss is "normal" for UDP and the network works "as designed". The "upper" TCP will be able to cope with a relatively small loss rate in the lower layer, but 50% is not reasonable. However Oleg, you are missing an important bit of information. Since there is no such thing as an "internet", one ISP can not be assumed to be at all like another. In the real world, such things are determined by how good the connection is from you to them, with several ISPs and different routes in between. Usually it means how well does your ISP's ISP connect to their ISP's ISP, or even multiple levels of ISPs. Then on top of it all, it depends upon the load on any leg of the trip. As an example, I used to have a VoIP provider that was connected in the US to an ISP with an excelent connection to my ISP. Then some idiot cut most of the fiber optic cables from Egypt (where all the Arab countries routed their data) and they scambled to get any connectivity at all. Well money talks, and they were able to replace their broken connections with new ones and got back most of their connectivity. This changed the loading on the international circuits and caused the rates for data to go up significantly (or the data rates to go down). My VoIP provider's ISP re-routed their connections from dedicated lines across the Atlantic which they no longer could afford to shared circuits terminating in London. So what was 180ms ping time became 500 or more, causing my VoIP connection to fail. A call to tech support, who made a call to their tech support, who "fixed" things. Bottom line, as it were is that you can not compare the performance outside of Israel between ISPs. You actually can't compare it in Israel too, but that's a different matter. Geoff. -- Geoffrey S. Mendelson, N3OWJ/4X1GM Making your enemy reliant on software you support is the best revenge. ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: UDP packets loss at Israeli ISPs during peak hours
On Sun, Jul 03, 2011 at 08:25:27AM +0300, geoffrey mendelson wrote: > 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). FTP? TFTP? -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Job Offer, for Freelancers in Linux System area
Hello, I'm looking for freelancers (more then one) that are Linux system guys. The job is to help me provide SLA to my clients as a backup for myself. The people I'm looking for need to be able to provide receipts on the payment, and are עוסק מורשה/פטור (Don't know how to explain it in English). The job is done remotely using VPN and ssh (on CentOS servers). The freelancers need to be able to do the following: * Read and understand logs * Capable of communicating in English * Able to communicate with clients that does not know Linux and sometimes even technical stuff. * Able to solve problems that occurs, or understanding that the servers does not have any problem at all. It does not matter to me where is the geographical location of the freelancers, so you can be anywhere ... If you are interested, or know anyone that can be interested in it, please replay in private message. Thanks, Ido LINESIP - Opening the source for communication http://www.linesip.com http://www.linesip.co.il ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: UDP packets loss at Israeli ISPs during peak hours
On Sun, Jul 3, 2011 at 11:23 AM, geoffrey mendelson wrote: > However Oleg, you are missing an important bit of information. Since there > is no such thing as an "internet", one ISP can not be assumed to be at all > like another. In the real world, such things are determined by how good the > connection is from you to them, with several ISPs and different routes in > between. > > Usually it means how well does your ISP's ISP connect to their ISP's ISP, or > even multiple levels of ISPs. No, Geoff, I am not missing that. What you are saying is that the 50% loss is over the whole path that includes numerous "autonomous systems" (AS), and not all of it may occur inside the ISP's network. While this is obviously correct, if the path to ISP#1 is lousy and the path to ISP#2 isn't, the only thing that you, the customer, can control is the choice between the two. How the packets are routed between ASes is out of scope and, frankly, should not interest you very much. It should interest the ISP, and your suggestion to give them a chance to fix their connectivity certainly has merit. Besides, paths are complicated if the OP is trying to connect to his office through an Israeli ISP from, say the US or Australia. If the whole path is inside Israel then the number of ASes along the path is actually small to trivial. -- Oleg Goldshmidt | o...@goldshmidt.org ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: UDP packets loss at Israeli ISPs during peak hours
On Jul 3, 2011, at 12:39 PM, Tzafrir Cohen wrote: FTP? TFTP? You're right, I think I confused the two. Regular FTP uses TCP. Geoff. -- Geoffrey S. Mendelson, N3OWJ/4X1GM Making your enemy reliant on software you support is the best revenge. ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: UDP packets loss at Israeli ISPs during peak hours
On Jul 3, 2011, at 2:39 PM, Oleg Goldshmidt wrote: No, Geoff, I am not missing that. What you are saying is that the 50% loss is over the whole path that includes numerous "autonomous systems" (AS), and not all of it may occur inside the ISP's network. yes. While this is obviously correct, if the path to ISP#1 is lousy and the path to ISP#2 isn't, the only thing that you, the customer, can control is the choice between the two. How the packets are routed between ASes is out of scope and, frankly, should not interest you very much. It should interest the ISP, and your suggestion to give them a chance to fix their connectivity certainly has merit. For example, last night, I have redundant connectivity, with different methods of connecting to an ISP and two different ISPs. Last night a SKYPE call on one kept dropping, so I switched to the other, where it went on for an hour with no drops. Not very usefull ancedotal evidence, but for me it worked. :-) Besides, paths are complicated if the OP is trying to connect to his office through an Israeli ISP from, say the US or Australia. If the whole path is inside Israel then the number of ASes along the path is actually small to trivial. Sorry, I ASSUMED he was talking about paths outside of Israel. If he's talking about paths inside of Israel the best thing he could do IMHO is to buy an NGN line for the connection, route it through the same ISP as the destination and use it as a static route on those systems that need to connect to it. For example, if their current router is at 192.168.1.1 add the new one at 192.168.1.2 and have a route for the server (or subnet) it is on via 192.16.8.1.2, with the defalt route still being 192.168.1.1. I have my DHCP servers set up to route a particular system via one of the lines or the other, and shell scripts/batch files to switch as necessary. Geoff. -- Geoffrey S. Mendelson, N3OWJ/4X1GM Making your enemy reliant on software you support is the best revenge. ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Hebrew fonts on digital readers
FWIW, this is not the same discussion as far as I am concerned. The previous discussion was about what reader is best for Hebrew book. This one is about how to read Hebrew on a Kindle 2. I am not going to buy eVrit, nor any book with DRM on it, if I can help it. On Sat, Jun 25, 2011 at 11:01 PM, geoffrey mendelson < geoffreymendel...@gmail.com> wrote: > Didn't we this discussion a couple of months ago? From what I can see > nothing has changed. I think in the end the person asking bought an eVrit, > which is really a PanDigital Memo with Hebrew support and Steimatzky DRM > built in. > > Are they still 900 NIS? > > Geoff. > > > -- > Geoffrey S. Mendelson, N3OWJ/4X1GM > Making your enemy reliant on software you support is the best revenge. > > > > > > > > > > > > ___ > Linux-il mailing list > Linux-il@cs.huji.ac.il > http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il > -- Check out my web site - www.words2u.net ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
