Subject: Measurement bit(s) or not

From: <[email-masked]>
Date: Sat, 10 Feb 2018 18:34:54 +0100

On 07/02/2018 14:34, Brian Trammell (IETF) wrote:
 > hi Jana,
 >
 >> 3. Some sequencing information -- a few bits of the packet number perhaps
 >> -- should be revealed (for monitoring. Number of bits TBD.)
 >
 > This is the crux of the argument. On one side we have the risk of misuse and
 > ossification (well, not ossification -- these bits are *meant* for the path
 > -- rather the risk that we'll figure out later that we specified the wrong
 > thing), on the other side we have the loss of visibility into how QUIC
 > traffic interacts with the network as compared to TCP, with a side question
 > of whether or not this visibility is really the transport layer's problem
 > despite the evolution the practice of diagnostics and troubleshooting using
 > TCP information.
 >
 > If we can come to agreement on this question, everything else falls into
 > place. I have my arguments here, but as you said, this subthread is not the
 > place for them. :)

The crux indeed. So what about settling it first ?

With the troubleshooting hat, I can only stress the need for measurement bits, 
for the benefit of everybody, since s**t happens, networks are imperfect, and 
nifty encapsulations-with-seqnum will simply not be where you need them.

Now to the exact nature of these measurement bits:

