Subject: [quicwg/base-drafts] A fixed transport parameter profile is legitimate (#3429)

From: Martin Thomson <[email-masked]>
Date: Thu, 06 Feb 2020 00:59:17 -0800

In the description of active_connection_id_limit, we require that the server make the value of the transport parameter conditional on the choice of connection ID from the client.

In the past, we have had the principle that either endpoint not condition its choice of transport parameter values based on anything from its peer.  We should maintain this principle throughout.

This means changing the definition of active_connection_id_limit;  @larseggert had a sense that there was another.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3429

---

From: ekr <[email-masked]>
Date: Thu, 06 Feb 2020 02:30:50 -0800

I'd like to understand what your argument is here. Is it that you *must not* condition your response, or merely that it is not necessary to.

For instance, you suppose we have a set of extensions that exist and that those extensions need to be jointly agreed on whether they will be done. The client supports some set E_c and the set of extensions E_s. The client clearly sends E_c. Is your argument that the server must send E_s and not E_c \cap E_s and the client must compute the intersection? Or that it might send either?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3429#issuecomment-582838091

---

From: Nick Harper <[email-masked]>
Date: Thu, 06 Feb 2020 03:34:31 -0800

My understanding of the argument is that we shouldn't force servers to condition their TPs based on the client's Initial packet (possibly including TPs). E.g. the server currently needs to condition its active_connection_id_limit TP based on whether the client's Initial had a zero-len SCID; PR #3426 relaxes that constraint.

Assuming we have some future sets of TPs for extensions (and these TPs are advertised values, not negotiated values) E_c on the client and E_s on the server: The server could always send E_s (so it doesn't have to condition its response), or the server could send E_c \cap E_s, and in either case the client will ignore values sent by the server not in E_c. For future extensions that have negotiated transport params, the server will have to condition those values based on what the client sent.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3429#issuecomment-582863797

---

From: Martin Thomson <[email-masked]>
Date: Thu, 06 Feb 2020 04:12:40 -0800

MAY send a fixed set (so MAY NOT condition the response I guess) or that it is not necessary to.

So managing intersection of incompatible extensions is one case where conditioning might seem to be necessary, but that can be resolved by establishing precedence for instance.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3429#issuecomment-582877541

---

From: Nick Harper <[email-masked]>
Date: Thu, 06 Feb 2020 07:04:32 -0800

I looked through the existing transport parameters for what currently conflicts with a fixed profile of transport parameters. I've only found one (apart from the already discussed active_connection_id_limit): original_connection_id. This field is necessarily dependent on what the client sends. The only way to avoid this is to not send Retry packets so you don't need to send this TP. The rest of the transport parameters appear to be independent of what the peer sent.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3429#issuecomment-582947242

---

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 06 Feb 2020 11:47:57 -0800

What about stateless_reset_token?  I doubt many servers would send a static value (or not send it at all).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3429#issuecomment-583078303

---

From: Marten Seemann <[email-masked]>
Date: Thu, 06 Feb 2020 23:56:18 -0800

> In the past, we have had the principle that either endpoint not condition its choice of transport parameter values based on anything from its peer. We should maintain this principle throughout.

@martinthomson Where did we use this principle in the past? I can't remember that we said anything like that.
Since we're using transport parameters to negotiate extensions (and extensions might use the value of the TP to negotiate *something*), I don't think this is a viable principle to follow.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3429#issuecomment-583276024

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 07 Feb 2020 00:58:27 -0800

@marten-seemann IIRC the most recent occasion that we discussed this principle is when we changed the name of `idle-timeout` to `max-idle-timeout`.

The reason we changed the name was specifically due to this principle. Each endpoint declares its maximum, instead of conditioning its value on the others. That's why it's now called max-idle-timeout, and why we require each endpoint to calculate the minimum of the two.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3429#issuecomment-583295363

---

From: ianswett <[email-masked]>
Date: Fri, 07 Feb 2020 02:43:51 -0800

My understanding is that the principle was you shouldn't be required to condition TPs based on data from the peer, not that one is precluded from doing so.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3429#issuecomment-583335470

---

From: Martin Thomson <[email-masked]>
Date: Sun, 09 Feb 2020 13:54:35 -0800

I guess that "fixed" is the wrong term.  More to the point that the transport parameters don't necessarily depend on what a peer does.  That accounts for the stateless reset case, because that only "depends" on local choices.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3429#issuecomment-583898282

---

From: Lars Eggert <[email-masked]>
Date: Wed, 19 Feb 2020 01:53:27 -0800

I think we need to see more (supportive) discussion in order to justify taking this on.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3429#issuecomment-588131809

---

From: Mike Bishop <[email-masked]>
Date: Fri, 21 Feb 2020 11:34:22 -0800

I don't know that there's much here to "take on" beyond clarifying what our design principles are, and maybe writing those down somewhere for designers of future transport parameters.  The principle here is that TPs are independent declarations by each side, not negotiations.

I've noticed as we get further and further into this process, we have a number of principles which haven't been written down which have guided our design -- and we keep revisiting them because only the resulting design is explicit.  I'm wondering if those principles belong... somewhere.  An appendix, a published draft, etc. even if not enshrined in an RFC.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3429#issuecomment-589802167

---

From: Nick Harper <[email-masked]>
Date: Fri, 21 Feb 2020 11:46:58 -0800

I agree with Mike. I noticed we already state this design principle in section 7.3: "These declarations are made unilaterally by each endpoint."

Taking on/resolving this issue brings transport parameters back in line with the stated property of them being declarations, not negotiated. I think this is a worthwhile change.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3429#issuecomment-589807097

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Feb 2020 15:13:30 -0800

Closed #3429 via 69c2d95035420cc9bc596ed1d6a3373dfbe85548.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3429#event-3071404665