Comments (12)
Tracking acks of acks is how STOP_WAITING dies.
from base-drafts.
ACKs are cumulative, therefore you would never retransmit them. This is similar to TCP.
Or possibly you're asking a different question?
from base-drafts.
This seems bound to the possible removal of STOP_WAITING (#66). STOP_WAITING effectively ACKs the ACK, informing the receiver that the sender has all the loss/arrival information needed about those packets. Hypothetically, you could infer something equivalent with ACKs of packets containing ACKs.
from base-drafts.
sack blocks aren't really cumulative under some interpretations; hence my confusion. For instance I might ack packet 1 and SACK 3,4,5. Do I continue to send this information in subsequent ACK frames, leading to potentially very long ones? Or do I just send it once and leave it out of ACK frames that report, say SACK 7,8,9?
If I leave them out, then by extension I should keep track of what acks/sacks went out in each packet, so that if the packet containing the ack is itself acknowledged I never have to report them again.
I am unclear as to how the logic of a protocol without STOP_WAITING would work, so it's clear that either I missed something in the draft or it's just not written.
from base-drafts.
The guideline is to continue to ack packets until a stop waiting frame says to not ack them anymore. However, a receiver can also stop acking packets due to memory constraints, running out of ranges, or potentially other reasons. Section 6.2 of the transport doc does go into this, but it could be a bit clearer, and a clarifying example may be helpful.
https://tools.ietf.org/html/draft-ietf-quic-transport-00#section-6.2
In terms of how the logic would work without STOP_WAITING, it's completely non-obvious in the current specs, which is why I need to write it up.
from base-drafts.
Ah. OK. My first hack at implementing this did what you describe, then I realized that the alternate approach would save lot of bytes, though with more bookkeeping. I see now that the words are there in Section 6.2 but it would be nice to have a more explicit requirement, e.g. "A receiver SHOULD repeat SACK blocks until those packets are covered by a STOP_WAITING".
To be honest, I think tracking which of my acks have been acked would reduce the control overhead of the protocol without requiring any wire format changes. But this might all be moot if STOP_WAITING dies.
from base-drafts.
I always thought the main purpose of STOP_WAITING was to stop acking lost packet numbers, which of course will never be retransmitted. Will the receiver somehow infer this instead?
from base-drafts.
And it is -- but the reason you can stop ACKing them is that the original sender has enough information to know they're lost. They can tell you this explicitly (STOP_WAITING), or you can infer it by knowing which of your ACKs made it through.
from base-drafts.
OK, so because we know the loss detection algorithm we can infer what the sender has given up on. That sounds like it might be problematic when the loss detection is timer-based. Moreover, it turns loss detection into something that must be carefully negotiated between endpoints, rather than simply innovating on one end.
Perhaps I should give you a chance to write it up before trying to poke holes in it. :-)
from base-drafts.
See #66 for what @ianswett will do
from base-drafts.
@janaiyengar I think that we can close this. There were lots of improvements to this text and I think that we captured the spirit of this well enough.
from base-drafts.
OK, so I am going ahead and closing this anyway. I probably missed this in the change log, but that's not a big deal.
from base-drafts.
Related Issues (20)
- Auth48: Combined internal references HOT 3
- Solidarity bot: Invalid HOT 4
- auth48 http/3: cite http2bis HOT 1
- Auth48: Keywords HOT 1
- Is "to the encoder" intended? (comment 2) HOT 4
- Auth48: Artwork types HOT 2
- Auth48: Difficult to parse sentence / duplicated words HOT 2
- Auth48: Huffman-coded versus Huffman encoded HOT 1
- To avoid awkward hyphenation, may we rephrase this text? Original (comment 6) HOT 2
- Should the following text be formatted using <aside>? (comment 7) HOT 2
- RFC Editor comment 8 HOT 1
- Auth48: SETTING_ => SETTINGS_ HOT 1
- Auth48: Capitalization and terminology consistency HOT 5
- Auth48: Servers and non-0-RTT clients HOT 1
- Stale contact information for Buck HOT 1
- STOP_SENDING to QPACK streams HOT 7
- CONTRIBUTING.md has out-of-date URLs HOT 1
- Marking packets as lost on PTO
- Add text on flow control deadlocks HOT 3
- Wiki: Implementations overview "destroyed" HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from base-drafts.