I design and build physical layer radio hardware (using SDR reception and transmission in the 5 GHz and 10 GHz Amateur radio bands). Fairness is easy in a MAC. 1 usec. is 1,000 linear feet. If the next station knows when its turn is, it can start transmitting within a couple of microseconds of seeing the tail of the last packet, and if there is adequate "sounding" of the physical environment, you can calculate tighter bounds than that. Even if the transmission is 1 Gb/sec, 1 usec. is only 1,000 bits at most. But at the end-to-end layer, today's networks are only at most 20 msec. end-to-end across a continent. The most buffering you want to see on an end-to-end basis is 10 msec. I disagree strongly that "mice" - small packets - need to be compressed. Most small packets are very, very latency sensitive (acks, etc.). As long as they are a relatively small portion of capacity, they aren't the place to trade latency degradation for throughput. That's another example of focusing on the link rather than the end-to-end network context. (local link acks can be piggy-backed in various ways, so when the local Wireless Ethernet domain is congested, there should be no naked ack packets) Why does anyone measure a link in terms of a measurement of small-packet efficiency? The end-to-end protocols shouldn't be sending small packets once a queue builds up at the source endpoint.
On Monday, August 3, 2015 12:14pm, "David Lang" <[email protected]> said: > On Mon, 3 Aug 2015, [email protected] wrote: > > > It's not infeasible to make queues shorter. In any case, the throughput of a > > link does not increase above the point where there is always one packet > > ready > > to go by the time the currently outgoing packet is completed. It physically > > cannot do better than that. > > change 'one packet' to 'one transmissions worth of packets' and I'll agree > > > If hardware designers can't create an interface that achieves that bound I'd > > be suspicious that they understand how to design hardware. In the case of > > WiFi, this also includes the MAC protocol being designed so that when the > > current packet on the air terminates, the next packet can be immediately > begun > > - that's a little more subtle. > > on a shared medium (like radio) things are a bit messier. > > There are two issues > > 1. You shouldn't just transmit to a new station once you finish sending to the > first. Fairness requires that you pause and give other stations a chance to > transmit as well. > > 1. There is per-transmission overhead (including the pause mentioned above) > that > can be very significant for small packets, so there is considerable value in > sending multiple packets at once. It's a lighter version of what you run into > inserting into reliable databases. You can insert 1000 records in about the > same > time you can insert 2 records sperately. > > The "stock" answer to this is for hardware and software folks to hold off on > sending anything in case there is more to send later that it can be batched > with. This maximizes throughput at the cost of latency. > > What should be done instead is to send what you have immediatly, and while > it's > sending, queue whatever continues to arrive and the next chance you have to > send, you will have more to send. This scales the batch size with congestion, > minimizing latency at the cost of keeping the channel continually busy, but > inefficiently busy if you aren't at capacity. > > > But my point here is that one needs to look at the efficiency of the system > as > > a whole (in context), and paradoxically to the hardware designer mindset, > > the > > proper way to think about that efficiency is NOT about link throughput > > maximization - instead it is an end-to-end property. One has very little to > > do with the other. Queueing doesn't affect link throughput beyond the > "double > > buffering" effect noted above: at most one packet queued behind the > > currently > > transmitting packet. > > > > Regarding TXOP overhead - rather than complicated queueing, just allow > packets > > to be placed in line *while the currently transmitting packet is going out*, > > and changed up to the point in time when they begin transmitting. This is > > trivial in hardware. > > This is a key thing that a lot of hardware and software folks get wrong. All > the > complexity and bugs that you see around 'blocking/plugging' flows are the > result > of this mistake. As you say, send something as soon as you have it to send. If > there's more arriving, let it accumulate while the first bit is being sent and > the next chance you get to send, send everything that's accumulated. This > minimizes latency, greatly simplifies the code (no need for timers to > unblock/release the data if more doesn't arrive), and results in the exact > same > throughput under load. > > It does have some interesting changes to the utilization curve at part load. > These could be a problem with wifi under some conditions, but I think the > trade-off is worth it since the wifi is going to end up running up to it's > limit > sometime anyway, and the part load problems are just previews of what you > would > run into at full load. > > David Lang > > > > > On Friday, July 31, 2015 1:04pm, "Jonathan Morton" > <[email protected]> said: > > > > > > > >> I think that is achievable, *even if there is a WiFi network in the > middle*, by thinking about the fact that the shared airwaves in a WiFi network > behaves like a single link, so all the queues on individual stations are > really > *one queue*, and that the optimal behavior of that link will be achieved if > there > is at most one packet queued at a time. > > I agree that queues should be kept short in general. However I don't think > single packet queues are achievable in the general case. > > The general case includes Wi-Fi networks, whose TXOP overhead is so > > ruinously > heavy that sending single MTU sized packets is inefficient. Aggregating > multiple > packets into one TXOP requires those several packets to be present in the > buffer > at that moment. > > The general case includes links which vary in throughput frequently, perhaps > on shorter timescales than an RTT, so either packets must be buffered or > capacity > is left unused. This also happens to include Wi-Fi, but could easily include a > standard wired link whose competing load varies. > > The endpoints do not have and do not receive sufficient information in > sufficient time to reliably make packets arrive at nodes just in time to be > transmitted. Not even with ECN, not even with the wet dreams of the DCTCP > folks, > and not even with ELR (though ELR should be able to make it happen under > steady > conditions, there are still transient conditions in the general case). > > - Jonathan Morton_______________________________________________ > Cerowrt-devel mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/cerowrt-devel >
_______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
