3 ms·

Not a networking guy. I'm curious if packets have priorities, and if so does everyone get greedy and claim to be high priority? They talk about delay reduction

Not a networking guy. I'm curious if packets have priorities, and if so does everyone get greedy and claim to be high priority? They talk about delay reduction in the article, but a lot of the internet bandwidth today seems to be video which doesn't need to have low latency once it's got a bit in the receive buffer. It just seems like gamers packets should be prioritized for delay while streaming stuff should be (maybe) prioritized for bandwidth, possibly with changing priority depending how far ahead of the viewer the buffer is. Not sure where regular web traffic would fit in this - probably low delay?

uluyol 4y ago
Paket properties are not respected on the public internet, but organizations do make use of them internally. For public clouds who operate global networks, they can typically send video streams at low/mid priority all the way to "last mile" ISP by peering with so many networks and just running massive WANs internally. So they can get most of the benefits of prioritization, even though the internet doesn't support it.
kkielhofner 4y ago
"The internet" is "best effort". What this really means is all of the networks that make up the internet don't pay attention to the DSCP marks[0] in the IP header. In reality almost all large networks (internal and internet traffic handling) use MPLS[1] or some variant to tunnel/encapsulate different types of traffic and handle priority that way while not paying attention to whatever DSCP markings users can arbitrarily set. MPLS (in most cases) is invisible to the end user so the carrier can do their own QoS while not allowing customer configuration to impact it. If "the internet" cared about DSCP you would definitely see the situation you're describing where everyone would just mark their traffic highest priority. Note you can still mark it, it's just that no one cares or respects it. On your network and queues you can definitely use DSCP and 802.1p[2] (layer 2 - most commonly ethernet) to prioritize traffic. Thing here is you need equipment end to end (every router, switch, etc) that's capable of parsing these headers and adjusting queueing accordingly. As if this isn't complicated enough, in the case of the typical edge connection (a circuit from an ISP) you don't have direct control of inbound traffic - when it gets to you is just when it gets to you. Unless you use something like ifb[3], in which case you can kind of fake ingress queuing by way of wrapping it through another interface that effectively makes the traffic look like egress traffic. All you can really do here is introduce delay and or drop packets which for TCP traffic most commonly will trigger TCP congestion control, causing the transmitting side to back off because they'll think they're sending data too fast for your link. UDP doesn't have congestion control but in practice that just means it's implemented higher in the stack. Protocols like QUIC, etc have their own congestion control implemented that in many cases can effectively behave like TCP. The difference here is the behavior in these scenarios is left dictated to the implementation as opposed to being at the mercy of the kernel/C lib/wherever else TCP is implemented. Clear as mud, right? Good news is many modern end user routers just kind of handle this with things like FQ-Codel, etc. [0] - https://en.wikipedia.org/wiki/Differentiated_services https://en.wikipedia.org/wiki/Differentiated_services [1] - https://en.wikipedia.org/wiki/Multiprotocol_Label_Switching https://en.wikipedia.org/wiki/Multiprotocol_Label_Switching [2] - https://en.wikipedia.org/wiki/IEEE_P802.1p https://en.wikipedia.org/wiki/IEEE_P802.1p [3] - https://wiki.linuxfoundation.org/networking/ifb https://wiki.linuxfoundation.org/networking/ifb
- sitkack 4y ago
  Thank you! I learned a ton.
  - kkielhofner 4y ago
    No problem. I'm happy I've had experience with all of this and learned it. I'm happier I don't have to deal with it on a daily basis anymore!

uluyol 4y ago

Paket properties are not respected on the public internet, but organizations do make use of them internally. For public clouds who operate global networks, they can typically send video streams at low/mid priority all the way to "last mile" ISP by peering with so many networks and just running massive WANs internally. So they can get most of the benefits of prioritization, even though the internet doesn't support it.

kkielhofner 4y ago

"The internet" is "best effort". What this really means is all of the networks that make up the internet don't pay attention to the DSCP marks[0] in the IP header. In reality almost all large networks (internal and internet traffic handling) use MPLS[1] or some variant to tunnel/encapsulate different types of traffic and handle priority that way while not paying attention to whatever DSCP markings users can arbitrarily set. MPLS (in most cases) is invisible to the end user so the carrier can do their own QoS while not allowing customer configuration to impact it. If "the internet" cared about DSCP you would definitely see the situation you're describing where everyone would just mark their traffic highest priority. Note you can still mark it, it's just that no one cares or respects it. On your network and queues you can definitely use DSCP and 802.1p[2] (layer 2 - most commonly ethernet) to prioritize traffic. Thing here is you need equipment end to end (every router, switch, etc) that's capable of parsing these headers and adjusting queueing accordingly. As if this isn't complicated enough, in the case of the typical edge connection (a circuit from an ISP) you don't have direct control of inbound traffic - when it gets to you is just when it gets to you. Unless you use something like ifb[3], in which case you can kind of fake ingress queuing by way of wrapping it through another interface that effectively makes the traffic look like egress traffic. All you can really do here is introduce delay and or drop packets which for TCP traffic most commonly will trigger TCP congestion control, causing the transmitting side to back off because they'll think they're sending data too fast for your link. UDP doesn't have congestion control but in practice that just means it's implemented higher in the stack. Protocols like QUIC, etc have their own congestion control implemented that in many cases can effectively behave like TCP. The difference here is the behavior in these scenarios is left dictated to the implementation as opposed to being at the mercy of the kernel/C lib/wherever else TCP is implemented. Clear as mud, right? Good news is many modern end user routers just kind of handle this with things like FQ-Codel, etc. [0] - https://en.wikipedia.org/wiki/Differentiated_services https://en.wikipedia.org/wiki/Differentiated_services [1] - https://en.wikipedia.org/wiki/Multiprotocol_Label_Switching https://en.wikipedia.org/wiki/Multiprotocol_Label_Switching [2] - https://en.wikipedia.org/wiki/IEEE_P802.1p https://en.wikipedia.org/wiki/IEEE_P802.1p [3] - https://wiki.linuxfoundation.org/networking/ifb https://wiki.linuxfoundation.org/networking/ifb

sitkack 4y ago
Thank you! I learned a ton.
- kkielhofner 4y ago
  No problem. I'm happy I've had experience with all of this and learned it. I'm happier I don't have to deal with it on a daily basis anymore!