Slow connection to mutant.

[[BTF]Sigma]

So I was downloading an update for a ps3 game and in a xbox 360 party while playing some MUTANT to kill time and noticed this...

There's a crapload of netspikes (lost packets)

Is there anyway to give my packets priority over anything else on the network?
Router
Brand: LinkSys
Model: wrt54g

[QwazyWabbit]

Short answer: No.

Wired or wireless to the router? If wireless, use a wired connection. Wireless frames can interfere with each other and cause dropped frames.
On the Internet, UDP frames get dropped, it's expected.

[ToxicMonkey^MZC]

You can set a different QoS (Quality of Service) for each DHCP client on the router if the router supports it.

Theoretically you can guarantee a certain bandwidth to a device on the network, providing the bandwidth is available from the WAN of course.  Or you can cap the bandwidth on a per client basis.  My router (old Edimax BR-6204WG) lets me do this with port and protocol filters as well.  I wouldn't advise messing with these settings unless you are absolutely sure what you are doing though

Wabbit is absolutely correct about UDP - packet loss is the trade-off for the high connection speed.

[quadz]

Wabbit is absolutely correct about UDP - packet loss is the trade-off for the high connection speed.

Hmmm... that's not quite how it works.

Routers make a best-effort attempt to deliver packets.  Packets get dropped whether they are UDP, TCP, ICMP, etc.

It's just that TCP hides the packetloss from the application.  It's smart enough to handle the packet sequencing and re-transmission behind the scenes, and deliver a stream of sequential bytes between two end-points.

But on the network, TCP packets are dropped just like UDP packets.

UDP doesn't deliver a 'higher connection speed' than TCP.  What UDP provides, is a means for an application like Quake to transmit so-called unreliable data.  The term 'unreliable' here doesn't mean the packets are more likely to be dropped, but rather, that they contain data that, if lost, we don't want to try to re-transmit.

This is useful for information that can become stale.  With TCP, if the client told the server "I am facing direction XYZ", and that packet got lost, TCP would faithfully keep re-trying to send that stale information until it was finally received by the server.  With UDP, the client can instead say, well, I never want to re-try that old information, even if it got lost, I want to tell the server "I am NOW facing direction XYZ'" ... we don't care about re-transmitting stale position information, even if it got lost, we always just want to send the latest info.

For an application like Quake, that is the principal difference between TCP and UDP.

Regards,

quadz

[reaper]

Routers make a best-effort attempt to deliver packets.

That is the nature of queues with packet switched networks.  You could always say "I want to reserve X bits per second for X type(s) of traffic", but since the internet is a collection of internetworks, and based on packet switching (using queues), it is truly best effort.  For example, you setup QOS on your home router, and the inbound bandwidth is maxed from connections from China..
I guess you could say, you could really never truly guarantee you have the bandwidth unless you have a point-to-point circuit or similarly designed internetwork, and that's not the interent.

There is also software queues and hardware queue's, in routers other than the Netgear's and the likes.  The hardware queues are fixed, and are particle buffers, which I believe are linked lists in a specially addressable form of memory. Sometimes a packet traverses both queues.  So you can drop the traffic, where a graph of the bandwidth would be level at a peak, or shape the traffic, where a graph of the bandwidth would go up and down.  Policing is essentially dropping the traffic from a hardware queue, and shaping is holding the packet up in "software". But in the end, if you have the bandwidth, QOS doesn't buy much if at all.  Altough there could be microbursts, where by chance everything consumes a lot of bandwidth at once, and on the internet, you never truly have a guarantee of bandwidth, because that is by design of packet switched networks.  Maybe in practical matters that's not the case though, I'm not sure.

And you also get your packet from one interface to the other by a lot more than bitwise anding against a routing table, CEF is used on cisco routers.  So you don't have to do lots of searching to lookup MAC addresses to rewrite the frame as it traverses networks, and looking up ARP information.  CEF is cisco express forwarding, and ties the mac address of the next hop, and interface nicely together in a "tree".  A tree is some kind of relationship you create between data in software:
http://en.wikipedia.org/wiki/B-tree

Wired or wireless to the router? If wireless, use a wired connection. Wireless frames can interfere with each other and cause dropped frames.
On the Internet, UDP frames get dropped, it's expected.

UDP would be considered a packet, which is kind of important because it is a distinction between a frame.  Both the term packet and frame describe PDUs (protocol data units), as bits get transported from one system to another, the units get passed up and down the stack.. from a bit (voltage of a square wave or whatever physical medium is being referenced), to a frame (atm/ethernet/fddi), to a packet (ip/ipx/others), to a segment (TCP), and then on up to the application layer where the model has fallen apart .

