[quicwg/base-drafts] QUIC lacks on-path exposure of packet loss (#3189)

[Alexandre Ferrieux <[e-mail]>]

QUIC exposes the Spin Bit to the path in order to help operators debug their
networks. It allows them to locate segments with an abnormal contribution to
latency by dichotomy, since observing the Spin Bit at a given middle point
allows to compute separately the contribution to RTT of both sides.

This is good, but in many cases, latency is not the crucial element; packet loss
is the real killer. The reason for this lies on the foreseeability of the fault
location:

1. The location of significant latency buildup is most often known in advance: it is the last segment of the access network (capacity bottleneck with a large per-user buffer)
2. Packet loss, by contrast, happens in all segments of the end-to-end path, with low correlation with latency (high-speed interfaces of core routers with limited RAM and large amounts of cross-traffic). 

For a network operator, the key feature is thus the ability to do dichotomy on
packet loss. One might imagine that it is doable by simultaneous packet captures
on both ends of a suspected segment; this simply doesn't help further
investigations on other segments, since one doesn't know in which direction to
proceed (upstream or downstream). Dichotomy is impossible.

In this context, it is very frustrating to anybody in network operations to see
QUIC v1 ship with the less important of on-path measurements, the Spin Bit, and
without an effective way to identity and locate loss. This means several years
of near blindness on network issues and degraded network QoS for QUIC. Everybody
(including content providers and customers) will directly or indirectly suffer
from this.

Early in the discussions around the Spin Bit, two "reserved" bits have been
secured "for experimentation" in the first byte of short headers. These bits are
currently unused. We propose to use them for on-path exposure of packet loss in

https://datatracker.ietf.org/doc/draft-ferrieuxhamchaoui-quic-lossbits/

Note the efficiency of the method ("QL bits") has been verified in the field
through a full-size experiment in 4 countries conducted by Orange and Akamai, as
described at IETF105 in TSVWG and MAPRG

https://datatracker.ietf.org/meeting/105/materials/slides-105-tsvwg-sessb-32-loss-signaling-for-encrypted-protocols-03

https://datatracker.ietf.org/meeting/105/materials/slides-105-maprg-packet-loss-signaling-for-encrypted-protocols-01

The purpose of the current Issue is to raise awareness of the upcoming
difficulty to debug networks in the current state of the specification, and to
request the inclusion of the QL bits in the transport draft, with the same
status as the Spin Bit – “experimental” in v1 and with anti-ossification
requirement to only activate the QL bits on no more than 80% of connections. We
are hereby suggesting the constitution of a design team to conduct the same
analysis of privacy and ossification impacts as was done for the Spin Bit.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3189