Subject: [quicwg/base-drafts] Do we really need a "final offset" in the Reset Stream frame? (#749)

From: Christian Huitema <[email-masked]>
Date: Wed, 23 Aug 2017 19:00:48 -0700

Or, what is the node that receives the Reset Stream supposed to do with the Final Offset?

The text says, "discard immediately". That rules out any idea of receiving the bytes up to the final offset before closing. So, what's the point, exactly?

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Aug 2017 21:01:49 -0700

https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#edge-cases-and-other-considerations

-- 
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/749#issuecomment-324526767

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Aug 2017 04:01:49 +0000 (UTC)

Closed #749.

-- 
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/749#event-1219026075

---

From: Christian Huitema <[email-masked]>
Date: Wed, 23 Aug 2017 21:47:11 -0700

Yes, OK. But then, a pointer from the reset stream description to these considerations would help.

-- 
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/749#issuecomment-324531709

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 27 Aug 2017 03:55:07 +0000 (UTC)

@martinthomson Could the requirement be abolished if we define the connection-level flow control window as the number of octets sent using STREAM frames (excluding stream_id=0), instead of defining it as the number of octets sent over the streams (excluding stream_id=0)?

I would argue that the bonus here is much more than removing the `final_offset` field. I think that we can get rid of the responding `RST_STREAM` frame as a whole if we change the way we calculate the connection-level flow control window.

-- 
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/749#issuecomment-325175583

---

From: Martin Thomson <[email-masked]>
Date: Mon, 28 Aug 2017 03:00:00 +0000 (UTC)

@kazuho, you don't want to count retransmissions, because then you have different numbers on each side.  So I assume that you mean total bytes originally sent, which is basically what it is right now.

We discussed removing the limitation entirely and have any used up flow control on a stream credited back when you reset it.  The problem with that is that I can send you a very large stream over time, but if it is reset, that gives a huge and immediate increase to the connection flow control window.  I think that this design is fine.

-- 
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/749#issuecomment-325249002