4 ms·

DSCP / ToS is used for traffic classification within a network (which can be used to select router policy), but generally not across autonomous systems. You'd h

by vitus 2y ago

DSCP / ToS is used for traffic classification within a network (which can be used to select router policy), but generally not across autonomous systems. You'd have to get everyone to agree on what various traffic markings mean, and, more critically, which traffic deserves to be marked in certain ways. For instance, suppose that you wanted a special traffic class that's prioritized over everything else. You really don't want just anyone to be able to send you that kind of traffic, since a DoS attack can easily starve all the other queues. Your best bet is usually to match traffic based on other characteristics, e.g. port × protocol.

gary_0 2y ago
Ah, I see. Still, it seems like it would be a useful idea to have an IP bit for "minimize buffering and drop instead, packet is time-sensitive", and that seems safe since the user is requesting fewer resources, not more.
- vitus 2y ago
  You would think so, but buffers are actually a core part of regular router function. The problem is not inherently router buffers, but rather buffers that don't fully drain (bufferbloat) or that fill up (congestive drops). Think about it this way: a 100Gbps link can process a 1500 byte packet in about 0.12 microsecond. If you have an average of 1,000 packets in that buffer at steady-state, that buffer is contributing a fraction of a millisecond to your overall latency. Meanwhile, if your home router's buffer has the same 1,000 packets for a 1Gbps link, that's 12 milliseconds of latency. If you had a way to tell a router to never buffer packets, you'd encounter packet loss much sooner, and for no good reason. Buffers are great for smoothing out (small) bursts of traffic (although if you have large bursts on very short timescales, you can easily overwhelm these buffers -- this is why you typically have pacing on the OS level). If instead you want the router to add no more than X amount of latency, that's suddenly much harder to dictate. (The "correct" value of X depends on your application requirements as well as the number of hops through the network between you and the server you're talking to.) (Also, while you might think that this should be strictly beneficial for network operators since the user wants fewer resources, encoding exceptions like this into router policy ends up using more of a specialized and expensive kind of memory called TCAM. Assuming that it's even possible to do such a thing.)

by vitus 2y ago

gary_0 2y ago

Ah, I see. Still, it seems like it would be a useful idea to have an IP bit for "minimize buffering and drop instead, packet is time-sensitive", and that seems safe since the user is requesting fewer resources, not more.

vitus 2y ago
You would think so, but buffers are actually a core part of regular router function. The problem is not inherently router buffers, but rather buffers that don't fully drain (bufferbloat) or that fill up (congestive drops). Think about it this way: a 100Gbps link can process a 1500 byte packet in about 0.12 microsecond. If you have an average of 1,000 packets in that buffer at steady-state, that buffer is contributing a fraction of a millisecond to your overall latency. Meanwhile, if your home router's buffer has the same 1,000 packets for a 1Gbps link, that's 12 milliseconds of latency. If you had a way to tell a router to never buffer packets, you'd encounter packet loss much sooner, and for no good reason. Buffers are great for smoothing out (small) bursts of traffic (although if you have large bursts on very short timescales, you can easily overwhelm these buffers -- this is why you typically have pacing on the OS level). If instead you want the router to add no more than X amount of latency, that's suddenly much harder to dictate. (The "correct" value of X depends on your application requirements as well as the number of hops through the network between you and the server you're talking to.) (Also, while you might think that this should be strictly beneficial for network operators since the user wants fewer resources, encoding exceptions like this into router policy ends up using more of a specialized and expensive kind of memory called TCAM. Assuming that it's even possible to do such a thing.)