Subject: [quicwg/base-drafts] Octets that are sent twice (#1353)

From: Martin Thomson <[email-masked]>
Date: Sun, 13 May 2018 18:03:10 -0700

This is obvious, but never stated.  We discussed checking that they stay constant and agreed that requiring a check would be crazy.  However, we never wrote anything down.  I think that a MAY is fine.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/1353

-- Commit Summary --

  * Octets that are sent twice

-- File Changes --

    M draft-ietf-quic-transport.md (13)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1353.patch
https://github.com/quicwg/base-drafts/pull/1353.diff

-- 
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/pull/1353

---

From: ianswett <[email-masked]>
Date: Sun, 13 May 2018 18:27:18 -0700

ianswett commented on this pull request.

> @@ -3612,10 +3612,15 @@ When new data is to be sent on a stream, a sender MUST set the encapsulating
 STREAM frame's offset field to the stream offset of the first byte of this new
 data.  The first octet of data on a stream has an offset of 0.  An endpoint is
 expected to send every stream octet.  The largest offset delivered on a stream
-MUST be less than 2^62. A receiver MUST ensure that received stream data is
-delivered to the application as an ordered byte-stream.  Data received out of
-order MUST be buffered for later delivery, as long as it is not in violation of
-the receiver's flow control limits.
+MUST be less than 2^62.
+
+A receiver MUST ensure that received stream data is delivered to the application

I think Patrick wanted to allow out of order delivery, and I thought the agreement was along the lines of "A receiver MUST provide the received stream data to the application as an ordered byte-stream".  The text you wrote implies it's in-order is the only possible option.

-- 
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/pull/1353#pullrequestreview-119675688

---

From: Martin Thomson <[email-masked]>
Date: Sun, 13 May 2018 23:34:03 -0700

martinthomson commented on this pull request.

That text isn't changed.  It's what we litigated (at some length), but moved into a new paragraph, because the old one was getting unwieldy.

You are right, though.  It seems to imply that it has to deliver in order, when the intent was that it be capable of doing so.

-- 
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/pull/1353#discussion_r187846970

---

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 14 May 2018 05:55:09 -0700

>From the proposed change:
> The value for a given octet MUST NOT change if it is sent multiple times...

Why require that it not change?  While inappropriate for HQ, mutable content (perhaps combined with out-of-order delivery) may make for some interesting protocol options.

-- 
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/pull/1353#issuecomment-388806387

---

From: Mike Bishop <[email-masked]>
Date: Mon, 14 May 2018 09:30:59 -0700

Because it's then unpredictable what version (or combination of versions) will be received by the application.  We'd need more versioning mechanisms if we wanted to employ that properly.

While I agree that the text around ordering reads as stricter than the agreed-upon intent, it's not actually modified by this PR.  The change introduced by this PR is fine; I don't feel strongly about fixing the in-order text while we're here versus creating a separate PR.

-- 
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/pull/1353#issuecomment-388879919

---

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 14 May 2018 10:52:06 -0700

> Because it's then unpredictable what version (or combination of versions) will be received by the application. We'd need more versioning mechanisms if we wanted to employ that properly.

An application might be OK with it.  What if the content is versioned purely as a function of time?

How about this scenario in HQ: serving a static file.  An implementation may simply `read(2)` the file contents into STREAM frames as packets are sent out, including when lost frames are resent.  The requirement that octets not be modified forces either keeping unacknowledged STREAM frames in memory or locking the file somehow.

-- 
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/pull/1353#issuecomment-388905399

---

From: Mike Bishop <[email-masked]>
Date: Mon, 14 May 2018 13:04:32 -0700

In that scenario, consider that bytes 0-800 and 1000-1200 are delivered on the first try, then the file changes, and bytes 800-1000 need to be resent.  If the file has changed in the meantime and the server is just reading from disk, you get a window into the new file while still having the outer bytes taken from the old file.

And yes, to avoid that, the server needs to hold read access to the file until it's done reading for good, or retain the content that it transferred, or at the least listen for filesystem change notifications.

I can see value in a solution (probably at the application layer) to abort a response and indicate that the resource has changed.  But randomly intermixing content from the old and new versions without indication of which source it came from, which would be the output of the current structure, seems like an invitation to invalid state.

-- 
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/pull/1353#issuecomment-388944565

---

From: MikkelFJ <[email-masked]>
Date: Mon, 14 May 2018 13:53:40 -0700

The wonderful mmap api does not guarantee MAP_PRIVATE view remains private on Linux if someone else writes to the file.

I think the requirement of unchanged data is the only sane approach at protocol level, but it can be viewed as a system requirement not the sole responsibility of the QUIC engine because that could range from very expensive to near impossible. Hence, if some other process with adequate permissions overwrite a mmap'ed file being transmitted, that process just violated the QUIC spec.

-- 
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/pull/1353#issuecomment-388959214

---

From: Martin Thomson <[email-masked]>
Date: Mon, 14 May 2018 18:14:30 -0700

@martinthomson pushed 1 commit.

4cdf040  Insist on being able to deliver in order

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1353/files/85a8ab10770d71c33980638d43cf95715cae6788..4cdf0409109f81fad372ac43f4056f21905761e7

---

From: Martin Thomson <[email-masked]>
Date: Mon, 14 May 2018 18:15:09 -0700

@ianswett, @janaiyengar, @mcmanus, can you check  that I'm accurate in my updated statement here.  I think that avoiding MUST is sensible here.

-- 
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/pull/1353#issuecomment-389011189

---

From: Martin Thomson <[email-masked]>
Date: Mon, 14 May 2018 18:16:21 -0700

@dtikhonov, if you want to change the value of an octet, I think that requires some sort of negotiation.  In other words, that's a new 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/pull/1353#issuecomment-389011358

---

From: ianswett <[email-masked]>
Date: Mon, 14 May 2018 18:40:57 -0700

> @@ -3612,10 +3612,18 @@ When new data is to be sent on a stream, a sender MUST set the encapsulating
 STREAM frame's offset field to the stream offset of the first byte of this new
 data.  The first octet of data on a stream has an offset of 0.  An endpoint is
 expected to send every stream octet.  The largest offset delivered on a stream
-MUST be less than 2^62. A receiver MUST ensure that received stream data is
-delivered to the application as an ordered byte-stream.  Data received out of
-order MUST be buffered for later delivery, as long as it is not in violation of
-the receiver's flow control limits.
+MUST be less than 2^62.
+
+QUIC makes no specific allowances for partial reliability or delivery of stream
+data out of order.  Endpoints are expected to deliver stream data to an
+application as an ordered byte-stream.  Delivering an order byte-stream requires

in-order byte stream?

-- 
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/pull/1353#pullrequestreview-120063548

---

From: ianswett <[email-masked]>
Date: Mon, 14 May 2018 18:41:14 -0700

Or ordered?

-- 
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/pull/1353#discussion_r188144835

---

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 14 May 2018 18:55:27 -0700

@MikeBishop, @martinthomson -- I am not advocating for this, just want to get to the rationale behind this requirement.

-- 
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/pull/1353#issuecomment-389017758

---

From: Martin Thomson <[email-masked]>
Date: Mon, 14 May 2018 20:26:06 -0700

58f71fb  ordered stream

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1353/files/4cdf0409109f81fad372ac43f4056f21905761e7..58f71fba7f1ed3304a6e69eb63480d0776ee8df8

---

From: Martin Thomson <[email-masked]>
Date: Mon, 14 May 2018 20:26:21 -0700

It's been an unstated assumption.  We're just documenting it, that's all.

-- 
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/pull/1353#issuecomment-389031209

---

From: ianswett <[email-masked]>
Date: Tue, 15 May 2018 05:15:20 -0700

ianswett approved this pull request.

-- 
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/pull/1353#pullrequestreview-120203903

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 May 2018 15:45:50 -0700

7b4cbf1  Able to

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1353/files/490c00a857c6185e0aaf4739ecae00f41d7f030d..7b4cbf1646eb83d94da62332bf08e65b971adc94

---

From: janaiyengar <[email-masked]>
Date: Tue, 15 May 2018 15:47:21 -0700

janaiyengar approved this pull request.

-- 
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/pull/1353#pullrequestreview-120442087

---

From: janaiyengar <[email-masked]>
Date: Tue, 15 May 2018 15:48:26 -0700

Merged #1353.

-- 
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/pull/1353#event-1628373952