Hmph.

Sharp of Fairlight · Post by **Sharp of Fairlight** » Thu Dec 02, 2004 8:15 am

my ISP at the time was dropping UDP packets under load (which is fully within their rights in the IP specs)

Nothing in the IP specs says anything about UDP packets having less priority than TCP or other protocols. It only says that UDP packets dont have to be resent (by that layer) compared to TCP packets. What most people miss is the "by that layer" part and just conclude that UDP packets are not important. But if you look at the big picture its realy the other way around. Its when TCP doesnt reach the reliability you need in your application that you have to take matters into your own hands. Its easy to understand when you look at the most popular applications for each protocol.

UDP: Television, Phone, Real Time Games...
In all of these you experience disruption in the service if these packets are dropped.
TCP: E-mail, Filetransfers...
You dont realy feel disrupted in any way if the filetransfer took 5:23 instead of 5:22. And if that E-mail took 1 second longer to deliver that you most likely didnt know that it was comming.

So, the next time someone says UDP is less important than TCP you can correct them.

Cr4zyb4rd · Post by **Cr4zyb4rd** » Thu Dec 02, 2004 12:18 pm

You know, Sharp..I already had mad respect for you, but that's one of the most brilliant things I've ever heard anybody say about the issue. I've tried hard to explain that to various people over the years and just couldn't manage to wrap the right words around it.

Thanks man. :)

insanitywiz · Post by **insanitywiz** » Thu Dec 02, 2004 2:21 pm

You know, I was about to say the same thing. Or at least I would have if I knew that stuff. But now I do know that stuff so I'll say the same thing some other time.

atomx · Post by **atomx** » Thu Dec 02, 2004 3:18 pm

Okay, I did a little more research on this since I knew there was some additional unreliability in UDP packets (above and beyond their connectionless nature) but I wasn't sure about the "part of the IP standards" bit.

You're right -- there's nothing in the standards that says that routers/switches can drop UDP packets in preference over TCP packets. I was definitely wrong there. That'll learn me for just parroting back what "someone once told me!"

However, a number of popular switches have, at least in the past, had the known behavior of preferentially dropping UDP packets when load got high. A lot of these were the cheaper switches, and a lot of these were commonly in use at the edges of larger ISP infrastructures. This had the net effect of making UDP packets even *more* unreliable than TCP packets, which, while they are still subject to network congestion, at least have a nice stateful connection to back them up and resend losses.

There are a number of good reasons *for* using UDP over TCP, however, not the least of which is that connections and all those SYN/ACK's take resources (both server resources and network bandwidth), and when you're at the tens or hundreds of thousands of clients level, this can quickly add up.

Bombadil · Post by **Bombadil** » Thu Dec 02, 2004 4:34 pm

Anarchy Online's first month of release is a prime example of what happens when you code a game to only use TCP packets.

eqjoe · Post by **eqjoe** » Thu Dec 02, 2004 9:25 pm

Switches work at that datalink layer. They don't know about UDP or TCP IP packets. Routers work at the network layer and could be configured to handle UDP different than TCP as far as forwarding priority. UDP is not guarantied delivery at the network level. Applications can be written to check and request retransmission of missing data regardless of transport. Now, it is common practice to flag UDP BROADCASTS at a lower priority if you are doing some sort of traffic prioritization. But unless you had some reason to setup a differentiated services network application (like MPLS traffic engineering for Voice over IP) that wouldn't happen either.

Whatever...

-j

atomx · Post by **atomx** » Thu Dec 02, 2004 9:59 pm

Okay, I'm venturing into vague territory here, but I was under the impression that newer (than about 5 years) switches include the ability to "peek" at the header bytes beyond the LLC stuff and make some decisions based upon what they see there. So while you're right that technically switches only work at the data-link layer (in terms of making forwarding decisions), the actual boxes (as opposed to the more abstract switches based upon the OSI model alone) can make forward/discard decisions based upon network layer info too.

From what I recall, the problem was with some switches being hardcoded (er, firmcoded) as to what packets to drop when traffic reached saturation of the switch fabric; they'd cut through the buffer, peek at some stuff, and (in the case of the faulty ones), choosing to discard UDP over TCP packets preferentially (presumably because at the time the particular ASIC or whatever was designed, UDP wasn't as prominent as it is now).

It's so vague now, that I'm unsure of about 40-50% of the content of this post, and regardless, who cares?

eqjoe · Post by **eqjoe** » Thu Dec 02, 2004 10:09 pm

Looking past the Ethernet header to decode the IP packet when under high load to deturmine what to drop sounds kinda crazy...

-j

atomx · Post by **atomx** » Thu Dec 02, 2004 10:40 pm

I'll agree with you there...

Cr4zyb4rd · Post by **Cr4zyb4rd** » Fri Dec 03, 2004 2:29 am

It's done though, more and more. Plenty of people in the world that think the best way to solve a bottleneck is to add another bottle...always will be.

Sharp of Fairlight · Post by **Sharp of Fairlight** » Fri Dec 03, 2004 3:30 am

Switches work at that datalink layer. They don't know about UDP or TCP IP packets.

Cheapo level 2 switches no, level 7 switches yes. Level 7 switches can even analyze whats inside a HTTP request and drop packets from one website in favour for another. If you look in the IP standard you will find that even at level 3 you can nowadays set bits depending on how important your packets are. This is what is called Quality of Service or QoS wich is one of the most important functions in a Router or Switch that i look for when i buy stuff. So atomx, youre right.

atomx · Post by **atomx** » Fri Dec 03, 2004 5:41 am

Sharp of Fairlight wrote:So atomx, youre right.

That's rare. Nice, but rare.

eqjoe · Post by **eqjoe** » Sun Dec 05, 2004 7:50 pm

Sharp of Fairlight wrote:
Switches work at that datalink layer. They don't know about UDP or TCP IP packets.
Cheapo level 2 switches no, level 7 switches yes. Level 7 switches can even analyze whats inside a HTTP request and drop packets from one website in favour for another.

These are content switches.. very limited in functionality and mostly used for load balancing. The big problem is that all that inspection takes CPU cycles. There is only so much you can offload to ASICs unless you are willing to give up most of your configuration options.

Inline Intrusion detection systems like the one sold by Tippingpoint use ASIC technology to inspect traffic and make a forwarding decision based on content. If the rules you apply to your traffic require deeper inspection, that traffic is moved from the fast path (fast switch or ASICs) to the slow path where it bottle necks at high data rates even with state of the art RISC processors.

Of course in time, CPUs will be so damn fast non of this will matter.

Sorry for the thread hi-jack.

-j

Voltstorm · Post by **Voltstorm** » Mon Dec 13, 2004 3:10 pm

on a side note if you are planning on doing any macro work for eq2, be advised that the "hot-key" or "in game socials/macros" are save on the server. Thusly if you make any / commands, do not store them in a game social (macro), as it *can* be viewed by the sony devs.

curiosity · Post by **curiosity** » Fri Dec 17, 2004 1:32 pm

on a side note if you are planning on doing any macro work for eq2, be advised that the "hot-key" or "in game socials/macros" are save on the server. Thusly if you make any / commands, do not store them in a game social (macro), as it *can* be viewed by the sony devs.

Do you have evidence to show this? I haven't tried logging in on another computer, but I guess that would be easy enough. If I log in on another and have the same buttons, then aye.

Also, anyone remember the simple trick on EQ1 where you could unplug your ethernet cable and walk around, then plug it back in before your lag got too deep? Anyone tried this yet on EQ2? I'd try it now, but servers are down...bleh.