Subject: Re: [quicwg/base-drafts] Increasing initial flow control window for streams (#219)

From: ianswett <[email-masked]>
Date: Mon, 15 Jan 2018 22:52:05 +0000 (UTC)

After thinking about this more, I can also imagine cases when you'd like to decrease the initial flow control window for new streams(ie: peer's memory becomes more constrained), but that would introduce a race condition where new streams assumed the old, larger window value.  The only solution to that I can think of is not enforcing the new smaller value it has been acknowledged.  It's a bit of complexity, but it seems viable, and the complexity is only present for those who wish to send smaller values.

I think we're going to end up wanting a transport parameters update frame for this use case and potentially the explicit max ack delay(Issue #912) and probably a few more things down the line, so I'm leaning towards adding one now.

-- 
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/219#issuecomment-357806971

---

From: Martin Thomson <[email-masked]>
Date: Mon, 15 Jan 2018 15:00:47 -0800

A generic mechanism is much harder to design correctly.  Updating transport parameters creates the problem for every parameter, forcing every parameter to deal with the transition.  If the intent is to update the initial flow control window, you could add a specific mechanism that marked a certain stream ID as the point at which the new setting applied.  That would be much easier to design.

-- 
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/219#issuecomment-357808148

---

From: ianswett <[email-masked]>
Date: Mon, 15 Jan 2018 23:03:44 +0000 (UTC)

There's no guarantee a peer hasn't already created a larger stream number than the one you specify, unless you state the update can't apply to any streams smaller than the max stream id, which seems unfortunate.

The approximate mechanism I'm proposing is that for parameters that want updating, they MUST take effect when the UPDATE_TRANSPORT_PARAMS frame is received and the sender MAY assume that they have taken effect as soon as the packet containing the UPDATE_TRANSPORT_PARAMS frame is acked.

-- 
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/219#issuecomment-357808563

---

From: Martin Thomson <[email-masked]>
Date: Mon, 15 Jan 2018 15:06:23 -0800

What about limits that are exceeded while the update is in flight?

-- 
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/219#issuecomment-357808906

---

From: ianswett <[email-masked]>
Date: Mon, 15 Jan 2018 23:22:12 +0000 (UTC)

They can't be enforced until the sender receives an acknowledgement.

-- 
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/219#issuecomment-357811001

---

From: Martin Thomson <[email-masked]>
Date: Mon, 15 Jan 2018 15:34:36 -0800

And not for packets that are reordered around that acknowledgment.  That's a lot of complexity.  We had to deal with negative flow control credits in h2, and I'm still not certain that it is implemented correctly.  You are asking for something that is incrementally more complex again.

-- 
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/219#issuecomment-357812597

---

From: ianswett <[email-masked]>
Date: Mon, 15 Jan 2018 18:59:03 -0800

It's only a lot of complexity for implementations that want to decrease initial flow control windows or similar changes which would make prior behavior no longer acceptable.  Some(probably most) implementations will only want to increase windows, but I think it's worth thinking about how to deal with those cases as well.

-- 
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/219#issuecomment-357840258

---

From: Martin Thomson <[email-masked]>
Date: Mon, 15 Jan 2018 20:19:17 -0800

It's complexity on their peers that I worry most about.  I'm sure that if you want to reduce windows, then you will take on that complexity.  But that's not necessarily true of everyone you talk to.

-- 
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/219#issuecomment-357849806

---

From: MikkelFJ <[email-masked]>
Date: Tue, 16 Jan 2018 08:33:05 +0000 (UTC)

A reduction in permissions could be seen as a new connection path, and a new path might need some parameters updated. If a new connection is created on a new path, it is known to respect the parameters of that path it would seem. So drastic non-trivial changes could possibly be handled as a migration thing.

-- 
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/219#issuecomment-357888085

---

From: Patrick McManus <[email-masked]>
Date: Tue, 16 Jan 2018 06:35:57 -0800

I will say that the ability to decrease a window is something I wanted in H2 and on a number of occasions have been sad that it did not make it in. The feature may very well be worth the complexity.

-- 
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/219#issuecomment-357978866

---

From: ianswett <[email-masked]>
Date: Tue, 16 Jan 2018 06:41:14 -0800

On the peer side, it's easy.  All newly created streams get the new window value.  All previously created streams are unchanged.  I think it's just a matter of copying the new value over the old value.

-- 
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/219#issuecomment-357980676