I agree, non-congestive loss notification is a research problem. So, out of scope for the IETF right now but I hope someone thinks about it (I will, as a background task).
On 8 November 2013 11:49, Fred Baker (fred) <[email protected]> wrote: > > At 23:04 04/11/2013, Andrew Mcgregor wrote: > > This seems like valuable work. One question is, can we put in scope > notification that losses are NOT due to congestion? > > Speaking for myself, I'm not sure how I would do that. > > A loss (or mark) due to congestion is pretty simple. The switch knows what > it did. > > To know that a packet was lost for reasons other than congestion, I need > to somehow know what packets I should expect, and infer that something that > I expected didn't happen. In TCP, we know about data segments because they > are enumerated - I know what the next octet sequence number to expect, and > it doesn't arrive. Control segments (SYN, ACK, FIN, RST, and so on) are not > enumerated in that sense - if my peer sends ten identical acks and nine > arrive, I as the receiver have no way to know that. At the link layer, most > link protocols in use today (PPP, Ethernet, and so on) do not enumerate > packets in flight - they are simply there. I *might* be able to see a burst > of noise on the line, but only if it looks like it might be the start of a > packet and then doesn't end with the right checksum. Even if I can see it, > I have no way to know whether the noise garbled one packet or many. > > If you want to do some research and come up with a solution, be my guest. > But in a standard discussed in 2013... let's not. > > _______________________________________________ > aqm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/aqm > > -- Andrew McGregor | SRE | [email protected] | +61 4 8143 7128
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
