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

[Tom Herbert <[e-mail]>]

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
> <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.
> >
>
>