Subject: [Taps] How to handle Protocol stacks that are not equivalent

From: "Philipp S. Tiesel" <[email-masked]>
Date: Mon, 22 Jul 2019 17:16:05 -0400

Hi,

as time did not permit to discuss all open issues in the session today, I’ll take them to the list as proposed.
This issue is based on Github issue #305: https://github.com/ietf-tapswg/api-drafts/issues/305

Following the architecture draft, only protocol stacks that are equivalent can be safely raced. What should happen if selection properties result in a candidate set that includes protocol stacks that are not intuitively equivalent?

Resolution Proposals:

a) Define Protocol Stack Equivalence more rigorously. A possible way to do this would be to say two stacks are equivalent with respect to the applications’ requirements if both fulfil all require properties specified by the applications and do not violate any of the prohibit properties.

b) Generate some kind of Error Event for configurations with unlike protocol stack candidates. (May need a definition of "unlike”).

c) Do nothing and close the issue.

AVE!
   Philipp S. Tiesel

-- 
Philipp S. Tiesel 
https://philipp.tiesel.net/

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 23 Jul 2019 10:31:12 -0400

My initial impression here is that any protocol stacks that provide the same transport services, and thus can be raced as candidates, need to be equivalent. It ends up being a bit tautological. The description in the architecture explains what combinations are allowed based on preference—if you don't require reliability, then a UDP protocol stack is equivalent to a message protocol over TCP. If you do require reliability, then those aren't equivalent.

Thanks,
Tommy

> On Jul 22, 2019, at 5:16 PM, Philipp S. Tiesel <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 23 Jul 2019 11:08:15 -0400

> My initial impression here is that any protocol stacks that provide the same transport services, and thus can be raced as candidates, need to be equivalent. It ends up being a bit tautological. The…
That makes sense to me.

Gorry
>> On Jul 22, 2019, at 5:16 PM, Philipp S. Tiesel<[email-masked]>  wrote:
>>
>> Hi,
>>

---

From: Theresa Enghardt <[email-masked]>
Date: Tue, 23 Jul 2019 11:19:14 -0400

Hi,

>> […] if you don't require reliability, then a UDP protocol stack is
>> equivalent to a message protocol over TCP. If you do require
>> reliability, then those aren't equivalent.

Another important difference between TCP and UDP are Message Boundaries.
So in some cases, TCP + Framer may be equivalent to UDP.

We probably don't want to put that in the Architecture draft, but a
Framer can essentially provide the "Message boundaries" property, thus,
making TCP equivalent to UDP if Message boundaries are required, right?

Maybe that's something for Implementation draft? But the application may
also want to know about the possibility to essentially use TCP or UDP
without having to change (much)? Thinking about DNS, even if there may
be more stuff to consider here, such as the EDNS0 features Ted Hardie
mentioned.

Best,
Theresa

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 23 Jul 2019 11:24:36 -0400

> On Jul 23, 2019, at 11:19 AM, Theresa Enghardt <[email-masked]> wrote:
> 
> Hi,
> 

Exactly! That's what I meant by "a message protocol over TCP".
> making TCP equivalent to UDP if Message boundaries are required, right?

Yes, I think that's already implicit in the text in Section 4.2.3, point 1. TCP doesn't preserve boundaries on its own/if it's the top (but does if there's another protocol that does).
> be more stuff to consider here, such as the EDNS0 features Ted Hardie

I agree that the implementation document is a more appropriate place to discuss the particulars of which protocols can be determined to be equivalent.

Thanks,
Tommy

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 Jul 2019 08:55:34 -0700

> On Jul 23, 2019, at 8:19 AM, Theresa Enghardt <[email-masked]> wrote:
> 

FWIW, they might provide *similar* capabilities, even only those that the app is concerned about, but there are a LOT of other differences that can’t be glossed over. In some cases, it is TCP that is lacking (as above); in others, UDP).

It’s only important whether the user does or doesn’t care about those properties. When they match what they care about, they can be considered equivalent.

I.e., there’s not likely going to be a strict and absolute equivalence between transports.

Equivalence is TO THE USER, relative to their constraints.

Joe

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 23 Jul 2019 11:59:24 -0400

Hi Joe,

Yes, I completely agree. The current text in -arch expresses this as:

   2.  Both stacks MUST offer the same transport services, as required
       by the application.  For example, if an application specifies
       that it requires reliable transmission of data, then a Protocol
       Stack using UDP without any reliability layer on top would not be
       allowed to replace a Protocol Stack using TCP.  However, if the
       application does not require reliability, then a Protocol Stack
       that adds unnecessary reliability might be allowed as an
       equivalent Protocol Stack as long as it does not conflict with
       any other application-requested properties.

If you think we can clarify this any further, let me know!

Thanks,
Tommy

> On Jul 23, 2019, at 11:55 AM, Joe Touch <[email-masked]> wrote:
> 
> 
> 
>> On Jul 23, 2019, at 8:19 AM, Theresa Enghardt <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Max Franke <[email-masked]>
Date: Tue, 23 Jul 2019 12:05:55 -0400

So if I understand this correctly, this boils down to the fact that if two protocols are in the candidate set for racing they are also equivalent? Thus we dont have to worry about unequivalent protocols as they are never part of the same candidate set anyway?

Best

Max

Am 23.07.2019 11:59 schrieb Tommy Pauly <tpauly=[email-masked]>:

Hi Joe,

Thanks,

Tommy

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 Jul 2019 09:14:45 -0700

