Re: Packet Loss Signaling for Encrypted Protocols - draft-ferrieuxhamchaoui-tsvwg-lossbits

[Mark Nottingham <[e-mail]>]

Hi Igor,

Thanks for that. Our agenda is indeed tight, so I'd recommend discussing on the list and having side conversations in Montreal.

Thanks,


> On 9 Jul 2019, at 2:44 pm, Lubashev, Igor <[e-mail]> wrote:
> 
> Alexandre, Isabelle, and I have posted a draft on a method for endpoints to signal packet loss to the path, while maintaining end user privacy and resisting ossification.  The method is protocol-independent, but of course you get the most benefit by applying the method to encrypted transports, and QUIC is what people usually think of first in such context.
> 
> The draft is not targeted at the QUIC WG specifically, since it is describing a general method of such loss reporting.  But we do mention QUIC, so the WG may find it interesting.  We would welcome feedback from the QUIC WG.
> 
> Lars, Mark, I am sure the meeting agenda for Montreal is pretty tight, but if the WG is interested, we are happy to have a quick QUIC-specific presentation on this.
> 
> Thank you!
> 
> - Igor
> 
> P.S.  We've implemented this proposal in some Akamai servers and have been using it to serve actual end-user QUIC traffic for a subset of Orange customers.  Orange implemented a passive observer that used this signal to detect and identify loss.  We can share the high-level of the results and will share the detailed analysis of the data and measurement techniques in maprg.
> 
> ---------------------
> 
> https://datatracker.ietf.org/doc/draft-ferrieuxhamchaoui-tsvwg-lossbits/
> 
> Abstract:
>   This document describes a protocol-independent method that employs
>   two bits to allow endpoints to signal packet loss in a way that can
>   be used by network devices to measure and locate the source of the
>   loss.  The signaling method applies to all protocols with a protocol-
>   specific way to identify packet loss.  The method is especially
>   valuable when applied to protocols that encrypt transport header and
>   do not allow an alternative method for loss detection.

--
Mark Nottingham   https://www.mnot.net/