Subject: Re: [quicwg/base-drafts] explain that and endpoint cannot expect the delivery of the peer's settings (5fadbbb)

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Aug 2019 17:11:37 -0700

I don't get this latter part of the sentence.  I think that we should mandate, with a "MUST", that endpoints not wait for a peer's SETTINGS frame before sending their own.

-- 
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/commit/5fadbbbff7a5e566a2c951376be7999aca2c7edb#commitcomment-34801559

---

From: Mike Bishop <[email-masked]>
Date: Mon, 26 Aug 2019 07:20:45 -0700

I think the situation @kazuho is trying to describe is that, for whatever reason, the SETTINGS frame isn't transmitted until the sender has something *else* to send on the control stream.  Since that is required to come after SETTINGS, it finally sends SETTINGS then.

-- 
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/commit/5fadbbbff7a5e566a2c951376be7999aca2c7edb#commitcomment-34833956

---

From: Martin Thomson <[email-masked]>
Date: Mon, 26 Aug 2019 16:35:40 -0700

Yeah, I don't think that this would be helpful.  I don't see how postponement of transmission in that sort of arbitrary fashion would be a good idea.  Sure, lost packets happen, but the contract is that the message is sent as soon as the connection opens.

-- 
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/commit/5fadbbbff7a5e566a2c951376be7999aca2c7edb#commitcomment-34841023

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 26 Aug 2019 17:28:35 -0700

@MikeBishop 
> I think the situation @kazuho is trying to describe is that, for whatever reason, the SETTINGS frame isn't transmitted until the sender has something _else_ to send on the control stream. Since that is required to come after SETTINGS, it finally sends SETTINGS then.

Yes, that is what this sentence tried to state. OTOH, I am somewhat negative against allowing such postponement, as @martinthomson says.

The contract should either be "SHOULD send" & "MUST NOT block on receipt" or "MUST send" & "SHOULD NOT block on receipt". At the moment, #2986 takes the latter approach.

-- 
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/commit/5fadbbbff7a5e566a2c951376be7999aca2c7edb#commitcomment-34841323

---

From: ianswett <[email-masked]>
Date: Mon, 26 Aug 2019 21:25:00 -0700

Agreed @kazuho , I think both of those contracts are consistent.

-- 
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/commit/5fadbbbff7a5e566a2c951376be7999aca2c7edb#commitcomment-34842762

---

From: Martin Thomson <[email-masked]>
Date: Mon, 26 Aug 2019 22:32:33 -0700

How about we change this to simply:

> An endpoint cannot assume the peer's settings to arrive in a timely manner, as the packet carrying the settings can be lost or delayed.

Implying the possibility of postponement tends to have the effect of endorsing it.

-- 
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/commit/5fadbbbff7a5e566a2c951376be7999aca2c7edb#commitcomment-34843275

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 27 Aug 2019 00:32:52 -0700

@martinthomson Makes sense. Applied as 29ce7d6 in #2986.

-- 
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/commit/5fadbbbff7a5e566a2c951376be7999aca2c7edb#commitcomment-34844410