You've specified this as if it were an individual property. You need to
deal with sets of properties, perhaps including choices (A and B) or (A
and C) but not (A and B and D)...

This is widely known as "constraint satisfaction", unsurprisingly.

Joe

On 7/23/2019 8:59 AM, Tommy Pauly wrote:
>> On Jul 23, 2019, at 11:55 AM, Joe Touch <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>
>>
>>> On Jul 23, 2019, at 8:19 AM, Theresa Enghardt
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>> FWIW, they might provide *similar* capabilities, even only those that
>> the app is concerned about, but there are a LOT of other differences
>> that can’t be glossed over. In some cases, it is TCP that is lacking
>> (as above); in others, UDP).
>>
>> It’s only important whether the user does or doesn’t care about those
>> properties. When they match what they care about, they can be
>> considered equivalent.
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 23 Jul 2019 13:51:42 -0400

Yes, that's correct. My interpretation is that being in the candidate set already requires equivalence. We can make the text more clear here, but it isn't a technical change.

Thanks,
Tommy

> On Jul 23, 2019, at 12:05 PM, Max Franke <[email-masked]> wrote:
> 
> On Jul 23, 2019, at 11:55 AM, Joe Touch <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>

---

From: Anna Brunström <[email-masked]>
Date: Tue, 23 Jul 2019 20:53:06 +0000

From: Taps <[email-masked]> On Behalf Of Tommy Pauly
Sent: den 23 juli 2019 19:52
To: Max Franke <[email-masked]>
Cc: Joe Touch <[email-masked]>; Tommy Pauly <tpauly=[email-masked]>; Theresa Enghardt <[email-masked]>; [email-masked]
Subject: Re: [Taps] How to handle Protocol stacks that are not equivalent

Yes, that's correct. My interpretation is that being in the candidate set already requires equivalence.

Same here, seems we all agree on this.

Thanks,
Anna

We can make the text more clear here, but it isn't a technical change.

Thanks,
Tommy

On Jul 23, 2019, at 12:05 PM, Max Franke <[email-masked]<mailto:[email-masked]>> wrote:

Best
Max

Am 23.07.2019 11:59 schrieb Tommy Pauly <tpauly=[email-masked]<mailto:tpauly=[email-masked]>>:
Hi Joe,

Thanks,
Tommy

On Jul 23, 2019, at 11:55 AM, Joe Touch <[email-masked]<mailto:[email-masked]>> wrote:

On Jul 23, 2019, at 8:19 AM, Theresa Enghardt <[email-masked]<mailto:[email-masked]>> wrote:

Joe

_______________________________________________
Taps mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/taps

_______________________________________________
Taps mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/taps

---

From: Theresa Enghardt <[email-masked]>
Date: Tue, 23 Jul 2019 17:30:03 -0400

Hi, (trimmed Cc list)

On 23.07.19 16:53, Anna Brunström wrote:
>
> *Subject:* Re: [Taps] How to handle Protocol stacks that are not
> equivalent
>
>  
>
Agreed.

However, the equivalence question becomes way more interesting once
you're adding security.

TLS 1.2 is not equivalent to TLS 1.3, therefore you can't race them, the
Architecture clearly says so and I agree.

As the application probably never asked for any specific version -- What
if our TCP stack only supports TLS 1.2 but our QUIC stack offers
basically TLS 1.3? We always take the better version and then fall back
in case this fails? But wouldn't that be racing?

I think this is also an interesting question for the Implementation draft.

Best,
Theresa

---

From: Max Franke <[email-masked]>
Date: Tue, 23 Jul 2019 17:56:22 -0400

Good point, I guess this might be true for other things as well.
Take SCTP for example, you might not know if it is multistream or not until after it has already been raced and the association has been established.
So for some transport properties you might have to race protocols before you can determine if two protocol stacks are equivalent or not.

Best

Max

Am 23.07.2019 17:30 schrieb Theresa Enghardt <[email-masked]>:

Hi, (trimmed Cc list)

On 23.07.19 16:53, Anna Brunström
wrote:

Subject: Re: [Taps] How to handle
Protocol stacks that are not equivalent

Yes, that's
correct. My interpretation is that being in the candidate set
already requires equivalence.

Agreed.

However, the equivalence question becomes way more interesting
once you're adding security.

TLS 1.2 is not equivalent to TLS 1.3, therefore you can't race
them, the Architecture clearly says so and I agree.

As the application probably never asked for any specific version
-- What if our TCP stack only supports TLS 1.2 but our QUIC stack
offers basically TLS 1.3? We always take the better version and
then fall back in case this fails? But wouldn't that be racing?

I think this is also an interesting question for the
Implementation draft.

Best,

Theresa

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Wed, 24 Jul 2019 10:10:56 -0400

> On 23. Jul 2019, at 17:56, Max Franke <[email-masked]> wrote:
> 

No! - That is exactly the reason why we need to clarify that “equivalent” actually means “satisfies requires/prohibits set by the application/profile” – that means setting all to ignore will make all protocols equivalent!

> However, the equivalence question becomes way more interesting once you're adding security.
> 
> TLS 1.2 is not equivalent to TLS 1.3, therefore you can't race them, the Architecture clearly says so and I agree. 
> 
> As the application probably never asked for any specific version -- What if our TCP stack only supports TLS 1.2 but our QUIC stack offers basically TLS 1.3? We always take the better version and then fall back in case this fails? But wouldn't that be racing?
> 

AVE!
   Philipp S. Tiesel