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

["Lubashev, Igor" <[e-mail]>]

Since tsvwg meeting is rather late in the week, I've booked a side meeting on Monday 8:30am-9:30am in Sainte-Catherine for those who are interested to discuss packet loss signaling for encrypted protocols.

- Igor

> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Tuesday, July 16, 2019 1:51 AM
> 
> Hi Tom,
> 
> A change is needed for these devices to parse the surplus area. Whether it is
> structured as (1) a fixed header followed by type-specific data or (2) as a set of
> TLVs does not matter much here, IMO.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Tom Herbert [mailto:[e-mail]]
> > Envoyé : jeudi 11 juillet 2019 20:07
> > À : BOUCADAIR Mohamed TGI/OLN
> > Cc : HAMCHAOUI Isabelle TGI/OLN; Lubashev, Igor; tsvwg; FERRIEUX Alexandre
> > TGI/OLN; RONTEIX JACQUET Flavien TGI/OLN
> > Objet : Re: [tsvwg] Packet Loss Signaling for Encrypted Protocols: draft-
> > ferrieuxhamchaoui-tsvwg-lossbits
> >
> > On Thu, Jul 11, 2019 at 5:22 AM <[e-mail]> wrote:
> > >
> > > Hi Isabelle,
> > >
> > >
> > >
> > > That is not surprising. Some devices are known to drop such packets
> > because of, for example, an assumption of how checksums are computed.
> > There are proposals to fix that (compensate the checksum).
> >
> > Med,
> >
> > Even if we can get middleboxes to pass packets with surplus header,
> > there is still a question of whether any of them would process it like
> > to extract the loss signal information described in this draft. The
> > problem is that network devices are designed to process protocol
> > headers, not protocol trailers. The UDP Extended Header described in
> > draft-herbert-udp-space-hdr-01 might be a way to address that.
> >
> > Tom
> >
> > >
> > >
> > >
> > > IMO, it is too premature to make a conclusion :-)
> > >
> > > Cheers,
> > >
> > > Med
> > >
> > >
> > >
> > > De : HAMCHAOUI Isabelle TGI/OLN
> > > Envoyé : jeudi 11 juillet 2019 12:19
> > > À : BOUCADAIR Mohamed TGI/OLN
> > > Cc : Lubashev, Igor; tsvwg; FERRIEUX Alexandre TGI/OLN; Tom Herbert;
> > RONTEIX JACQUET Flavien TGI/OLN
> > > Objet : RE: [tsvwg] Packet Loss Signaling for Encrypted Protocols:
> > draft-ferrieuxhamchaoui-tsvwg-lossbits
> > >
> > >
> > >
> > > Hi Med,
> > >
> > >
> > > We’ve tried using UDP trailers to support our loss bits some months ago,
> > and some L4 equipment just drop packets with non-empty UDP trailers.
> > >
> > > So, it seems that using UDP surplus area is not really a viable option
> > either.
> > >
> > >
> > >
> > > Cheers,
> > >
> > >
> > >
> > > Isabelle
> > >
> > >
> > >
> > > De : BOUCADAIR Mohamed TGI/OLN
> > > Envoyé : jeudi 11 juillet 2019 08:53
> > > À : Tom Herbert
> > > Cc : Lubashev, Igor; HAMCHAOUI Isabelle TGI/OLN; tsvwg; FERRIEUX
> > Alexandre TGI/OLN
> > > Objet : RE: [tsvwg] Packet Loss Signaling for Encrypted Protocols:
> > draft-ferrieuxhamchaoui-tsvwg-lossbits
> > >
> > >
> > >
> > > Hi Tom,
> > >
> > >
> > >
> > > Actually, there is no new problem to solve for TCP (and some of the
> > other protocols you mentioned). Existing techniques are OK, see for
> > example the discussion in https://tools.ietf.org/html/rfc8517#section-2.1.
> > >
> > >
> > >
> > > Supplying these bits at the network layer would be ideal, but as you
> > know there is no such common layer. IPv6 extensions will be obviously
> > specific to IPv6 and similar extensions to IPv4 would be needed… which is
> > more challenging given that no viable option is left in that space.
> > >
> > >
> > >
> > > The UDP surplus area solves that problem for both IPv4 and IPv6.
> > Obviously, it applies when UDP is used as underlying transport which
> > covers the QUIC case and many encap protocols relying upon UDP for NAT
> > traversal, entropy, etc. matters.
> > >
> > >
> > >
> > > Cheers,
> > >
> > > Med
> > >
> > >
> > >
> > > De : Tom Herbert [mailto:[e-mail]]
> > > Envoyé : mercredi 10 juillet 2019 18:28
> > > À : BOUCADAIR Mohamed TGI/OLN
> > > Cc : Lubashev, Igor; HAMCHAOUI Isabelle TGI/OLN; tsvwg; FERRIEUX
> > Alexandre TGI/OLN
> > > Objet : Re: [tsvwg] Packet Loss Signaling for Encrypted Protocols:
> > draft-ferrieuxhamchaoui-tsvwg-lossbits
> > >
> > >
> > >
> > >
> > >
> > > On Tue, Jul 9, 2019, 1:44 AM <[e-mail]> wrote:
> > >
> > > Hi Tom,
> > >
> > >
> > >
> > > I do think there is a value in structuring this as a 2-stage effort:
> > >
> > >
> > >
> > > (1)This draft, as it currently stands, which sketches the overall
> > framework. I do see a value in having this generic framework document
> > without going into details about which signal channel is used.
> > >
> > > (2)Applicability document(s)(?) which will focus more on how to convey
> > these bits: HBH is an option for IPv6, but I suggest to explore the
> > “surplus area” (udp-options) as this may be valid for both v4/v6.
> > >
> > > Med,
> > >
> > >
> > >
> > > The UDP surplus area is only useful for UDP. It doesn't help TCP for
> > instance (or SCTP, DCCP, IPsec, etc.). This is why information belongs in
> > the common network layer; we don't have to worry about how to support
> > network visible information in each and every possible transport protocol.
> > >
> > >
> > >
> > > Tom
> > >
> > >
> > >
> > > Cheers,
> > >
> > > Med
> > >
> > >
> > >
> > > De : tsvwg [mailto:[e-mail]] De la part de Tom Herbert
> > > Envoyé : mardi 9 juillet 2019 04:52
> > > À : Lubashev, Igor
> > > Cc : HAMCHAOUI Isabelle TGI/OLN; tsvwg; FERRIEUX Alexandre TGI/OLN
> > > Objet : Re: [tsvwg] Packet Loss Signaling for Encrypted Protocols:
> > draft-ferrieuxhamchaoui-tsvwg-lossbits
> > >
> > >
> > >
> > >
> > >
> > > On Mon, Jul 8, 2019, 7:10 PM Lubashev, Igor <[e-mail]> wrote:
> > >
> > > Thank you for your comments, Tom. I am pleased that you find intent of
> > the proposal admirable -- this is a major purpose of this draft.
> > >
> > > This draft is "informational", not "standards track". Its purpose it to
> > recommend a technique that would be adopted for specific protocols in
> > different protocol-specific drafts, possibly in protocol-specific WGs.
> > >
> > > As for our experiment, the bits we used were the two most significant
> > bits of TTL (IPv4) and HopLimit (IPv6). That was done mostly for
> > expediency of the implementation and good interoperability on the network.
> > >
> > >
> > >
> > > Igor,
> > >
> > >
> > >
> > > On one hand, it's good that the signaling is being done in the network
> > layer protocol, that justifies the argument that the mechanism is
> > transport independent or at least transport agnostic. On the other hand,
> > commandeering bits in protocol headers that are already allocated is
> > obviously something that shouldn't be standardized (we've previously seen
> > other attempts to repurpose defined IP fields; stealing bits from the IPv6
> > flow label seems like a common idea!).
> > >
> > >
> > >
> > > For a longer term solution, the alternative is to use the extensibility
> > mechanisms of IP (options in "legacy" IPv4, extension headers in IPv6).
> > For instance, it would be interesting to define a Hop-by-Hop extension
> > header for the loss signaling. One caveat is that a single HBH option
> > gives at least 32 bits of data to work with, so it makes sense to pack as
> > much functionality into an the option (e.g I'm thinking maybe latency
> > signaling, which also can done in two bits, might be another function in
> > the grand "Transport metrics" option).
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Tom
> > >
> > >
> > >
> > >
> > > Many thanks,
> > >
> > > - Igor
> > >
> > > -----Original Message-----
> > > From: Tom Herbert [[e-mail]]
> > > Received: Monday, 08 Jul 2019, 8:20PM
> > > To: Lubashev, Igor [[e-mail]]
> > > CC: [e-mail] [[e-mail]]; Isabelle Hamchaoui
> > [[e-mail]]; Alexandre Ferrieux
> > [[e-mail]]
> > > Subject: Re: [tsvwg] Packet Loss Signaling for Encrypted Protocols:
> > draft-ferrieuxhamchaoui-tsvwg-lossbits
> > >
> > > On Mon, Jul 8, 2019 at 2:20 PM Lubashev, Igor <[e-mail]>
> > wrote:
> > > >
> > > > Alexandre, Isabelle, and I have just posted a draft on a protocol-
> > independent method for endpoints to signal packet loss to the path, while
> > maintaining end user privacy and resisting ossification.  This method can
> > work for any protocol, but the primary focus is, of course, on protocols
> > that encrypt their headers.
> > > >
> > > > We think this loss signaling scheme (just takes 2 bits somewhere that
> > are set by the sender) is an appropriate solution for allowing networks to
> > do their job at providing high QoS and ease of troubleshooting without
> > compromising on encrypted protocol goals.
> > >
> > > Igor,
> > >
> > > While the intent of the proposal is admirable, I think both the draft
> > > and this description gloss over a critical piece of a protocol, namely
> > > what is the exact protocol that the sender uses to convey the
> > > information and the receiver knows how to unambiguously interpret it.
> > > That is, it's not enough to say that it "just takes 2 bits somewhere
> > > that are set by the sender", in order to produce robust and
> > > interoperable implementations we'll need to know _exactly_ where those
> > > two bits live. In passing the draft mentioned "e.g. two most
> > > significant its of the TTL field in IP (see [IP]) and IPv6 (see
> > > [IPv6]) headers or reserved bits in a QUIC v1 header (see
> > > [QUIC-TRANSPORT]).". I'm not sure which of those are intended to be
> > > implemented and standardized (It's not clear to me that any protocol
> > > solution for such signaling, other that IPv6 HBH headers, can be
> > > robustly defined for such signaling).
> > >
> > > >
> > > > - Igor
> > > >
> > > > P.S.
> > > >   We've implemented this proposal in some Akamai servers and have been
> > using it to serve actual end-user traffic for a subset of Orange
> > customers.  Orange has implemented passive observer that used this signal
> > to detect and identify loss.  We will discuss and analyze the data we
> > collected at maprg (while the signaling protocol details belong to tsvwg).
> > >
> > > Right, so if you've implemented something already then where were the
> > > bits put in the protocol headers?
> > >
> > > Thanks,
> > > Tom
> > >
> > > >
> > > > ----------------------------------------------------------------------
> > -------------------------------------------------------------------------
> > > >
> > > > A new version of I-D, draft-ferrieuxhamchaoui-tsvwg-lossbits-00.txt
> > > > has been successfully submitted by Igor Lubashev and posted to the
> > > > IETF repository.
> > > >
> > > > Name:           draft-ferrieuxhamchaoui-tsvwg-lossbits
> > > > Revision:       00
> > > > Title:          Packet Loss Signaling for Encrypted Protocols
> > > > Document date:  2019-07-08
> > > > Group:          Individual Submission
> > > > Pages:          9
> > > > URL:            https://www.ietf.org/internet-drafts/draft-
> > ferrieuxhamchaoui-tsvwg-lossbits-00.txt
> > > > Status:         https://datatracker.ietf.org/doc/draft-
> > ferrieuxhamchaoui-tsvwg-lossbits/
> > > > Htmlized:       https://tools.ietf.org/html/draft-ferrieuxhamchaoui-
> > tsvwg-lossbits-00
> > > > Htmlized:       https://datatracker.ietf.org/doc/html/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.
> > > >