Re: [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols?

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) <fred@cisco.com> 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
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm
>
>

-- 
Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128