Subject: [quicwg/base-drafts] Rejecting reduced flow control limits (#447)

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Apr 2017 21:04:33 -0700

We currently say that a sender MUST NOT reduce these limits, but don't really require or permit a receiver to enforce this.  Now, it's true that reordering might cause limits to be received out of order, and it's probably best that we not *require* a receiver to check that the limit never reduces.  However, we might want to allow a receiver to look at packet numbers, determine that the number has been reduced, and kill the connection with a flow control error.

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

---

From: Marten Seemann <[email-masked]>
Date: Thu, 20 Apr 2017 07:50:33 -0700

An old WINDOW_UPDATE (with a lower offset) might end up in a packet with a higher packet number if it is a retransmission, and the sender doesn't regenerate the frame. 

-- 
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/447#issuecomment-295764990

---

From: MikkelFJ <[email-masked]>
Date: Thu, 20 Apr 2017 08:45:31 -0700

Is there are more general control frame flooding attack concern? For example starving stream 0.

-- 
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/447#issuecomment-295786538

---

From: Martin Thomson <[email-masked]>
Date: Thu, 20 Apr 2017 16:31:21 -0700

@marten-seemann, you aren't supposed to retransmit WINDOW_UPDATE verbatim like that.  A consequence of making a change like this would be a stronger prohibition on dumb retransmission strategies.

-- 
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/447#issuecomment-295966845