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

From: "Lubashev, Igor" <[email-masked]>
Date: Tue, 9 Jul 2019 04:44:17 +0000

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.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 9 Jul 2019 14:48:54 +1000

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 <[email-masked]> wrote:
> 

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

---

From: Lars Eggert <[email-masked]>
Date: Tue, 9 Jul 2019 10:36:01 +0300

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

Igor, are you going to present the draft elsewhere (e.g., TSVWG?) If so, please send a notice to the QUIC WG so interested folks can add it to their agenda.

Thanks,
Lars

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Tue, 9 Jul 2019 02:18:17 -0700

The Q Period needs to be chosen carefully, since the observation could
become too unreliable in case of packet reordering and loss if Q Period is
too small. However, when Q Period is too large, short connections may not
yield a useful upstream loss measurement.

Wrt. short connections, do you mean low-latency, small RTT, or short-lived?

While this looks interesting, can you explain how the objectives compete or
differ from the spin bit, and quality and information provided?

Mikkel

On 9 July 2019 at 06.45.42, Lubashev, Igor ([email-masked]) 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.

---------------------

Abstract:

---

From: "Lubashev, Igor" <[email-masked]>
Date: Tue, 9 Jul 2019 14:56:49 +0000

Thanks, Lars.  Will do.

> -----Original Message-----
> From: Lars Eggert <[email-masked]>
> Sent: Tuesday, July 09, 2019 3:36 AM
> To: Mark Nottingham <[email-masked]>
> Cc: Lubashev, Igor <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: Packet Loss Signaling for Encrypted Protocols - draft-
> ferrieuxhamchaoui-tsvwg-lossbits
> 
> > Thanks for that. Our agenda is indeed tight, so I'd recommend discussing on the
> list and having side conversations in Montreal.
> 
> Igor, are you going to present the draft elsewhere (e.g., TSVWG?) If so, please
> send a notice to the QUIC WG so interested folks can add it to their agenda.
> 
> Thanks,
> Lars

---

From: "Lubashev, Igor" <[email-masked]>
Date: Tue, 9 Jul 2019 15:07:22 +0000

Understood (and not unexpected).

For those who are interested, we'll talk about the draft in tsvwg (focus on signaling behavior, privacy preservation, ossification resistance, maybe specifics of where the signals can be carried) and maprg (focus on the data collected, accuracy of measurement, capabilities at detecting/measuring various causes of loss, and techniques to improve noise filtering due to reordering).  Both of the WG meetings are later in the week (tsvwg is on Thu, maprg on Fri).

Alexandre and I will be in Montreal, and we are happy to have side meetings with interested people.

Many thanks,

- Igor

> From: Mark Nottingham <[email-masked]>
> Sent: Tuesday, July 09, 2019 12:49 AM
> To: Lubashev, Igor <[email-masked]>
> Cc: Lars Eggert <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> 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
> >
> 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.
> >
> > ---------------------
> >

---

From: "Lubashev, Igor" <[email-masked]>
Date: Tue, 9 Jul 2019 15:18:42 +0000

From: Mikkel Fahnøe Jørgensen <[email-masked]>

The Q Period needs to be chosen carefully, since the observation could become too unreliable in case of packet reordering and loss if Q Period is too small. However, when Q Period is too large, short connections may not yield a useful upstream loss measurement.

By “short” I mean too few packets sent (fewer than half Q Period).  I will clarify this in the text. Thank you.

While this looks interesting, can you explain how the objectives compete or differ from the spin bit, and quality and information provided?

Latency Spin Bit (aka “spin bit”) measures connection rtt.  The proposed mechanism measures packet loss.  So the two are complementary measurement signals.

  *   Igor

On 9 July 2019 at 06.45.42, Lubashev, Igor ([email-masked]<mailto:[email-masked]>) 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.

Thank you!

- Igor

---------------------

https://datatracker.ietf.org/doc/draft-ferrieuxhamchaoui-tsvwg-lossbits/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dferrieuxhamchaoui-2Dtsvwg-2Dlossbits_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=8tqj3OKmcGwAeTvifbhpZNwiGgQQrld_04cGqddUgas&s=GDUFlTwCpg_Ewg6sZuR0uKLJ5gLiW8qRPrb88Eoscr0&e=>

Abstract:

---

From: "Lubashev, Igor" <[email-masked]>
Date: Fri, 19 Jul 2019 18:22:28 +0000

Since tsvwg and maprg meetings are rather late in the week, I've booked a side meeting time.

So, for those who are interested in loss signaling for encrypted protocols (such as QUIC), we can discuss this:

* side meeting -- Monday 8:30am-9:30am in Sainte-Catherine
* tsvwg (Thu) -- focus on signaling, privacy, ossification
* maprg (Fri) -- focus on real world data collected and capabilities/limitations of the measurement method 

- Igor

> From: Lubashev, Igor <[email-masked]>
> Sent: Tuesday, July 09, 2019 11:07 AM
> 
> For those who are interested, we'll talk about the draft in tsvwg (focus on
> signaling behavior, privacy preservation, ossification resistance, maybe specifics
> of where the signals can be carried) and maprg (focus on the data collected,
> accuracy of measurement, capabilities at detecting/measuring various causes of
> loss, and techniques to improve noise filtering due to reordering).  Both of the
> WG meetings are later in the week (tsvwg is on Thu, maprg on Fri).
>