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)
<<mailto:[email protected]>[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
<mailto:[email protected]>[email protected]
https://www.ietf.org/mailman/listinfo/aqm
--
Andrew McGregor | SRE |
<mailto:[email protected]>[email protected] | +61 4 8143 7128
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
________________________________________________________________
Bob Briscoe, BT
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
