Slashdot Mirror
UDP - Packet Loss in Real Life?
PacketStorm asks: "There's always an argument between TCP and UDP users. TCP users complain that UDP is non-determinstic and lossy, while UDP users complain that TCP is slower and nobody needs all the features anyway. So the question is - has anyone actually seen/experienced UDP loss in high-traffic environments? Is the degeneration of UDP any better or worse than TCP in a congested environment? TCP also craps out in times of congestion, but at least you know - or do you? Experiences?"
I don't know if it means anything, but I have experienced UDP packet loss on a regular basis -- playing online games. Unit positions are most often tracked over UDP because it doesn't really matter if things warp around a little when the client receives an update that puts a unit somewhere other than where the client extrapolated it was. There was a big fiasco at launch-time for Anarchy Online -- they used TCP and not UDP for about 8 hours, during which time the game was unplayable because the servers couldn't maintain all the TCP connections. Interpret this as you will.
UDP for streaminig video and games and other sorts of things where it doesn't matter if you miss a couple of packets and TCP where you can't miss packets such as file transfers. There everyone happy go home now.
this is the most important sig ever! In your face 446154!
Check the Internet Traffic Report
UDP is commonly used in games and other time sensitive environments precisely because it lacks reliabilty. With time sensitive data (such as streaming video or unit positions in a game), if the data gets dropped it's not worth it to retransmit, because it woudl be out of date. Therefore, the program just transmits the next update and the user sees a small skip. This is better than getting "out of sync".
TCP is designed to make unreliable networks (like the internet, which only gives "best effort delivery") reliable by ensuring that a stream can be reassembled, in order, with no missing pieces. Read the RFC for more info here. This reliability makes it good for things that need zero corruption (file transfers for example), and aren't time criticial.
Hope this helps.
--MonMotha
I'm firmly in the UDP camp. About 4 years ago we replaced our timeclocks at work (manufacturing facility) with hardened, wall-mounted PCs. I wrote a GTK app that started at boot up that takes the users card swipe, grabs their name from the database (for display only), and sends the clock number via UDP to the timeclock server.
:-)
During my initial proposal I mentioned to the PHBs that I would use the UDP protocol. One of my colleagues, wanting to sound important, said that UDP can be lossy. He went on to explain packet loss to the befuddled crowd. Well, the PHBs latched onto the term "packet loss". Packet loss this, packet loss that. They had no freakin' clue what it was, but it sounds pretty cool.
Anyway, I had to set up a test in which I had all of the timeclocks start a program at the same time. This program went into a tight loop of sending UDP packets (clock numbers) across the network to the server. Each one sent 1000 clock numbers, and every single one made it across. Obviously our 100mb network and proper use of subnets helped, but we haven't experienced any packet loss in the four years that these things have been running. So there.
Matthew
/. finds me to be 20% Troll, 80% Funny
I run a cluster of high volume mail servers that use syslog-ng to log to a remote syslog server. This reduces disk IO for each message and actually gives a very noticable performance increase. However, I noticed under periods of very high volume, I was losing nearly 50% of my log entries. Syslog-ng has the ability to use TCP for logging, so I switched, and I haven't lost any entries yet.
UDP is great for things you that aren't useful if retransmitted later, like real time apps (Quake, video streams, audio streams, etc.) But to ensure no loss at all, you need to use TCP.
Need Free Juniper/NetScreen Support? JuniperForum
Jesus. Both have their uses. You use TCP if you need the reliability, and a stateful connection. You use UDP if it doesn't matter that a packet gets dropped here or there. Things like games and streaming media are good examples. This is rather like comparing Pepsi to milk. They both have their place. It's the job of a good engineer to determine which is most apropriate.
never seen udp packet loss over local networks, over the internet, it happens all the time.
why didnt the question asker open his/her copy of stevens ? anyone doing network programming has it on their bookshelf
The only protocol I ever use is ICMP.
- A.P.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
Dude, I hate sound flame-y, but do you have any understanding of what you implemented? That you got lucky and it "works" is totally irrelevent to the fact that it's completely unreliable. All it takes is one flakey piece of Ethernet dropping packets to SCREW UP FREAKING TIMESHEETS.
This reminds me of the morons who use MySQL for financial transactions (i.e., no transactions, no foreign keys, etc) who justify their ignorance with "well, it works so far!!"
They point isn't whether it works or not, the point is that when it fails, it fails spectacularly. Like your system. Just because you can keep spinning the chamber and the russian roulette gun never goes off doesn't mean it never will.
Seriously, you screwed up bad. These are the kinds of stories that really make me think that programmers should have some sort of licensing.
- Automatically and transparently timeout waiting for the packet, and ask for retransmission. In this case, use TCP.
- Anything else. In this case, use UDP.
As an example of "Anything Else" maybe notice that a packet is missing, ask for a retransmission, and draw a little rendered animation of a gerbil chewing on a length of cat5utp in the corner of the screen.Trees can't go dancing
So do them a big favor
Pretend dancing stinks!
Oh, I thought you said package loss
Could you please elaborate on that for me? I always though NTM's (non-determinstic Turing Machines) were so powerful since they always made the "right" decision and didn't need luck or a specific rule set, they just non-determinstically chose the right path.
If you have a network that is just sending packets correctly with out decisions then all the better and we should take it on tour. Maybe, however you're refering to the complete broadcast mentality that packets aren't sent to specific hosts as required but to all hosts since this is how non-determinism is typically simulated, but simulated non-determinism and true non-determinism are a tad different.
Maybe it's just that I don't really know a lot of networking theory, but that term just sort of jumped out at me. I've often equated non-determinism with magic...
Wheeeee
I used to work with a company that sent data (mostly video) to all customers via satellite, in multicast. The uplink went through the terrestrial network. IIRC, the whole traffic was sent over UDP.
Trollem mirabilem hanc subnotationis exigiutas non caperet
I'm a skydiver. I never use a parachute. Instead, I just jump out of planes and hope that I land on a large air mattress. It's worked perfectly so far. Why should I switch? All you silly fools using parachutes make me laugh.
As some people have pointed out, both UDP and TCP have their advantages. Note though, that for some applications you don't want retransmission at all! What's the point in having part of an audio stream retransmitted, or a video stream for that matter? It only makes things worse.
An excellent example comes from my own experience. Years ago we built a system that needed to synchronize system clocks between a server (hooked up to an atomic clock) and a bunch of workstations (I know about NTP, it was just too complicated for our humble needs). The server would broadcast the time over UDP every 30 seconds, and the workstations would synchronize their system clocks. This is a typical example where you don't want retransmission of lost packets, since the data (i.e., the system time) has become invalid in the mean time. Better to wait for the next update, since the system clocks will drift only microseconds in 30 seconds anyway.
Before implementing this, I sort of tested UDP reliability. I was warned about dropped packets, corrupted packets and packets delivered out of sequence. The test consisted of pumping out as many packets as possible, and see what happens. I never ever saw a single corrupted packet, or a packet delivered out of sequence! The only errors I could force were dropped packets, basically by overflowing the socket buffers on the receiving end. This test brought the network (10 Mb/s Ethernet LAN) completely to it's knees, by the way (got me the honorary title of "the network killer"). Millions and millions of packets sent, only dropped packets, never anything else.
Now, this was an isolated LAN (more or less) without crazy geeks downloading DivX movies, but the hardware wasn't all that spectacular either (SparcStation 10 server, 64MB RAM, SparcStation 5 workstations, 16MB RAM -- no typo!).
I ran some more tests with more 'normal' network loads, and I never, ever, detected a single problem.
So, your mileage may vary, but I think that problems with UDP typically would happen under circumstances (i.e., severe network congestion)that would also affect TCP.
Silly idea: you could use UDP with Forward Error Correction if your data is important. Plenty of textbooks about coding theory that explain the theory behind it, and how to design your customized error-correcting code. As long as you stay within the Shannon limit (i.e. don't try to exceed your channel capacity), you can make the error probability arbitrarily low. Doesn't help with disconnected cables an the like, since your channel capacity is zero then... Oh well, you can't win...
MSN 8: Now Microsoft even has bugs in their ad campaigns.
One of the points for using UDP over TCP is where 'guaranteed' data data delivery is not a 'hard' required. i.e. It does not cause a catastrophic failure.
We use Multicasting (IGMP is built on UDP) to 'broadcast' MPEG Video over an IP network for an Interactive DTV (www.kitv.co.uk) project.
This functions largely without problems, because maintaining an MPEG steam is highly time sensitive but it is not catastrophically sensitive to lost or dropped packets. These lost/dropped packets lead to video artifacts and not total loss of data, because the video stream can continue from the next received packet.
The quality issue is governed by *minimising* the lost packets not 'guaranteeing' them
packet loss expierenced using tcp A while back i was getting alot of CRC errors with tcp transfers. Just to give you an idea how bad it was if I downloaded 40 - 15 meg files, at least half would have CRC errors. I never recieved any error messages during the transferes and I used multiple protocols, client apps, even diffrent computers on my lan. I isolated the problem by replacing siemens speedstream nat router with a custom built router, and I've had no crc errors yet.
My point... I thought tcp wasnt supposed to let that happen, then again, maybee i should just blame the router. Has any one else have simular problems with cheap nat routers or is this post on topic?
::i visited slashdot and all i got was this lousy sig::
Also, there is an issue of IP over wireless, where packet loss is a given, at quite high rates. Thus, if you need the reliability either use TCP or add a reliability layer over UDP.
Make even shorter URLs - 8LN.org
About the only reason for using UDP is if you deliberately want to circumvent the congestion avoidance protocols that are built into TCP. So, if you are playing a game, and you need the packets to get through at all costs, but you aren't sending many packets- by using UDP you can agressively defend the small amount of bandwidth you need- any TCP connections around will tend to back off and get out of your way; and that's reasonable if you code it carefully. But writing the protocol to do that is hard, you have to understand not only UDP but also TCP, as well as your game requirements.
And that's the real problem. In most cases people think that waving UDP at the problem will solve their problems- in fact it makes them worse; and TCP has solutions to problems only PhDs have even thought of, and the solutions are built in.
As an example, somebody I know implemented a tftp protocol using UDP. The guy is off the chart in his software abilities (trust me the guy is amazing, he's in the top 2 percent of software engineers according to the tests). Anyway in a back-back comparison against a standard ftp protocol- the tftp protocol loses by a factor of 10 or more (on a network with some congestion, I expect a quiescent network would have been much more level). Of course tftp isn't supposed to handle congestion. But that's the problem- UDP can't handle network congestion out of the box... indeed if anything it tends to create network congestion.
The main algorithms in tcp include 'slow start' and 'exponential backoff'. Both of these are missing in UDP, and both improve the network performance enormously. If your application doesn't affect network performance and doesn't worry about packet loss much, then UDP may be the way to go, otherwise stay away from UDP.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"Since TCP has flow control and UDP doesn't, you can actually cause your network connection to saturate with a couple UDP connections and then you won't be able to make any TCP connections. UDP doesn't play very well with others. I believe there is a new protocol in the works that is like UDP but plays better with TCP.
Also, some TCP stacks are implemented in a way that if you start TCP connections one-after-another, after you let the latest one peak in its bandwidth usage, the third or higher TCP connections will not be able to grab any bandwidth. This is appearantly a problem with windows 9x and some ADSL connections. The TCP flow control lets the first two connections split the bandwidth between each other, but the third connection can't ramp up enough bandwidth and just chokes. Appearantly this problem is mitigated by using different types of network connections or different operating systems.
This is a very interesting paper on why things don't always work like we think they should...
Derek
Don't Panic...
When things get rough sometimes it can be difficult to reign back a UDP stream (in comparison to a TCP one) if bandwidth is being shared. UDP streams are often unresponsive and having the odd packet dropped here and there simply will not cause the rate of packets to be slowed down (there are various solutions to this though).
However as others have pointed out, which you use should depend upon the situation. If getting packets out of sequence is not so important (e.g. video streaming) then great but if reliablity is absolutely essential then TCP is probably better (plus TCP tends to still work when computers are stuck behind restrictive stateful firewalls).
NTP was too complicated(??) so, you designed built and tested your own homegrown version of NTP??????
To quote Dr. Evil, "Riiiight...".
I've spent the past several years writing networking applications, and this is my philosophy: Anytime there is *any* chance of a packet being lost or arriving out of order, you must write code that assumes every packet has a high probability of being lost. I've seen people make assumptions that since it's running on an ethernet lan they will never lose UDP packets, then their app becomes very unstable. Even when sending UDP packets to localhost they can be lost. When designing UDP software it shouldn't be a matter of how often packets are lost, but how well your code deals with lost packets. :)
Now if only someone would standardize a reliable datagram protocol implementation.
OKay, a very small amount of packet loss can be normal and should be ignored. However if you have anything other than a tiny amount of packet loss your network is in trouble, and in serious need of upgrades. Remember packet loss starts to casscade, because the droped packets have to traverse the network two or more times, and each time it crosses the network it uses some bandwidth. One droped packet, but when it is re-transmitted some other packet is droped and re-transmitted, and as a result your network gets really slow. In theory tcp will just slow down, but users will re-start the slow jobs trying to get a fast connection.
Sure, TCP will get through even when you have 85% packet loss, (I had a customer who had 85% packet loss once, a babybell I won't name) but your applications will often start timing out in other areas. In theory things should still operate, but they just get slow, but many programs have their own timeout outside of tcp so they can detect when the connection when down.
Don't use tcp where you don't need it though. I once had to debug a heartbeat for a failover system, where the system only provided tcp packets. When there was a failure in the network we could switch the network easially enough, but then we had a lot of code to try to figgure out if the heartbeat that just arrived after the network switch was old (and contained invalid information about the failed node), or correct. It always seemed to work, but I didn't sleep well many nights knowing that a customer could lose a critical computer because of code that I was supposed to make work.
So in theory you can say TCP is better when there is expected to be packet loss, and UDP is better when lost packets should be ignored. In parctice though, if you have significant packet loss you need to upgrade the network.
Yep, I did.
In one of our course, we had to do a network game in Java and we decided to use UDP. When we where using it in the university Labs (130 boxens, 100 Mbps) we had a packet loss of about 5%. Mainly caused by ethernet collisions I guess.
The best method is really a send / reply setup in your code. You send data and the other side replys with I got it (or something). Like what is done in RFC 821 - SMTP.
Only 'flamers' flame!
Implementations are already available or becoming available, on various OSs. Although designed for transporting real-time telephone signalling over IP (as stated in the RFC), it is applicable to anything else with similar requirements.
Frankly, the single most important use of UDP is for sending singleton datagrams. Not to be pissy but, um... duh. Consider how DNS works: queries are sent as UDP, and if the reponse is small enough it goes back in a UDP packet. If it's too big, it's sent as a TCP stream. Prime example of what UDP is good for.
Frankly, as far as UDP streams are concerned, I've never found a use for them that didn't involve a realtime response on the receiving end. Network gaming and video streaming is one idea, but certain kinds of telecontrol are another.
The thing that bugs me most is that, by trade I am not a network programmer. I have done network stuff in the past, but it upsets me that the sum of information in all the commentary on Slashdot is more and more frequently less than I already knew about the topics.
Maybe Bruce Perens is right.
IP is just rude.
Is there any torture so subl
What the hell is a "TCP User" or a "UDP User"? I've never heard of someone classifying them into one camp or the other. What do you think this is, the next religious war? Emacs! Vi! TCP! UDP!
-- An Eliza Troll post: As insightful as the average Slashdot post, or your money back.
Exponential backoff is braindead when you need good thoughput on a fat but noisy pipe. The reason TFTP gets lousy throughput is not because it uses UDP but because it waits for every ACK before it sends the next packet rather than having a receiver window feature like TCP does.
Apparently you have to be smarter than mister Top 2 Percent to make this work.
Here's some links for you:
Good luck with that. Try and see whether your custom application works so well with extremely large files where the packets are delivered out-of-order. Use two dummynet's connected end to end--after you're done testing with the dummynet's, come back and let us know whether it really does outperform TCP for extremely large files. (Like, tens of gigabytes.)
Actually he's very capable of doing this kind of stuff right. More or less he had to follow the tftp spec, so what's he gonna do?
But my real point is still that most people don't know enough to do it right.
You certainly sound like you might have your head around what TCP does, so probably your protocol works very well.
Exponential backoff is braindead when you need good thoughput on a fat but noisy pipe.
Yes, you are optimising your protocol to deal with cases where packet loss is caused by noise. The internet is built mostly on the assumption that packet loss is caused by congestion, so of course TCP will perform more poorly, and a more tailored protocol is a win, and UDP allows you to do that.
I do wonder if your protocol might trigger congestion collapse, but I have no doubt you've designed against that and tested for it too.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"I have a fairly high traffic enviroment.... (my boss pulling pr0n from news servers on our internet connections constant......) Most days.... I see about 97% usage of the connections... Scarry huh? I haven't noticed many UDP dropped packets.... Infact... I think I'm seeing more mangled UDP packets that are failing the crc test then packets being dropped. I do have QoS enabled, which allows my web browsing... or software downloads to take his bandwidth right out from under him.
Dude, I hate sound flame-y, but do you have any understanding of what you implemented? That you got lucky and it "works" is totally irrelevent to the fact that it's completely unreliable. All it takes is one flakey piece of Ethernet dropping packets to SCREW UP FREAKING TIMESHEETS.
Ok, calm down...
Now, I agree that UDP is built to be a fast, not-so-reliable protocol. One would initially presume that this is not the best thing to use on a punchclock system.
However, you have to look at the whole system.
First of all, if you put all the punchclocks, and the servers on the same subnet, then you've eliminated dropped packets due to routing.
Secondly, if you send an acknowledgement back to the clock, then it can display to the user "OK, you're signed in" or "ERROR, please retry". If you lose either the "sign-in" packet, or the acknowledgement packet, then all the user has to do it swipe again to retry.
Thirdly, these kind of systems always (should) have a manual backup, so if, for some reason, the system records Buddy punching in at 7 am, but never punching out, then a supervisor can go in and manually update the database to fix the problem.
Just remember that programs like this don't exist in a vaccuum; they are always part of a larger picture, and they need to function in that framework.
"I have never let my schooling interfere with my education." - Mark Twain
As a rule, people who build acknoweldgements into their UDP based protocol should have used TCP.
-bugg
First of all, if you put all the punchclocks, and the servers on the same subnet, then you've eliminated dropped packets due to routing.
Perhaps due to routing, but you have NOT eliminated dropped packets. If you have a busy LAN and the Ethernet card can't get a turn at the wire, it will eventually drop the packet. Some cheaper cards drop it immediately if it can't send it.
Secondly... Thirdly... various gyrations...
So exactly WHAT is the advantage of using UDP rather than TCP in this instance? Why go through all this crap when you can just use TCP?
As a rule, people who build acknoweldgements into their UDP based protocol should have used TCP.
Not necessarily. A better rule is that people who build sequencing and acknowledgements in should have used TCP. But if you can do without one or the other then sometimes UDP is worth it, but not often.
Sumner
rage, rage against the dying of the light
Everyone's arguing back and forth about which is better, UDP, TCP, some are even presenting other protocols such as SCTP. None of it matters, because the protocol you use depends on what the problem is.
From what I understand, UDP will lose packets in a congested environment when passing across a router. Your stack will guarantee that the packet gets onto the wire, if it gets onto the wire, it will make it onto the other machine if it is on the same wire (subnet) (barring sunspots). As soon as it hits a router, then it can be dropped.
TCP has some nasty timers in it that make it entirely unsuitable for real-time traffic. It assumes that a packet was lost because of congestion, and backs off on the retry, rather than retransmitting immediately. In modern corporate/telco IP networks congestion simply isn't the case. What really is bad is having to wait up to 4+minutes to find out the connection is dead.
UDP allows you to do what you want, and avoid anything you don't need. However, if you need things like in-order, reliable transmission you are probably better off with TCP. If you are simply providing a response, then you should be fine with UDP.
If you are after high-traffic, high connection, high throughput, UDP seems to be the way to go. If you are after easy programming and guaranteed in-order delivery, TCP is your tool.
As someone pointed out, there is a new player in town, and that's SCTP. It was invented specifically because TCP is bad for low-latency transmissions (such as Telephony!). It is used in the SS7 over IP protocols, such as M3UA, SUA, etc.
That is why you will see a mix of streams in various protocols. H.323 uses TCP for control, and UDP for speech/video. SIP allows you the choice of UDP/TCP for call control.
Jason Pollock
I of course don't know about the original poster's actual implementation.
I'm making the assumption timeclocks themselves are very lightweight (or thin) devices, CPU and memory wise.
The problem with TCP for a truly embedded application is that you have to play a lot of keep-state programming to implement even a minimal TCP stack.
A minimal UDP stack is much smaller. Everything you need to do with UDP is rather stateless.
Ignoring ARP and ICMP for a second (which is the same for TCP and UDP), sending a single message via UDP consists of encapsulating the packet and sending it. With TCP you have to send a SYN, then wait for a SYN-ACK, then send an ACK back (possibly containing data), and then you have to deal with closing the connection.
Maybe a better way to describe this is that UDP is a DATAGRAM protocol. I.E. you format a datagram and send it. By contrast TCP is designed for a mostly-reliable almost-serial-like stream, with congestion control, retransmission, etc. etc.
I was going to try to make a case for TCP in the timeclock example where a larger machine is available. I just can't see a good reason for the TCP overhead in this app. I mean, what exactly are they going to be sending... Something like "Employee 308 clock in", which the server is going to say "Got it, employee 308"?
If you haven't written low-level embedded networking code you really don't realize how much overhead is in TCP. Heck, just to get a TCP session set up and torn down you need 7 packets:
--> SYN
<-- SYN-ACK
--> ACK
(Session Established)
<-- FIN
--> ACK
--> FIN
<-- ACK
With UDP you only need 2 (1 each way) to send your message and get it acknowdged.
Don't get me wrong, I'm a fan of TCP in the right places. Any message over the ~1400-1500 MTU size of a UDP packet should probably be sent via TCP.
When was the last time you used MySQL? MySQL now supports several table types other than the default MyISAM type, including types with full transaction support.
Not necessarily. A better rule is that people who build sequencing and acknowledgements in should have used TCP. But if you can do without one or the other then sometimes UDP is worth it, but not often.
I agree. In this case, you don't need sequencing, because there's only ever one transaction out there from each client at any given time. The transaction is as simple as "12345"->"OK". The UDP protocol is so much simpler to program (and you don't have to worry about managing connections) that for this particular application, it certainly seems worthwhile.
"I have never let my schooling interfere with my education." - Mark Twain
I was going to try to make a case for TCP in the timeclock example where a larger machine is available. I just can't see a good reason for the TCP overhead in this app. I mean, what exactly are they going to be sending... Something like "Employee 308 clock in", which the server is going to say "Got it, employee 308"?
Actually, the timeclocks he describes are fully fledged PCs, I believe, and they do support a full TCP stack already. However, considering the differences in complexity of the server, I still would favour a UDP solution.
As an example, for the server to implement TCP, you would need to listen on a port, deal with an incoming connection (maybe fork off another process), deal with connection timeouts, etc.. With UDP, you can just have one single procedure that's called when a packet arrives. The procedure parses out the employee number from "Employee 308 signing in", updates the employee database, and sends a UDP message back, i.e. "Employee 308 signed in". This tolerates dropped packets (the employee just swipes again), and most importantly, the implementation is practically stateless, and that's a much simpler architecture. Never underestimate the KISS principle.
"I have never let my schooling interfere with my education." - Mark Twain
I once worked on a system that made use of PC's to process bitstreams for a digital radio broadcast system. Communications were UDP-based, and we had a problem where the odd data packet was being lost (0.5 seconds of audio lost approx every 20 seconds). I spent a MONTH debugging code to figure out where the lost packets were going. Then using tcpdump, I saw that the NIC was actually losing packets (each packet contained an integer counter). I was able to repeat the loss of packets at will.
Replaced the NIC, and all was well.
This is not to put down UDP; for this application, TCP would have retransmitted and the added delay would have created problems elsewhere.
Moral of the story: expect data to be lost over ANY kind of network.
That's easy. Now make 1000 connections in parallel with your protocol. Watch also how much bandwidth you left to say, 1000 other TCP connections. Also try have several connections in both direction with a network with several hops. I can guarantee you some surprises.
Also your links like "Max Ethernet and TCP Throughput" are completly outdated. Hint: check TCP capabilities in Linux 2.4.
With my former Companies IBS and DVBS we were doing video over TCP, UDP (Unicast and Multicast)
TCP is certainly the easiest to implement. but at only a few percent packet loss (under 5%) is comes to a grinding halt. I have never seen TCP get to full speed between to T3 at 45Mbps and even with much tweaking of the TCP windows and other timing parameters in some cases we still couldn't get over 56K over a lossy 45Mbps to 45MBps link.
With UDP 5% loss is 5% loss, MPEG and most other video formats will not be happy, with video tearing up and stalling all the time.
It's possible to implement the TCP's transmission protocol over UDP, just the packet headers will not be correct.
At my former company we developed 2 mechanisms to re-implement a TCP like connection using UDP packets. One called SPAK, which is an aggressive retransmission protocol, unlike TCP that backs down intentionally with congestion (loss) this pushes harder! On a 64K link with 90% loss measured with Ping we were able to send 60Kbps! This was for a live event from Sri Lanka to the USA on March 14 1997 with Arthur C. Clarke, and it work, even to my surprise. I had to use a 2400 Bps modem to connect to the remote server because telnet couldn't establish a connection over the 64K line into that country.
The other method we called ECIP for Error Correction Internet Protocol. It used erasure Codes, (unheard of at that time) the best papers on this are by Luigi Rizzo. http://info.iet.unipi.it/~luigi/fec.html These also worked well it took about 4 years of work to find an optimal coding and transmission scheme that ultimately borrowed some of the S-PAK ideas to include a retransmission but kept the latency to under 1 packet round trip time! This is important when doing video conferencing.
Both of these protocols were able to consonantly move up to 40MBps between to lossy T3's from the USA to Korea. This was tested over a 3-year period.
I still own the rights to these and if anyone is interested is commerial or opensourcing these you can contact me through livecam.com
I am always doing that which I can not do, in order that I may learn how to do it. - Pablo Picasso
I ran into this very problem a while back and solved it last week. Have have a Packeteer PacketShaper 4545. We use it at my Unv to slow down P2P and speed up interactive traffic such as SSH. I also use it to limit the amount of bandwidth an application or set of applications can consume. One of these sets is Games. I limited them to a slice of bandwidth during the day and raised that after hours (neither limit has ever been reached). After hours I also garuntee a small slice to help kick start apps. I also use dynamic partitions to garuntee each flow a certain amount of BW within the garunteed slice. I've made various changes to the Games class over time to try and make it better. It's been a bit of a guinea pig to test settings on for other types of traffic. One of the things I've done is raise the classes Rate Policy after hours to something slightly higher than most other traffic. None of the things I tried helped. Users still complained of exceptionally high ping times (ie, 9999ms) even during after hour times. Most of these corresponded to bursts of other traffic, not usually with a higher rate policy. Finally I called tech support. One of their techs had me switch the Rate Policy (default) to a Priority Policy. He also explained the difference between the two. Using a rate policy to slow TCP traffic means that the ACKs are delayed to slow responses down. This isn't possible with UDP though. Using a rate policy on UDP resulted in either dropped packets or an entire datgram being delayed. There is no backoff implementation in UDP so the queue would fill with these UDP datagrams. Using a simple FIFO, the 1st delayed datagram would be delivered considerably late. The another and another. If the queue was full and a datagram was received, it was dropped. Bad news. The client would experience really crappy performance. Video and audio would be extremely choppy. It would just suck. A Priority policy works differently though. Let's say a UDP Quake packet and a TCP HTTP packet arrive at the same time. The Quake packet has a higher priority. The Quake packet goes 1st. No queuing, no delay. There's other technical stuff that goes along with this but I won't bore you with it. All in all, because this traffic was UDP, the policy method I was using (again, the default) caused horrible service. Does UDP have it's uses? I'm sure. Does UDP have benefits over TCP in some cases? Sure. Would I consider switching everything to UDP? Hell no.
Interesting that no one has suggested using tools (e.g. one, two) to actually test to see what happens to a network as TCP or UDP traffic increases. There are a variety of ways to test the way both streams perform under various/different network conditions. The tools allow you to configure these metrics to your whim. (Caveat emptor, if you use these tools, there is a VERY good chance that people will notice and either get mad or just blackhole everything form your IP address.)
----
"they said there's too much caffeine in your bloodstream..."
MySQL now has transactions and foreign key support using the InnoDB table type. Beta-ed about a year ago, production about six months ago, and I heve heard few complaints, though I don't usi it myself.
Consciousness is an illusion caused by an excess of self consciousness.