On 14 May, 2011, at 11:48 pm, Fred Baker wrote: > My suspicion is that the right approach is something akin to 802.2 at the > link layer, but with NACK retransmission - system A enumerates the data it > sends to system B, and if system B sees a number skip it asks A to retransmit > the indicated datagram. You might take a look at RFC 5401/5740/5776 for > implementation suggestions.
This sounds like "reliable datagram" semantics to me. It also sounds a lot like ARQ as used in amateur packet radio. I believe similar mechanisms are built into 802.11. The fundamental thing is that the sender must be able to know when sent frames can be flushed from the buffer because they don't need to be retransmitted. So if there's a NACK, there must also be an ACK - at which point the ACK serves the purpose of the NACK, as it does in TCP. The only alternative is a wall-time TTL, which is doable on single hops but requires careful design. Let's face it. UDP is unreliable by design - applications using it *must* anticipate and cope with dropped and delayed packets, either by exponential RTO or ARQ or NACK or FEC, all at the application layer. And, in a congested network, some UDP packets *will* be lost. TCP is reliable but needs to maintain appropriate window sizes - which it doesn't at present because a lossless network without ECN provides insufficient feedback (and AQM, which is required for good ECN signals, is usually absent), and in the quest for performance, the trend has been inexorably towards more aggressive window sizing (of which TCP-Fit is the latest example). At the receiver end, it is possible to restrain this trend by reducing the receive window. Unfortunately, it's useless to expect Ethernet switches to turn on ECN. They operate at a lower stack level than IP, so they will not modify the IP TOS headers. However, recent versions of Ethernet *do* support a throttling feedback mechanism, and this can and should be exploited to tell the edge host or router that ECN *might* be needed. Also, with throttling feedback throughout the LAN, the Ethernet can for practical purposes be treated as almost-reliable. This is *better* in terms of packet loss than ARQ or NACK, although if the Ethernet's buffers are large, it will still increase delay. (With small buffers, it will just decrease throughput to the capacity, which is fine.) - Jonathan _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
