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

From: "Lubashev, Igor" <[email-masked]>
Date: Mon, 8 Jul 2019 21:16:41 +0000

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

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

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

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.

---

From: Tom Herbert <[email-masked]>
Date: Mon, 8 Jul 2019 17:19:56 -0700

> 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 troub…

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

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

Right, so if you've implemented something already then where were the
bits put in the protocol headers?

Thanks,
Tom

---

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

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.

Many thanks,

- Igor

-----Original Message-----
From: Tom Herbert [[email-masked]]
Received: Monday, 08 Jul 2019, 8:20PM
To: Lubashev, Igor [[email-masked]]
CC: [email-masked] [[email-masked]]; Isabelle Hamchaoui [[email-masked]]; Alexandre Ferrieux [[email-masked]]
Subject: Re: [tsvwg] Packet Loss Signaling for Encrypted Protocols: draft-ferrieuxhamchaoui-tsvwg-lossbits

Igor,

Thanks,
Tom

---

From: Tom Herbert <[email-masked]>
Date: Mon, 8 Jul 2019 19:51:44 -0700

On Mon, Jul 8, 2019, 7:10 PM Lubashev, Igor <[email-masked]> 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

> *From:* Tom Herbert [[email-masked]]
> *Received:* Monday, 08 Jul 2019, 8:20PM
> *To:* Lubashev, Igor [[email-masked]]
> *CC:* [email-masked] [[email-masked]]; Isabelle Hamchaoui [
> [email-masked]]; Alexandre Ferrieux [
> [email-masked]]
> *Subject:* Re: [tsvwg] Packet Loss Signaling for Encrypted Protocols:
> draft-ferrieuxhamchaoui-tsvwg-lossbits
>
> > 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,
>
> >   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).
>
> > 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:

---

From: <[email-masked]>
Date: Tue, 9 Jul 2019 08:44:13 +0000

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.

Cheers,
Med

De : tsvwg [mailto:[email-masked]] 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 <[email-masked]<mailto:[email-masked]>> 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.

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 [[email-masked]<mailto:[email-masked]>]
Received: Monday, 08 Jul 2019, 8:20PM
To: Lubashev, Igor [[email-masked]<mailto:[email-masked]>]
CC: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>]; Isabelle Hamchaoui [[email-masked]<mailto:[email-masked]>]; Alexandre Ferrieux [[email-masked]<mailto:[email-masked]>]
Subject: Re: [tsvwg] Packet Loss Signaling for Encrypted Protocols: draft-ferrieuxhamchaoui-tsvwg-lossbits

Igor,

Thanks,
Tom

> Htmlized:       https://tools.ietf.org/html/draft-ferrieuxhamchaoui-tsvwg-lossbits-00<https://tools..ietf.org/html/draft-ferrieuxhamchaoui-tsvwg-lossbits-00>

---

From: Giuseppe Fioccola <[email-masked]>
Date: Wed, 10 Jul 2019 14:54:21 +0000

Dear Igor, Alexandre, Isabelle,
I have had a look at the draft and I think it is an interesting proposal for packet loss signaling and it is good to have a protocol independent document.
In addition, I would suggest to add a reference to RFC 8321 that introduces the packet loss measurement methodology through the alternate marking schema, as reported in Section 3 of your draft. 

Best Regards,

Giuseppe

-----Original Message-----
From: tsvwg [mailto:[email-masked]] On Behalf Of Lubashev, Igor
Sent: Monday, July 8, 2019 11:17 PM
To: [email-masked]
Cc: Isabelle Hamchaoui <[email-masked]>; Alexandre Ferrieux <[email-masked]>
Subject: [tsvwg] Packet Loss Signaling for Encrypted Protocols: draft-ferrieuxhamchaoui-tsvwg-lossbits

- Igor

P.S.

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.

Abstract:

---

From: Tom Herbert <[email-masked]>
Date: Wed, 10 Jul 2019 09:27:42 -0700

On Tue, Jul 9, 2019, 1:44 AM <[email-masked]> wrote:

> (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:[email-masked]] *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:
> <https://tools..ietf.org/html/draft-ferrieuxhamchaoui-tsvwg-lossbits-00>
> > Htmlized:

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 10 Jul 2019 16:53:41 +0000

Giuseppe, thank you very much for this feedback and a pointer to RFC 8321.  We'll definitely mention it in the next rev of the draft.

I see that RFC 8321 did introduce what we are calling a "sQuare bit" for alternate marking of blocks of packets. That's a method to estimate upstream loss.

Our draft is also using what we call "Loss event" bit that allows a single observer to estimate the end-to-end loss as well.  The combination of Q bit (RFC 8321) and the new L bit lets an observer do significantly more than RFC 8321 allows. 

- Igor

-----Original Message-----
From: Giuseppe Fioccola <[email-masked]> 
Sent: Wednesday, July 10, 2019 10:54 AM

Best Regards,

Giuseppe

-----Original Message-----
From: tsvwg [mailto:[email-masked]] On Behalf Of Lubashev, Igor
Sent: Monday, July 8, 2019 11:17 PM
To: [email-masked]
Cc: Isabelle Hamchaoui <[email-masked]>; Alexandre Ferrieux <[email-masked]>
Subject: [tsvwg] Packet Loss Signaling for Encrypted Protocols: draft-ferrieuxhamchaoui-tsvwg-lossbits