So while in context it might not matter to describe a UDP packet as a frame, they are very much two different things.  Frame is the term for a layer2 protocol data unit, while packet is a layer3 protocol data unit.  A frame of course has a UDP header inside, but is making an entirely different reference.  The frame has a different header, and functions at a different layer of the internetworking stack.  The frame has a preamble at the start to denote where it starts, and is a different protocol than IP/IPX/Vines.  Frames are also local and are not even recreated but are totally new between layer3 internetworks, so you would refer to a UDP packet, or a higher layer unit, which for TCP would be a segment, but UDP has no segments, it's just a packet and we don't care if it might drop, we usually are not going to ask the application layer to retransmit it.

So layer1 you have the bit, layer2 the frame, layer3 the packet...the layer2 frame being different between each internetwork.  When you say frame, you are not saying which frame, is it an ATM frame between hop 11-12, or one of the Ethernet frames between hops 10-20.   Does the frame contain part of the packet or the whole thing?  Either way between each hop it is a new frame. There's quiet a difference, not that it matters, but technically it is the wrong term to describe a packet..


I may have butchered some of that explanation, but I don't think to much


edit: an ATM layer2 PDU is usually referred to as a cell since it is fixed with, so it doesn't have a preamble, but you can swith ATM with whatever layer2 PDU..

[QwazyWabbit]

Some good information there.

My statement was correct, UDP packets get dropped, however, it's the application's responsibility to detect and correct data loss, if necessary. In the context of the Q2 protocol, red spikes are lost frames, the application protocol knows it, but doesn't do anything about it.

The difference between TCP and UDP can best be summarized as being the difference between guaranteed delivery regardless of time and best-effort delivery without regard to time.

Once data has been passed to TCP, it WILL be delivered. Guaranteed. Once sent, a TCP packet MUST be acknowledged by the destination before it can be considered delivered by the sender. Further communication beyond a certain number of outstanding frames cannot continue until both ends agree about the status of acknowleged or outstanding frames. Whether those frames are delayed, duplicated, mis-routed or dropped, neither end needs to know but the TCP/IP stack itself takes responsibility for proper, in-order, delivery of the application data. The only thing that can interfere with the process is hardware failure at either end or deliberate reset of the TCP session by either end. (Disregarding MITM attacks for this discussion.)

IP packets carrying TCP and UDP messages have a TTL element that tells routers when the packet has been hopped beyond it's useful life and it is time to drop it. This prevents IP frames from circling the globe in search of a destination forever.

UDP on the other hand is much simpler. It frames the data with source and destination information but it places the responsibility for end-to-end delivery of the data on the client/server application itself. Once the network stack has "transmitted" the data it discards it and doesn't check for or guarantee the data will actually arrive. If the application (like Q2) doesn't care about stale data, it's acceptable to let the frames be dropped. The application is responsible for validating the data and acknowleging it or not. UDP was designed to be a quick way of enabling adoption of time-critical data or for newer protocols the designers of TCP/IP might not have anticipated. The media conferencing H.323 protocol is an example of a protocol that sits on top of UDP for "real-time" communication. (VOIP)

When discussing these protocols in the OSI model, TCP and UDP are said to be in Layer 4, where IP is in Layer 3. The applications reside in Layer 7. In TCP, data arriving in layer 7 (application layer) is guaranteed to be delivered in proper sequence without visible "error" due to delays or drop out at the lower layers. The same cannot be said about UDP transport.

As far as "frame" vs "packet" is concerned, I don't know of any formal definition that a packet is L3 or L4 and a frame is L2 or L1. Such a definition does not exist unless you have an authoritative citation. Tannenbaum uses packet at L3 and frame at L2 but even he makes the statement that frame is not the OSI accepted name for the unit. The terms are used just about interchangably except in some circles the term frame is usually ascribed to an ATM (L2) frame and where it takes several ATM frames to carry a TCP/IP packet. Tannenbaum also says the proper unit for TCP or UDP is "message" and it's an IP "packet". Most network sniffers use the term "frame" when they mean "packet". The MS Netmon sniffer defines:

frame
Also called a packet. A package of information transmitted as a single unit over a network. Every frame follows the same basic organization and contains control information, such as synchronizing characters, station address, an error-checking value, and a variable amount of data.

packet
See frame.

The distinction between frame and packet is pointless unless you are dealing with transport issues between layers and discussing both layers simultaneously and that's the job of protocol designers and not specific to TCP/IP.

What about QOS? The QOS flags can be set in your LAN or in your router but once they pass from your router, unless there is an explicit agreement about your QOS, the ISP is free to disregard the information and handle the transport as it normally would for "routine" traffic.