Thanks to the detailed exchanges on this thread, it is by now clear that a 
simple gapless counter, even nonzero-based and XORed, is not acceptable. The 
4-bit SSN comes pretty close but is not enough when things go really wrong (and 
they will - and that's where we need the tool).

Then Kazuho's square signal and Mikkel's Pi (or any other consensual 
self-synchronizing sequence) ramification came up. They are both appealing for 
their elegance and low complexity on QUIC endpoints. Beyond their quirks 
acknowledged here, here are a few considerations for troubleshooting:

  (1) Since reordering is less of a concern to QUIC than to TCP, it becomes a 
secondary goal. This is nice, because the square doesn't see it, and the 
self-synchronizing sequence will only tolerate a mild one, and never see its 
detail like cycle length etc.

  (2) There's of course a huge difference between them in complexity for the 
midpoint: square is trivial, Pi is hefty.

Given these, a benevolent, troubleshooting-minded passive midpoint will clearly 
vote for the square. Now the obvious question is: is this acceptable, or deemed 
too easy for a Murphy, Inc. active middlebox to see upstream losses and 
benevolently wreak havoc by delaying packets ?

_________________________________________________________________________________________________________________________

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: "Gorry (erg)" <[email-masked]>
Date: Sat, 10 Feb 2018 18:01:55 +0000

> On 10 Feb 2018, at 17:34, <[email-masked]> <[email-masked]> wrote:
> 

> With the troubleshooting hat, I can only stress the need for measurement bits, for the benefit of everybody, since s**t happens, networks are imperfect, and nifty encapsulations-with-seqnum will simply not be where you need them.
> 
+1
... at the time when this is most useful for troubleshooting, a lot may be happening that is not normal.

> Thanks to the detailed exchanges on this thread, it is by now clear that a simple gapless counter, even nonzero-based and XORed, is not acceptable.
Again +1

> The 4-bit SSN comes pretty close but is not enough when things go really wrong (and they will - and that's where we need the tool).
> 
8 bits could be enough - and still would be les than 0.1% overhead.

> Then Kazuho's square signal and Mikkel's Pi (or any other consensual self-synchronizing sequence) ramification came up. They are both appealing for their elegance and low complexity on QUIC endpoints. Beyond their quirks acknowledged here, here are a few considerations for troubleshooting:
> 
> (1) Since reordering is less of a concern to QUIC than to TCP, it becomes a secondary goal. This is nice, because the square doesn't see it, and the self-synchronizing sequence will only tolerate a mild one, and never see its detail like cycle length etc.

Being able to observe that the network is doing this could still be good when debugging network faults.
> 
> (2) There's of course a huge difference between them in complexity for the midpoint: square is trivial, Pi is hefty.
> 
> Given these, a benevolent, troubleshooting-minded passive midpoint will clearly vote for the square. Now the obvious question is: is this acceptable, or deemed too easy for a Murphy, Inc. active middlebox to see upstream losses and benevolently wreak havoc by delaying packets ?
> 
No amount of encryption is going to actually prevent a middlebox/tunnel/lower layer doing things - such as link retransmission.

Gorry

---

From: "Lubashev, Igor" <[email-masked]>
Date: Sat, 10 Feb 2018 21:41:42 +0000

I am a bit sceptical about the square. With TCP, packet trace shows loss of any packet, except for SYN. The "square wave" whould show no loss at all for short connections (fewer than a "wavelength" of packets). Moreover, the square wave can only detect loss after up to the wave length of subsequent packets has been transmitted. If there is an application pause in transmission, loss may not become evident.

Basically, a spin bit or a bit pattern (like a square wave) may help in troubleshooting, but it will be more uncertain and hokey than what people come to expect of tcp. We have be very clear in acknowledging it.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sun, 11 Feb 2018 11:06:14 -0800

I already wrote this elsewhere, but the mail topic was a bit off, and I
think it might actually be a good alternative to the other approaches
balancing the simplicity of the square without the problem of having to
wait for the square half period to detect loss.

It is a fractal pattern in the form of grey code. For example an 8 bit code
that is transmitted one bit a time. Each bit represents a wave length and
changes at half the wave length. To simplify synchronisation, the same 8
bit pattern could be transmitted twice before a bit changes. This would
support half-periods of 16, 32, …, 2048 packets.

In addition, there is a lot of error correcting coding theory around this
with noise analysis and maximum likelihood decoders.

https://en.wikipedia.org/wiki/Gray_code
https://en.wikipedia.org/wiki/Constellation_diagram

The encoding is simple as per Wikipedia:

/* * This function converts an unsigned binary * number to reflected
binary Gray code. * * The operator >> is shift right. The operator ^
is exclusive or. */unsigned int binaryToGray(unsigned int num){
    return num ^ (num >> 1);}
/* * This function converts a reflected binary * Gray code number to a
binary number. * Each Gray code bit is exclusive-ored with all * more
significant bits. */unsigned int grayToBinary(unsigned int num){
    unsigned int mask = num;
    while (mask != 0)
    {
        mask = mask >> 1;
        num = num ^ mask;
    }
    return num;}
/* * A more efficient version, for Gray codes of 32 or fewer bits.
*/unsigned int grayToBinary32(unsigned int num){
    num = num ^ (num >> 16);
    num = num ^ (num >> 8);
    num = num ^ (num >> 4);
    num = num ^ (num >> 2);
    num = num ^ (num >> 1);
    return num;}

On 10 February 2018 at 22.41.51, Lubashev, Igor ([email-masked]) wrote:

I am a bit sceptical about the square. With TCP, packet trace shows loss of
any packet, except for SYN. The "square wave" whould show no loss at all
for short connections (fewer than a "wavelength" of packets). Moreover, the
square wave can only detect loss after up to the wave length of subsequent
packets has been transmitted. If there is an application pause in
transmission, loss may not become evident.

Basically, a spin bit or a bit pattern (like a square wave) may help in
troubleshooting, but it will be more uncertain and hokey than what people
come to expect of tcp. We have be very clear in acknowledging it.

-----Original Message-----
*From:* [email-masked] [[email-masked]]
*Received:* Saturday, 10 Feb 2018, 12:34PM
*To:* [email-masked] [[email-masked]]
*Subject:* Measurement bit(s) or not

With the troubleshooting hat, I can only stress the need for measurement
bits,
for the benefit of everybody, since s**t happens, networks are imperfect,
and
nifty encapsulations-with-seqnum will simply not be where you need them.

Thanks to the detailed exchanges on this thread, it is by now clear that a
simple gapless counter, even nonzero-based and XORed, is not acceptable. The
4-bit SSN comes pretty close but is not enough when things go really wrong
(and
they will - and that's where we need the tool).

Then Kazuho's square signal and Mikkel's Pi (or any other consensual
self-synchronizing sequence) ramification came up. They are both appealing
for
their elegance and low complexity on QUIC endpoints. Beyond their quirks
acknowledged here, here are a few considerations for troubleshooting:

  (1) Since reordering is less of a concern to QUIC than to TCP, it becomes
a
secondary goal. This is nice, because the square doesn't see it, and the
self-synchronizing sequence will only tolerate a mild one, and never see its
detail like cycle length etc.

Given these, a benevolent, troubleshooting-minded passive midpoint will
clearly
vote for the square. Now the obvious question is: is this acceptable, or
deemed
too easy for a Murphy, Inc. active middlebox to see upstream losses and
benevolently wreak havoc by delaying packets ?

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: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sun, 11 Feb 2018 11:25:14 -0800

Actually, since the half-period is 16*2048 so loss can be detected up to
32K packets, or typically 32MB worth of data. At the same time loss can be
detected within the first 16 bytes by trivially comparing the first 8 bits
with the next 8 bits. If these are not the same, something is off.

But it is perfect because all bits could be zero.

To improve on this, each transmitted bit could be spread over two packets,
0, 1 for sending a reset bit, and 1, 0 for sending a set bit. If we then
drop repeating the 8 bit pattern, the shortest half-period remains at 16
packets since an 8-bit Gray code requires 16 packets.

Now we can detect a single loss or swap already after two packets, although
this is probably not interesting since reordering could happen already in
multiple send queues.

On 11 February 2018 at 20.06.14, Mikkel Fahnøe Jørgensen ([email-masked])
wrote:

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 12 Feb 2018 10:20:14 +0100

hi Mikkel, Igor, Alexandre, all,

Engineering is fun, but let's step back a bit. :)

It looks like we're exploring a space of proposals that have different tradeoffs for the patterns of loss and reordering they can easily make visible, tradeoffs for sender (endpoint) versus observer (midpoint) complexity, and tradeoffs for fidelity versus overhead.

In any case, it seems like it is possible to design a signal that would be a vast improvement (from the measurement utility standpoint) over no signal and no discernible pattern in the packet number that will fit in bits scavenged from the Type field of the short header, i.e., the bandwidth overhead will be *zero*, because otherwise in an encrypted-PN world we just have to grease those bits anyway.

Back to Alexandre's question:

Do we want to do this?

Rephrased: Is the passive measurability of loss, reordering (and, if we consider the spin bit as one of the measurement bits, latency) of QUIC important to us, or do we decide we can live with the negative pressure a complete loss of visibility and an vast increase in diagnostic complexity will place on deployment?

Note, of course, that all the proposals we have so far represent a decrease in visibility and an increase in complexity of measurement compared to passive measurement of TCP. New tools will have to be developed. But the loss of visibility is minimal compared to blackout, and the deployability and feasibility of all of these is far, far better than an SSLKEYLOGFILE-based debugging approach, especially in the interdomain case.

I've heard at least one dismissal of this whole space as being too abstract to take seriously. (I'm not concerned, but maybe I've been staring at network measurement both passive and active for too long to know what's intuitive anymore.) Let me then suggest a way forward:

I've announced a table at the London hackathon for "Transport Measurability" (see https://trac.ietf.org/trac/ietf/meeting/wiki/101hackathon), which we intend to set up in the vicinity of QUIC. This was originally intended as the "Spin Bit" table, and we (from ETH) will be there working on scalable, open-source passive measurement tools both for the spin bit as well as for the current TCP TSOPT and SEQ/ACK methodologies (as a basis of comparison, mainly; at least in the case of the spin bit we so far believe the explicit signalœ to have superior usability compared to current TCP measurement). I suggest we expand the scope of table to hack on various signals for loss and reordering, and to compare their complexity and fidelity against the loss and reordering patterns we want visibility into. One output of this work could be a (smaller) set of suggestion(s) for which signal(s) to add, so that those who want to have concrete proposals to evaluate can do so.

Cheers,

Brian

> On 11 Feb 2018, at 20:25, Mikkel Fahnøe Jørgensen <[email-masked]> wrote:
> 
> Actually, since the half-period is 16*2048 so loss can be detected up to 32K packets, or typically 32MB worth of data. At the same time loss can be detected within the first 16 bytes by trivially comparing the first 8 bits with the next 8 bits. If these are not the same, something is off.
> 
> To improve on this, each transmitted bit could be spread over two packets, 0, 1 for sending a reset bit, and 1, 0 for sending a set bit. If we then drop repeating the 8 bit pattern, the shortest half-period remains at 16 packets since an 8-bit Gray code requires 16 packets.
> 
> Now we can detect a single loss or swap already after two packets, although this is probably not interesting since reordering could happen already in multiple send queues.
> On 11 February 2018 at 20.06.14, Mikkel Fahnøe Jørgensen ([email-masked]) wrote:
> 
>> I already wrote this elsewhere, but the mail topic was a bit off, and I think it might actually be a good alternative to the other approaches balancing the simplicity of the square without the problem of having to wait for the square half period to detect loss.
>> 
>> It is a fractal pattern in the form of grey code. For example an 8 bit code that is transmitted one bit a time. Each bit represents a wave length and changes at half the wave length. To simplify synchronisation, the same 8 bit pattern could be transmitted twice before a bit changes. This would support half-periods of 16, 32, …, 2048 packets.
>> 
>> In addition, there is a lot of error correcting coding theory around this with noise analysis and maximum likelihood decoders.
>> 
>> /*
>>  * This function converts an unsigned binary
>>  * number to reflected binary Gray code.
>>  *
>>  * The operator >> is shift right. The operator ^ is exclusive or.
>>  */
>> unsigned int binaryToGray(unsigned int num)
>> {
>> 
>> 
>> return num ^ (num >> 1);
>> }
>> 
>> 
>> 
>> /*
>>  * This function converts a reflected binary
>>  * Gray code number to a binary number.
>>  * Each Gray code bit is exclusive-ored with all
>>  * more significant bits.
>>  */
>> unsigned int grayToBinary(unsigned int num)
>> {
>> 
>> 
>> unsigned int mask = num;
>> 
>> 
>> while (mask != 0)
>> 
>> 
>> {
>> 
>> 
>> mask = mask >> 1;
>> 
>> 
>> num = num ^ mask;
>> 
>> 
>> }
>> 
>> 
>> return num;
>> }
>> 
>> 
>> 
>> /*
>>  * A more efficient version, for Gray codes of 32 or fewer bits.
>>  */
>> unsigned int grayToBinary32(unsigned int num)
>> {
>> 
>> 
>> num = num ^ (num >> 16);
>> 
>> 
>> num = num ^ (num >> 8);
>> 
>> 
>> num = num ^ (num >> 4);
>> 
>> 
>> num = num ^ (num >> 2);
>> 
>> 
>> num = num ^ (num >> 1);
>> 
>> 
>> return num;
>> }
>> 
>>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 12 Feb 2018 01:34:57 -0800

On 12 February 2018 at 10.20.16, Brian Trammell (IETF) ([email-masked])
wrote:

Do we want to do this?

Rephrased: Is the passive measurability of loss, reordering (and, if we
consider the spin bit as one of the measurement bits, latency) of QUIC
important to us, or do we decide we can live with the negative pressure a
complete loss of visibility and an vast increase in diagnostic complexity
will place on deployment?

Originally I did not care much, but I think there is self-interest in
supporting some level of passive monitoring:

External hostile agents that can drop packets are more easily exposed,
hence monitoring is a deterrent.

Traffic shaping by an internet provider might be exposed more easily.
Internet providers might “accidentally” misplace some netflix packets.

Routers that experience faulty paths can more readily route traffic towards
higher fidelity path in terms of latency and loss.

Omitting monitoring might just add tunnel headers increasing overhead.

Clearly there is a privacy concern, and we should not expose unnecessary
details. Packets could be sorted against the applications interest. But
this can happen with tunnel headers. Latency cannot as easily be monitored
without help, but it is not that difficult either: measure timing between
packets and find a pause, then wait for traffic the other way.

---

From: <[email-masked]>
Date: Mon, 12 Feb 2018 12:56:40 +0100

Hi Brian,

We're clearly in violent agreement about both the potential to make intelligent
use of this measurement nibble, and the desirability of *some* troubleshooting
helper. Thanks for proposing to include this discussion in the spin bit table.

As it turns out, we do have concrete illustrations to show there, on real
networks and long distances. But beyond that, I'd like to "probe" this group for
a possible veto before digging further: while I have no doubt about an eventual
consensus among us "troubleshooters", I'm more worried by the other side of the 
board: people primarily concerned about ossification and linkability, to whom
network debugging is at best a secondary goal.

More precisely, as you accurately described, the position of the cursor of both
tradeoffs may display a kind of threshold for acceptability by them :

- endpoint vs midpoint complexity: if the tool is too easy on the midpoint,
active Murphies will come in ; at kind of entry barrier should be set -- how high ?

- fidelity: the coarser, or the more delayed, the better, since it precludes any
real-time feedback loop like active Murphies do ; what is the minimum
degradation that is needed ?

On 12/02/2018 10:20, Brian Trammell (IETF) wrote:
> It looks like we're exploring a space of proposals that have different
> tradeoffs for the patterns of loss and reordering they can easily make
> visible, tradeoffs for sender (endpoint) versus observer (midpoint)
> complexity, and tradeoffs for fidelity versus overhead.
>
> In any case, it seems like it is possible to design a signal that would be a
> vast improvement (from the measurement utility standpoint) over no signal and
> no discernible pattern in the packet number that will fit in bits scavenged
> from the Type field of the short header, i.e., the bandwidth overhead will be
> *zero*, because otherwise in an encrypted-PN world we just have to grease
> those bits anyway.
>
> Note, of course, that all the proposals we have so far represent a decrease
> in visibility and an increase in complexity of measurement compared to
> passive measurement of TCP. New tools will have to be developed. But the loss
> of visibility is minimal compared to blackout, and the deployability and
> feasibility of all of these is far, far better than an SSLKEYLOGFILE-based
> debugging approach, especially in the interdomain case.
>
> I've heard at least one dismissal of this whole space as being too abstract
> to take seriously. (I'm not concerned, but maybe I've been staring at network
> measurement both passive and active for too long to know what's intuitive
> anymore.) Let me then suggest a way forward:
>
> I've announced a table at the London hackathon for "Transport Measurability"
> (see https://trac.ietf.org/trac/ietf/meeting/wiki/101hackathon), which we
> intend to set up in the vicinity of QUIC. This was originally intended as the
> "Spin Bit" table, and we (from ETH) will be there working on scalable,
> open-source passive measurement tools both for the spin bit as well as for
> the current TCP TSOPT and SEQ/ACK methodologies (as a basis of comparison,
> mainly; at least in the case of the spin bit we so far believe the explicit
> signalœ to have superior usability compared to current TCP measurement). I
> suggest we expand the scope of table to hack on various signals for loss and
> reordering, and to compare their complexity and fidelity against the loss and
> reordering patterns we want visibility into. One output of this work could be
> a (smaller) set of suggestion(s) for which signal(s) to add, so that those
> who want to have concrete proposals to evaluate can do so.
>
> Cheers,
>
> Brian
>
> [...]

>>>>
>>>> -----Original Message----- From: [email-masked]
>>>> [[email-masked]] Received: Saturday, 10 Feb 2018,
>>>> 12:34PM To: [email-masked] [[email-masked]] Subject: Measurement bit(s)
>>>> or not
>>>>
>>>>>> 3. Some sequencing information -- a few bits of the packet number
>>>>>> perhaps -- should be revealed (for monitoring. Number of bits
>>>>>> TBD.)
>>>>>
>>>>> This is the crux of the argument. On one side we have the risk of
>>>>> misuse and ossification (well, not ossification -- these bits are
>>>>> *meant* for the path -- rather the risk that we'll figure out later
>>>>> that we specified the wrong thing), on the other side we have the
>>>>> loss of visibility into how QUIC traffic interacts with the network
>>>>> as compared to TCP, with a side question of whether or not this
>>>>> visibility is really the transport layer's problem despite the
>>>>> evolution the practice of diagnostics and troubleshooting using TCP
>>>>> information.
>>>>>
>>>>> If we can come to agreement on this question, everything else falls
>>>>> into place. I have my arguments here, but as you said, this subthread
>>>>> is not the place for them. :)
>>>>
>>>> With the troubleshooting hat, I can only stress the need for
>>>> measurement bits, for the benefit of everybody, since s**t happens,
>>>> networks are imperfect, and nifty encapsulations-with-seqnum will
>>>> simply not be where you need them.
>>>>
>>>> Thanks to the detailed exchanges on this thread, it is by now clear
>>>> that a simple gapless counter, even nonzero-based and XORed, is not
>>>> acceptable. The 4-bit SSN comes pretty close but is not enough when
>>>> things go really wrong (and they will - and that's where we need the
>>>> tool).
>>>>
>>>> self-synchronizing sequence) ramification came up. They are both
>>>> appealing for their elegance and low complexity on QUIC endpoints.
>>>> Beyond their quirks acknowledged here, here are a few considerations
>>>> for troubleshooting:
>>>>
>>>> (1) Since reordering is less of a concern to QUIC than to TCP, it
>>>> becomes a secondary goal. This is nice, because the square doesn't see
>>>> it, and the self-synchronizing sequence will only tolerate a mild one,
>>>> and never see its detail like cycle length etc.
>>>>
>>>> (2) There's of course a huge difference between them in complexity for
>>>> the midpoint: square is trivial, Pi is hefty.
>>>>
>>>> clearly vote for the square. Now the obvious question is: is this
>>>> acceptable, or deemed too easy for a Murphy, Inc. active middlebox to
>>>> see upstream losses and benevolently wreak havoc by delaying packets ?
>>>>

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 12 Feb 2018 13:35:02 +0100

hi Alexandre,

> On 12 Feb 2018, at 12:56, [email-masked] wrote:
> 
> Hi Brian,
> 
> consensus among us "troubleshooters", I'm more worried by the other side of the board: people primarily concerned about ossification and linkability, to whom

While our experience with TCP here provides ample, loud warning about the dangers of letting the middle know too much, IMO these worries are a little misplaced with QUIC.

Two important things to note:

(1) A middlebox that speaks TCP can modify the header without breaking the connection, and it knows which ACK belongs with which packet. It has a wide variety of actions available to it: it can delay or drop packets; coalesce, delay, or even falsify ACKs; manipulate seq/ack and timestamps (though I don't know of any that do the latter), and so on. A middlebox that understands QUIC can only delay or drop a packet.

(2) Nobody will buy (or build and deploy) middlebox that can't even pretend to solve a problem. If we've designed QUIC such that selective drop or delay of packets based only on path-observable latency and loss will improve performance for anyone, we have done something horribly wrong.

In general, the cost of deriving a measurement from a signal should be paid by the user of the measurement, not the endpoint generating the signal (principle 3 from Principles for Measurability in Protocol Design (https://arxiv.org/pdf/1612.02902.pdf) if you're playing along at home :). This isn't meant to make it harder to mess something up, rather to make it so easy to implement the signal at the endpoint that doing so isn't seen as a negative tradeoff.

Fidelity is a hard one. Some troubleshooting tasks turn on the pattern of losses, which means you really want to know *which* packet was lost. Again, knowing which packet was lost doesn't give a QUIC-understanding measurement box as much freedom to get things wrong as the equivalent TCP box.

Cheers,

Brian

---

From: "Gorry (erg)" <[email-masked]>
Date: Mon, 12 Feb 2018 15:00:02 +0100

Since this is now discussing issues that relate to any new protocol at the transport layer, I would be interested in understanding the impacts on current practice. I have written:
draft-fairhurst-tsvwg-transport-encrypt-06

To explore some of these topics across a wider front than just QUIC. Thoughts welcome,

Gorry 

> On 12 Feb 2018, at 12:56, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Brian,
>