- Igor

P.S.

Abstract:

---

From: Giuseppe Fioccola <[email-masked]>
Date: Wed, 10 Jul 2019 18:01:30 +0000

Hi Igor,
Thank you for considering the mention to RFC 8321.
Agree, the combination of Q bit and L bit helps the applicability of the alternate marking method.
In fact, we are also working on another draft in IPPM with the purpose to define how to deploy alternate marking.

Let's discuss further in Montreal.

Regards,

Giuseppe

-----Original Message-----
From: Lubashev, Igor [mailto:[email-masked]] 
Sent: Wednesday, July 10, 2019 6:54 PM
To: Giuseppe Fioccola <[email-masked]>; [email-masked]
Cc: Isabelle Hamchaoui <[email-masked]>; Alexandre Ferrieux <[email-masked]>; Cociglio Mauro <[email-masked]>
Subject: RE: Packet Loss Signaling for Encrypted Protocols: draft-ferrieuxhamchaoui-tsvwg-lossbits

- Igor

-----Original Message-----
From: Giuseppe Fioccola <[email-masked]> 
Sent: Wednesday, July 10, 2019 10:54 AM

Best Regards,

Giuseppe

-----Original Message-----
From: tsvwg [mailto:[email-masked]] On Behalf Of Lubashev, Igor
Sent: Monday, July 8, 2019 11:17 PM
To: [email-masked]
Cc: Isabelle Hamchaoui <[email-masked]>; Alexandre Ferrieux <[email-masked]>
Subject: [tsvwg] Packet Loss Signaling for Encrypted Protocols: draft-ferrieuxhamchaoui-tsvwg-lossbits

- Igor

P.S.

Abstract:

---

From: <[email-masked]>
Date: Thu, 11 Jul 2019 06:52:49 +0000

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:[email-masked]]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tom,

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

Igor,

Thanks,
Tom

Many thanks,

- Igor

-----Original Message-----
From: Tom Herbert [[email-masked]<mailto:[email-masked]>]
Received: Monday, 08 Jul 2019, 8:20PM
To: Lubashev, Igor [[email-masked]<mailto:[email-masked]>]
CC: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>]; Isabelle Hamchaoui [[email-masked]<mailto:[email-masked]>]; Alexandre Ferrieux [[email-masked]<mailto:[email-masked]>]
Subject: Re: [tsvwg] Packet Loss Signaling for Encrypted Protocols: draft-ferrieuxhamchaoui-tsvwg-lossbits

Igor,

Thanks,
Tom

---

From: <[email-masked]>
Date: Thu, 11 Jul 2019 10:19:23 +0000

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,

Cheers,
Med

Tom

Cheers,
Med

Igor,

Thanks,
Tom

Many thanks,

- Igor

-----Original Message-----
From: Tom Herbert [[email-masked]<mailto:[email-masked]>]
Received: Monday, 08 Jul 2019, 8:20PM
To: Lubashev, Igor [[email-masked]<mailto:[email-masked]>]
CC: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>]; Isabelle Hamchaoui [[email-masked]<mailto:[email-masked]>]; Alexandre Ferrieux [[email-masked]<mailto:[email-masked]>]
Subject: Re: [tsvwg] Packet Loss Signaling for Encrypted Protocols: draft-ferrieuxhamchaoui-tsvwg-lossbits

Igor,

Thanks,
Tom

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Thu, 11 Jul 2019 12:22:22 +0000

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

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,

Cheers,

Isabelle

Hi Tom,

Cheers,
Med

Tom

Cheers,
Med

Igor,

Thanks,
Tom

Many thanks,

- Igor

-----Original Message-----
From: Tom Herbert [[email-masked]<mailto:[email-masked]>]
Received: Monday, 08 Jul 2019, 8:20PM
To: Lubashev, Igor [[email-masked]<mailto:[email-masked]>]
CC: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>]; Isabelle Hamchaoui [[email-masked]<mailto:[email-masked]>]; Alexandre Ferrieux [[email-masked]<mailto:[email-masked]>]
Subject: Re: [tsvwg] Packet Loss Signaling for Encrypted Protocols: draft-ferrieuxhamchaoui-tsvwg-lossbits

Igor,

Thanks,
Tom

---

From: Tom Herbert <[email-masked]>
Date: Thu, 11 Jul 2019 11:07:15 -0700

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

---

From: <[email-masked]>
Date: Tue, 16 Jul 2019 05:50:35 +0000

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-----
> Envoyé : jeudi 11 juillet 2019 20:07
> Cc : HAMCHAOUI Isabelle TGI/OLN; Lubashev, Igor; tsvwg; FERRIEUX Alexandre
> TGI/OLN; RONTEIX JACQUET Flavien TGI/OLN
> > 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,
> 
> > 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.
> >
> > 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
> >
> >
> >
> > 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.
> >
> > 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,
> >
> >
> >
> layer protocol, that justifies the argument that the mechanism is
> transport independent or at least transport agnostic. On the other hand,
> 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
> >
> > CC: [email-masked] [[email-masked]]; Isabelle Hamchaoui
> [[email-masked]]; Alexandre Ferrieux
> [[email-masked]]
> > > 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.
> > >
> > > ----------------------------------------------------------------------
> -------------------------------------------------------------------------
> > >

---

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

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

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