Subject: [quicwg/base-drafts] WINDOW_UPDATE parameters (#329)

From: Dragana Damjanovic <[email-masked]>
Date: Tue, 21 Feb 2017 08:34:13 -0800

> Byte offset: A 64-bit unsigned integer indicating the absolute byte offset of data which can be sent on the given stream. In the case of connection-level flow control, the cumulative offset which can be sent on all streams that contribute to connection-level flow control.

Can we clarify what "the cumulative offset which can be sent on all streams" means? It reads as cumulative amount of data that can be sent on all streams including data already sent, and not an increment like in h2. 
I think this should be an increment similar to h2.

-- 
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/329

---

From: ianswett <[email-masked]>
Date: Tue, 21 Feb 2017 08:50:51 -0800

We considered that, but incremental differences are problematic when combined with reordering and loss.  Cumulative has no such problems, and the receiver can ignore old WINDOW_UPDATE values.

The only benefit I can think of for incremental would be slightly smaller encoding on the wire, but it's expected these messages are relatively infrequent, so that seems like a premature optimization.

Is there a benefit to incremental you have in mind?

-- 
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/329#issuecomment-281403638

---

From: Dragana Damjanovic <[email-masked]>
Date: Tue, 21 Feb 2017 09:49:06 -0800

The reason why I wrote this is that 2^64 is the limit to how much data can be sent on a connection, if the cumulative window updates are used.

This number is really large, therefore we do not need to change this.
I will close the issue.

Is there an error code when the connection flow control reaches 2^64 limit? or will it wrap around and start from 0? 
Is it "QUIC_FLOW_CONTROL_INVALID_WINDOW (0x80000040): : The peer received an invalid flow control window.", the explanation does not sound right?
Sorry if I miss that in the draft.

-- 
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/329#issuecomment-281421668

---

From: Dragana Damjanovic <[email-masked]>
Date: Tue, 21 Feb 2017 09:49:33 -0800

Closed #329.

-- 
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/329#event-971165752

---

From: Martin Thomson <[email-masked]>
Date: Tue, 21 Feb 2017 20:54:50 -0800

FWIW, we could allow the limit to wrap, but that adds complications and it would be a rarely used feature.

-- 
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/329#issuecomment-281569126

---

From: Mike Bishop <[email-masked]>
Date: Wed, 22 Feb 2017 10:50:40 -0800

It's a good reason for a host to send a GOAWAY and spin up a new connection, though.  The problem is going to be how much margin you give yourself.  The closer you come, the more risk you run that the last streams you allow through will collectively need to use all the space remaining in your WINDOW_UPDATE value range.  Having to RST a nearly-complete download because you can't send the necessary WINDOW_UPDATE frame seems like an unfortunate corner to be able to back yourself into, even if it's rare.

-- 
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/329#issuecomment-281764153

---

From: Dragana Damjanovic <[email-masked]>
Date: Thu, 23 Feb 2017 01:52:53 -0800

This is probably going to be the first limit that a connection will hit, not the packet ids limit.
We could also scale the offset, I do not think that the update needs to be per byte, it can be 1000Bytes as well. I do not think that we need granularity of a byte.

-- 
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/329#issuecomment-281946502

---

From: ianswett <[email-masked]>
Date: Thu, 23 Feb 2017 05:52:18 -0800

I agree, this is almost certainly the first limit we'll hit at this point.

Scaling by 1024 or a similar value seems reasonable.

-- 
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/329#issuecomment-281996474