Thanks. Personally, I think it is two problems. One, which I imagine is the one you worked on, is the question of detection; we can detect loss at an endpoint (it doesn't see something it expects to see) but not reliably (it might not be expecting something, but an outside observer expects it to see something, and it doesn't see it). The other is the question of what one does about it. If it is an unreliable interface injecting packet errors, one can route around it. If it's a wireless interface (unreliable in the sense that the probability of error is non-negligible), one might route around it, or one might impose some variation on ARQ or FEC, as we do in WiFi and other technologies. If it's another source of non-congestive loss, I suspect that the solution is somehow tailored to the mode of operation.
I can tell you that we have a capability for video streaming applications in which we enumerate packets and literally send two streams on disjoint paths. At the receiving end, we discard the second instance of a packet that arrives. In the event of loss in the network, we expect that to reduce the probability of non-delivery to a negligible value. Solutions like that can be a cost-effective solution to non-congestive loss, I should think. On Nov 12, 2013, at 3:20 AM, Bob Briscoe <[email protected]> wrote: > Fred, > > For the record, Andrew and I spent an evening to see if we could come up with > a solution to indicate non-congestive loss. We started with a list of 9 > different causes of loss (from my PhD thesis). We worked through a number of > ideas, but they all exhibit varying degrees of problems. > > So we all agree indicating non-congestive loss is a research problem for > now... > > > Bob > > At 20:38 08/11/2013, Andrew Mcgregor wrote: >> 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 > ________________________________________________________________ > Bob Briscoe, BT > Make things as simple as possible, but not simpler. Albert Einstein
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
