Octets that are sent twice #1353
Conversation
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.
martinthomson
added
editorial
draft-ietf-quic-transport.md
Outdated
| 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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
From the proposed change:
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. |
|
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. |
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 |
|
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. |
|
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. |
But don't imply an absolute requirement to do so. It seems like an opportune moment to point out that no provision is made for partial reliability either.
|
@ianswett, @janaiyengar, @mcmanus, can you check that I'm accurate in my updated statement here. I think that avoiding MUST is sensible here. |
|
@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. |
draft-ietf-quic-transport.md
Outdated
|
|
||
| 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 |
|
@MikeBishop, @martinthomson -- I am not advocating for this, just want to get to the rationale behind this requirement. |
|
It's been an unstated assumption. We're just documenting it, that's all. |
martinthomson
force-pushed
the
overlapping-data
branch
from
58f71fb
to
490c00a
Compare
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.