Subject: Re: [quicwg/base-drafts] ECN verification text (#2752)

From: mirjak <[email-masked]>
Date: Fri, 02 Aug 2019 02:35:45 -0700

mirjak commented on this pull request.

>  If verification fails, then the endpoint ceases setting ECT codepoints in
 subsequent IP packets with the expectation that either the network path or the
 peer does not support ECN.
 
-If an endpoint sets ECT codepoints on outgoing IP packets and encounters a
-retransmission timeout due to the absence of acknowledgments from the peer (see
-{{QUIC-RECOVERY}}), or if an endpoint has reason to believe that an element on
-the network path might be corrupting ECN codepoints, the endpoint MAY cease
-setting ECT codepoints in subsequent packets.  Doing so allows the connection to
-be resilient to network elements that corrupt ECN codepoints in the IP header or
-drop packets with ECT or CE codepoints in the IP header.
+If an ECT codepoint set is not dropped or corrupted by a network device, then a
+received packet contains either the codepoint sent by the peer or the Congestion
+Experienced (CE) codepoint set by a network device that is experiencing
+congestion.
+
+Upon successful verification, an endpoint continues to set ECT codepoints in
+subsequent packets with the expectation that the path is ECN-capable.

Under the assumption that ECN-based black holing basically doesn't exists anymore or at at least was not measurable anymore, I would like to propose to enable ECN-marking from the beginning and simply disable ECN on time-out or if acks without ECN feedback are received. Of course ECN could be enabled anytime again if you want to try again, however, no matter if in "testing" or not if you don't receive ECN feedback (anymore) for whatever reason, you should stop using ECN no matter what.

-- 
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/2752#discussion_r310056524

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 05 Aug 2019 18:30:28 -0700

@janaiyengar pushed 250 commits.

a5dd08a22bd8d74970e06b86ce1d0d83962175e3  fixed jana's formatting issues
a16744366973b7e50b9f531f6e919fa39d142358  Merge pull request #2747 from quicwg/one-per-level
7fdaf76f37d45ae278cc2042bb92218106bea1a3  Update draft-ietf-quic-transport.md
4c95c0ccef9a2b3c5147483374ed967ca63147a5  Merge pull request #2691 from quicwg/close2689
3a2ff52410f7335b0ac53f5cb3d456cb1f4f201f  Merge pull request #2733 from quicwg/srt-same
0fd9989e4ef297e48c917497a7c15980bb0dd822  Merge pull request #2680 from quicwg/ianswett-varint-error-codes
7bb735acdb237f47c2617e69a18e749e402e8a8d  Merge pull request #2637 from erickinnear/validation_source_address
bceffd54d8180854dce143971cf9ee0112b62e6b  Merge pull request #2574 from quicwg/sr-2119
08692908e709617d9be705cfe25d12316621cf53  Merge pull request #2461 from quicwg/0rtt-cant-respond-to-1rtt
cf17a89edd1b238a5fd7df4e400b180cb675765a  Retire Prior To
bac1c92fb8087129ad49546a6ee6eae21577385d  Fix typo: s/overiew/overview/
f1ab5070f1ce6019b9f08d0bdb78a774b42153e5  fix typo
a1d35eb487b5a2447d0a20f0bfeb6f280da7fe61  Merge pull request #2750 from quicwg/tweak-ecn-ignore
5f5a4194151098de76aa038d22ba85d68cea5c90  Allow not creating QPACK codec streams (#2529)
e892d9604bb99d33658b7779f525ed943c74802c  Drop maximum value restrictions on QPACK settings
b977de2816f64b0f11fda8e08d15744cc0934eff  Merge pull request #2751 from quicwg/spin-flow
e52cf67f31259dc6a62d9da1c663663a1e5ccee7  Merge pull request #2673 from DavidSchinazi/design_team_discard_keys
7a18778a489a8fe2b4442580b42635db79ef98b7  Merge pull request #2758 from reschke/patch-23
3a11ef01f6736ca7e3a4ec58c2a43614c5444e08  Merge pull request #12 from quicwg/master
7312d63a4ee85cd125b97d3868a9572f129e0120  Merge pull request #13 from huitema/master
23bacec76b1a30d8cb2119f7cb8c085c02524973  Reference "handshake confrmed" for connection migration.
4079e66c3b6663c49ea6ba0d78ca6a184724eb2a  Update draft-ietf-quic-transport.md
9dfb614cec93c5b860ccd06fd7e6a3d3fdcd53ed  Update draft-ietf-quic-transport.md
4029df2796f2426543d7becb051809a6ef94c262  Update draft-ietf-quic-transport.md
68d1c8b3b1dd3b657de8a7b4580f7a8da0db509b  Update draft-ietf-quic-transport.md
b669d0f7c51fa100e2c7c76fe6ddffa1e2c495d9  Update draft-ietf-quic-transport.md
ce74eecbbc1228dc48a69b249126410eb597e0fa  Update draft-ietf-quic-transport.md
13f452a1556564d5ceffd9424525ed2d430b6de4  clearer text. 2119 language. retire prior to less than seq number
091b4f5f81ae8dfb10155853ae48c1fad098ab57  Missed a type change
f80ffce179dabc3c0f72ef6ea8d0c199f0eb91e0  Change restriction from >= to >
75ed143f62141b429057c54827fefb660ced7367  Mention initial and preferred_address CIDs
db6980c75761ff46772d685a60d2a97e29baff0f  Yet another < vs <= fix
2db529c95f40f1118cd04e371325764aca1bec78  Added a 'than'
d60188e312f34326720c5453f0f156ab2efaa291  Fixed nits from David, Ian, MT
05e9d183140a3b9474eae24a9c013a9b9aa9773e  Fix changelog
b21444e25156141077fe8ad246841ca64bb2202e  Update draft-ietf-quic-transport.md
f68dd2cc60c4a06f65019ae51ed91fcce2b504cc  Fix typo: s/steam/stream/
ca74837d27795daaa195e7d48a24f5bcf4bc55bc  Fixed formatting error
490e99eef3fbd01d6f4418bbc0e3edc2d3929d59  Remove British spelling
4696d46774b50379d3d1823470d195ff975abcbc  Make it a requirement; SHOULD do immediately
ff007e11812de4775eaf91de75b33aa6dd789164  Clean up the other text too
053044d622bc6854474ee88d018a2ec88f7480dd  Orphan Placeholder (#2690)
87b268bcd6c8c11c443a92c99486dfe9239e9603  Don't Close; Just Remove after 3 PTO
6e2b7e10de29ec7b931c7afa40015d2d0b4db4ce  s/to 0// as redundant
0cefaa1ddf7680bc5d04133fd93e8216c57ceae7  Whitespace edits
50597d66aeb5653fdbd2ff1fbb41827454ed3dce  Consolidate two paragraphs from Bidirectional Streams and Frame Layout.
6a8d79bc7e743972250e4ed94008ed734935fb93  Mike's suggestion.
5035bae0fc51c06048ea68798e8565c33b230025  Mike's suggestion.
6cc8ad2c9406a26b5c222f529d43458e40491bd6  Mike's suggestion.
9302377793ff14019aa4cbffc2b79eb0341ab747  Specify HEADERS on control stream error.
86020b03d195b9268dd2daabd7af0d51771889b1  use upper-case RECOMMENDED, the text is from RFC 7540 that does not invoke 8174
8275d504bc118ac651b7d4071c73392179945853  Ian's suggestions
e3761e0c2ea0432f4ff1eff235dd46eeb7175a77  Fix number agreement: a peer *is* able
ac90f3261a364c3c3b800c86a74b9f380e8391b9  Fix typo: add missing "as" in "as soon as"
65e576d03e3c985d3fbed778bec0bf17702ff375  David's suggestions
269e67d456e2e4b8d4a75cbfd4622c114c54825f  Break up H2 considerations (#2698)
54c308a351d5293b66964a32e4bab00f23c35a27  More of David's suggestions
a923c343833c96deb2f42efd27ee8dcfcd83579c  Fix inconsistency. (#2784)
4a446a068f57b98e60a3ca0439e408fa0f093829  Ian's suggestion
04ff063f17a271bfb769bd1a269ffd7774b48c97  Rewrap
e8df2f6a6622d14d40810d0d93e4483ca412051a  Ian's suggestions
aa663e687b176d064dc6f5df61b3477ec23948fb  Jana's suggestions
b0b447899546791d9454eb6fd616695b307e0840  Merge pull request #2715 from quicwg/DaanDeMeyer-specify-data-before-headers-error
f6401e38e594c7104993343703592028bb3afacd  Mandate allowing peer to create enough unidirectional streams for HTTP and QPACK (#2762)
255e533fcd5ee63e736d536b8b03f278a5aafd5a  Import malformed message text (#2764)
3af8d911df004690345ffbe340bcdb17c9122c8c  Don't mandate zero server-initiated bidi streams (#2773)
933ac365d1d324e07bee34e69045ad674287b3fe  Eric's suggestions
a827f9ed9117adc7e7947416688dee6a1692e6c2  Explain initial settings a little more (#2776)
c72fdd96906c8acdc3201ba3bef925cca51021ed  Bring back the Exclusive Flag (#2781)
10d19646b5774de97b1e594bdf71b3aed139fe76  Update draft-ietf-quic-transport.md
c205b79ad75d9e67759dcb48994f3aef3b021715  Prohibit sending multiple PATH_RESPONSE
f00f3d111f9ca642081e9c9dd2ce7c117081055b  Only one path response should be sent in response to a packet containing any number of path challenge frames
950ab2255168c827670234a01f8211ea68090d35  Merge branch 'master' into dont_retransmit_path_response
bef17653caa29d28e96fa825ad34ef4ce8345d70  Remove requirement on responders to PATH_CHALLENGE
b71c1fffb6b4346942a721ead122c355868d1405  SHOULD NOT include platform delay in ack delay (#2786)
99ced9ef1199ad0efb5eb906171e994fda6826fd  Clarify ACK of ACKs and bundling a PING
8031f58dee2bd4aa29375d402bc64d9c6cb584ac  Update draft-ietf-quic-transport.md
f6ff3188febdb3f7db6b84d3d4a118ad20e4b2ee  Fix grammar
c9da070a4f4301456ad88d591dc3c9d5e7a2589d  Update draft-ietf-quic-transport.md
3c0d1f7297091d0e0cff31d7850fa1c557f2d130  Update with Jana's wording suggestion
52f5a62b5698201774dc98e5667072c2b9b52975  Remove extra space
386d61f5acc4dfbbce3c26307da905f997649364  Add missing comma
2d198dfffcca5ed6694f5109cb21f830bd316dda  Fix verb ownership: a packet does not process packets
e246745e8d3e4354a2b0cc6b3b3ee2bb489a85ff  Update draft-ietf-quic-transport.md
58e174a6c6afa7e8d24e615545b269faf0d50231  Update draft-ietf-quic-transport.md
33aa341ce7a3f2966bb22c08971d91ed55bf9da0  Update draft-ietf-quic-transport.md
aa377d4eb35e0e6908ed21b18dce6608df8aead3  Update draft-ietf-quic-transport.md
77b46c30d60fb46e971d302c9324d377de1bdb8e  Update draft-ietf-quic-transport.md
2b4486f2c49c84726bd0f8f082ff696d7b73ddbd  Update draft-ietf-quic-transport.md
8a4593370beb26f67b4fa687fb9fe7fe38b0e56a  Update draft-ietf-quic-transport.md
2c3addf78ae448fd6593c3b384aa83959871bab5  Update draft-ietf-quic-transport.md
b2248390b67338c081f41244a5c024e4fc97252d  Merge pull request #2796 from amirlivneh/patch-7
9fe134fb8eb371ab40710f82e4b7b48da70c6986  fix description which token to use for Initial packets
9f58ddf10bdc549c19a0045a8f613fb113bed614  remove outdated text about version negotiation
045f99415dfce3e2b1607d16193d9186f68abc5f  Update draft-ietf-quic-transport.md
f2b2ebb1f721907b233059b7caeca4ecae03f0a8  Update draft-ietf-quic-transport.md
bba4f7b2b423d2cf5b1d95c9d0240ca8055ab95c  Discuss max-header-list-size from the other side (#2774)
9618d5b884b4384e026c57c02aa0d72dc7fb9b60  Merge pull request #2746 from quicwg/same-ch-retry
f7334889aead71f724d11f887ff50d860676740a  Merge pull request #2803 from marten-seemann/remove-version-negotiation
6f5a6430607d4e6d6bbdce4b2d314409ef6e9a3a  Move Retry and Version Negotiation (#2804)
a981f677829327c37fb5fb68f95428932b5dca1b  Merge pull request #2688 from quicwg/ianswett-close-initial-handshake
0994d20047076fbfa01e1fd02f252b2d8168459d  Merge pull request #2727 from erickinnear/should_replace_cids
5eaf4d9582c65c7d618e7b90cfce51243effaf02  Update draft-ietf-quic-transport.md
bf9e38c8feb47740f2615c32e8000b81cafa53fb  Update draft-ietf-quic-transport.md
111407d94ec4cadafa75ebffd1a3a9f3b94b82d0  Update draft-ietf-quic-transport.md
92716d077e40dd49870aa9c39bcaca9d80e5d7c8  Update draft-ietf-quic-transport.md
675a2ed31f8f3ef64f47f0aba973ce20c227e174  Update draft-ietf-quic-transport.md
7ed03b155612dbf05f75e415c8ac804887f5832a  Update draft-ietf-quic-transport.md
f9c685139e55d8d824747ee306c4d3f079be257e  Update draft-ietf-quic-transport.md
9e3b8003e45b881c63118427c8a64e37db2297fa  Update draft-ietf-quic-transport.md
483a757fccc57d323349b3821f23ad7fa561ddd3  Update draft-ietf-quic-transport.md
e87958746169b877b3060c1ce5aaf7b6a020d514  Update draft-ietf-quic-transport.md
f546d201e4fb7b11a11bcafcd0a203c8e7a9a8cb  Update draft-ietf-quic-transport.md
8e41bfb039fa466061ab426f6bd171643bbfcc79  Merge pull request #2800 from marten-seemann/fix-token-usage
416583a40e672626baedc746e5a5e6f94fd4979c  Update draft-ietf-quic-transport.md
c4fcf6e91f544e9f56f096806dd6f7eabf5feab5  Merge pull request #2799 from dtikhonov/201906171701-packets-dont-process-packets
62795f89f068f02159dca106ebd7a7fe94aae2f5  Remove paragraph; add period
8cbcebf6ccafee170693188161e402506f2d2ef7  Reword field desc
4c32ea380a03eedc43e7413418926bc520524724  Mike's comments
9a2e34d2d6be4d7e04bf1175e50791cda6c8a26e  Update draft-ietf-quic-transport.md
fc2f166590b73da2e81ddf5926138fdf9cd60d90  Update draft-ietf-quic-transport.md
fea52b2ff749fe073c46fb5d34656e365bec4210  Update draft-ietf-quic-transport.md
0cc930090e39796ac456591b786c0e2364503454  Make exceeding stream limits a connection error
f019459311444a7886721cb471f6c72eaf7c9506  Fix typos
615453788949232d984fd3ade7ebcfe99cba70f4  Fix title capitalization
a3f3471aa65ca6d9890c462625f843686d3a9d7c  clarify why the client MUST NOT reset the packet number after a Retry
8c0aa5131f6dec1eb4e6f59d44a0d36abac1a30b  remove misleading sentence about connection IDs after Retry
11eca04ecf0524b488bb3bdfc159ff268d60571a  remove conflicting paragraph
f8ff494ff544fb7ae4b6253d7bedd30496a883c4  fix typo
86a977d543e8571e55acafd7f02f9f0e8ce8d2cd  clarify why clients can't send Handshake packets from the beginning
ff1698fc81ef401fed5c24c60bb7a51d1a3f6363  Fix grammar in 3.2. Receiving Stream States
1a752ccc0099be5ca880848a59c9f18ea2b6203c  Fix grammar
98d4f38a6386773d3bfbae4cb72c3afcce1e8daf  Merge pull request #2835 from amirlivneh/grammar-2
4d38e6f55020714443ae5a7bddad662d1e3d7cc3  Merge pull request #2830 from monkey-mas/fix-grammar-in-3-2-ReceivingStreamStates
eb640ba08786f55498514abc5534532895a9dddc  recovery: fix dangling ref to tls
36a2d9476358acf4c8b38dd9529b0429084638c7  Add intro sentence about ACK only packets
4f2130e2c279efb01baa5789aca13ba364da00ee  Update draft-ietf-quic-transport.md
cf619677cbbedd4e18d8171c03dca222c40b350a  v1 CID limit of 20 Bytes + MT's nit
d8f77e8c64f79eb4f23beb95bd95bcc1f02e14a4  Update draft-ietf-quic-transport.md
233d0c522e16cedadfb4c89d7ccddcae576eda59  Update draft-ietf-quic-transport.md
217306941a341029879362e7496d9d27a759512a  Merge pull request #2836 from reschke/patch-24
58877cfbf582e03e78d1727f27c3c008b2633f30  Merge pull request #2827 from amirlivneh/typos
b18e0baf6b2fc1e532e956c1a81ea57edf5b4777  Merge pull request #2831 from marten-seemann/pn-after-retry
c1e6e1eaa4500944f778c4cd6683861d33505e8a  Merge pull request #2833 from marten-seemann/fix-packet-buffering
f65c731f24d43e23e416de87103871c1f13a4806  Merge branch 'master' into master
63aa20accef3f5be9da50f26aab444162bd27944  Merge pull request #2731 from quicwg/ianswett-transport
43ad86c009e578a857ec71d0563574282bc07625  Update draft-ietf-quic-transport.md
bbe2b80d490c39c1d5900a5f00b4bbe11a29c4df  Update draft-ietf-quic-transport.md
dd947bce51843c3ec294b13428b47c220e6a7f41  Merge pull request #2730 from quicwg/ianswett-streams-editorial
09ee3ebc938c58016d7c81eaec22dc2f1b8cb454  Update draft-ietf-quic-transport.md
0ba5ab23f95342b221cabac4fc96e635616be430  Merge pull request #2826 from quicwg/ianswett-exceed-stream-limits
dc9d7ebdb2f14409a4a547bd0605f2b56814f050  Remove stale text that forbids the use of TLS records carrying early data.  As
39eacb3d1b3fa7e06508cd3147faae50b7f77cc4  Merge pull request #2832 from marten-seemann/remove-misleading-retry-sentence
49065dba4cd6a61faceb53c913c86426cb07e6ef  Merge pull request #2828 from amirlivneh/capitalization
6ade931ef4ed274fb5608ab78b65279e39cabd2f  it doesn't matter what an Initial is coalesced with
429c21970577028a46aed47c41f57e6ba0c37260  Merge pull request #2845 from kazuho/kazuho/early-data-records-arnt-available
b536fb12752ec4302d7e805494a658ba9e8a27dd  Merge pull request #2846 from marten-seemann/coalesce-initial
41286c3d318a32922cb1da6bccf3135b7aee2e82  Wrap
da92b1e351dd4893bc5c702890258d24271a7b2c  Fix grammar
10f280e67cd0b564ed63dac5bb755e23347cff05  Merge pull request #2848 from amirlivneh/grammar-3
575fff7375c90039c38aed3d12c43dba8923d59d  Fix grammar
7757fa1f6f367b678118726b98f76d98f4d46657  Merge pull request #2849 from amirlivneh/grammar-4
00825b28527842415b2500bf9f8ea6cdb0c16cc7  [qpack] rewrite abstract
3db93931bff5b7873c227acc56270d022dc02591  [qpack] Minor editorial pass
204691ddd4bae68984fa44d24624024714d18612  [qpack] Prefer header blocks to H3 frame types
f31269bbaa13738634adfb1eeb1329e1195ebeeb  [qpack] Reorder sections
d24dc65ec79519ba647fce623a7190827498513d  [qpack] Editorial Clarifications
c81c290d169e2106d5b28978cd24ee233015649b  [qpack] Move some decoder text to the decoder section
e251b7dfceccb027fe462b3c5f980c29a657a314  [qpack] Move some explanatory text from Wire Format to Decoder section
71af1873f346495148acfd7ddf840237a6068f24  [qpack] Make the instruction text more consistent
971f7454bd414bca6f47a77fb0b0283bb385c5f1  [qpack] Remove redundant stream text, update TOC
33795a5fb45d8625a452703cf8df5e8d0180ab6c  [qpack] Header blocks carry representations
06d63073ae61ee043691e31c7eb53f5fb4b61b54  Review feedback from everyone
6b6fd584a5cb5ca9843e656a9531dc4c88b62af8  More feedback
805380e7d7bb9b5303461a07448e17265da1b362  Merge pull request #2847 from quicwg/tp_mandatory
01ca26ffe1e6aea3c762705af4eef7f990e257ef  transport: fix dangling reference to -tls
0d82dc3bc2d50a1094a65c00e71d735078010758  Merge pull request #2854 from reschke/patch-26
d6d6d0f81b781697d6fb55caee804abee43ce8e1  Compare H2 PROTOCOL_ERROR with HTTP_GENERAL_PROTOCOL_ERROR (#2808)
6678903c9d52ae99ec64b44e34f17d6620185ea8  Remove HTTP_PUSH_ALREADY_IN_CACHE error (#2813)
9a358f2e4801f008e6723c514a1ec0e5f4989fd2  Rationalize HTTP_WRONG_SETTING_DIRECTION (#2814)
4d2900cb696a4777090b5f6d244833a20f96a9b0  Refactor Push ID related errors (#2820)
07395caae43e954270f8321523ba9aa0809e88f3  Rationalize HTTP/3 stream creation errors (#2822)
63b17279fc110da181efa5f6724c0025547851cc  Delayed packets can't create state
4121da9cf6a5fa043c0aa2dcf0948fbf6aec5fcc  Fix grammar
3535bef971d4989dcbc728b2803ec5598734c1dd  remove incorrect statement about empty STREAM frames
fe45b191e06fedbcbe24d7dbacc122aadfc1a8a7  Merge pull request #2862 from marten-seemann/empty-stream-frames-are-allowed
fa033e09d26c70fcfafd5d7f06a7fd4ea8d193c2  Merge pull request #2860 from amirlivneh/patch-17
63321d1cef419b086cb79cfdafee16563624d981  Merge pull request #2859 from quicwg/transport/late-packets
81bef6ee83ba699dee2d4cbc036023f31b469054  More suggestions
81a9886a84216209e2f3a8b4db475a5428b0e58e  Update draft-ietf-quic-transport.md
b4f756770b96c402a2b90123c2d3a9378806ed9a  Update draft-ietf-quic-transport.md
5d90a56f7104a2377ea015a718752ef8700dce4a  Update draft-ietf-quic-transport.md
9f9ad4757f0d5247aa40b2250dfaa9e29c7d94b1  Update draft-ietf-quic-transport.md
e9c0357b7416ad5d14684731b05a3a02fc42e539  Update draft-ietf-quic-transport.md
d6b8f0f1b276e409186910c9ca6c0a1f7c490af3  Update draft-ietf-quic-transport.md
e02a4e8f026b786d1a6b900787a8ea2a4d5cd4ec  Update draft-ietf-quic-transport.md
3525929ad18f4b68aa23a8d89b0dc00dc945ea91  Update draft-ietf-quic-transport.md
e4296ef4b5dbe54de69fdbd477f9ccb7a01ff818  Update draft-ietf-quic-transport.md
ec6a311f399ea4a1868d03066cf432872ff7e666  Update draft-ietf-quic-transport.md
e32333c304c4333bf3c986ae619e08532652a7d4  Update draft-ietf-quic-transport.md
42540ef2946775787f457841486975bf5d4d8445  Update draft-ietf-quic-transport.md
200841fa1a5175571e6a7c6c6ee01c8726bbb866  Update draft-ietf-quic-transport.md
6c786bdf032d81c8bf8169d77e4c647b1c595b76  Update draft-ietf-quic-transport.md
5e43503dd4265966177e7f20e54cd576f845f33d  Update draft-ietf-quic-transport.md
458232de8e964beb957288593b74ebcbb0a1ffa9  move definition of active_connection_id_limit to where it belongs
5dd2c59cb76179b64d7725d248c7f1d4cfeaf442  Merge pull request #2872 from marten-seemann/move-active-conn-id-limit-def
6a71414dbad7b8ed4d0745a2606aab70e1e37910  Merge pull request #2769 from nibanks/pr/replace-cid
b7c58fd9f4eebc161964f87aff2a33471395f874  Merge pull request #2729 from erickinnear/dont_retransmit_path_response
3685b650c27fe0c83892079014f53bee7e3dff61  Merge pull request #2794 from quicwg/ianswett-ack-ack
84eee53493ff81dbec79e13a70196c4fb8ea3c58  Merge pull request #2370 from huitema/stronger-migration-handshake
d7ed46a84cd78a601e1fa1581d59b3c21cec3947  Change log for -21
2ffc0b72a3449819b8a28bc0abc3ecc8de65a329  Ian's tweaks to text
a0e7d777e1a3220cd4a17c5e4ccac506bd4b1a29  Reflow
abd26dee7c4360e673314fa59465e0191d96c417  Merge pull request #2875 from quicwg/changelog-21
bfbe8237bab2752ef1de1c17db67f8561f1ee2a9  Fix recovery references
eba9381771002ac6145fd3e815fee7f97e3b30dc  Grammatical error
67fede17d34ba2fadb124ca6cf19156a2bbc2174  Merge branch 'master' into master
b25e6b7b3e5fea9ce21ce9b6bf3f5955e196caab  Merge pull request #2749 from martinduke/master
c3eef712c72ebb5a11a7d2432bb46365bef9f502  Fix changelogs for -22
913370291aa863a847126f7df9f9ab3df7024196  Editorial fix for #2479
b9f6425786a4a347ec926bac02c4b1631e15cdb9  Update draft-ietf-quic-invariants.md
5601eb00ee1d8b88d10e1a5e9f75c9899d602abf  Update draft-ietf-quic-invariants.md
a8a705e0da6e8009c4b9a902ad0228b0f7b3c181  Update draft-ietf-quic-invariants.md
49e721ae5aa2b3d5c1474cfc8c771721ed12b5fd  Update draft-ietf-quic-invariants.md
553106c6343f699ea9dabe23df5e1cb06b6795a8  Update draft-ietf-quic-transport.md
4f3e69d0f1a126e7c420a1d5d01efca60f498276  Update draft-ietf-quic-invariants.md
b205028bd6b3ee9419725022c96d8a6f72bd5d91  fixed typo
4926cf4edf332380b83e48b1a7ee717dfe891f5f  Byte lengths are next
1b61c54b8a4677890dde6108714d49674b0155d0  Merge pull request #2877 from quicwg/ianswett-2479
8791dd420b0afb6a6395025d33c339747b448e3b  Merge pull request #2883 from martinduke/patch-1
212169ad443ebd496c4b0452fefd1223d5c9c13d  qpack: fix reference to blocked-streams section
cb6828672ebbb3288be99155ae151ed243723421  Merge Crypto timeout and PTO (#2806)
8006456f147c1ea32e80cc65fb33b04bf955ec00  Fix typo
d090d4d796abf702f7246c06cbae1011342c360f  Don't state QUIC error codes.
d432cd6f844cabbce899e21ed2e177dc0815bba0  Fix lack of exponential backoff in pseudocode (#2902)
c56d843044ed537a53487411438e2638bec1a46a  Fix HPACK xref
bf59b827aeab949b66e62173dd6ec0f3c7d3d068  Add one to sample offset for header protection
17d82ab10046ca8eba79d8db0c8b8273c77e20d5  Merge pull request #2904 from quicwg/sample-offset
251b42e00d2973ae2dcbbe09d6c193932bb7c72c  Merge pull request #2901 from tandf/patch-1
94e02c1f34af486b0ef3cce6530ee1609da754b5  Typo in change log
407928b26fd9e4fcb2efbef4f70a39eb8a466cd6  PTO should always send an ack-eliciting packet
e0c0ed2898f55e5dc4feac38520bcb272c6276f2  Clarify resetting congestion control
02c8c88c142ca4ac8a1b08c1c16b333cbf1a38f8  Merge pull request #2917 from quicwg/close2685
d3c66d26508da8ad76829342bd75c7e844cf02ca  Up to two full-sized datagrams, not packets (#2915)
114b20f4b2accf4f76a242a34d5f620cd48f4e3d  Add rationale for why ack-eliciting
0d684171abcf439c7fc5fa6ff95433826682a108  Merge pull request #2912 from quicwg/ianswett-pto-ack-eliciting
6bb23b3fa6ea8c07c88760b7167346c18d5ec196  ECN verification text
a0c327a188415dbc5860a8907b60c5e382acdd58  faulty, not all
83cc335c78b4782c4cff9d5e5a6854bfaa40824c  ... and I thought this was going to be easy
c0db7a13f295d2dee1769fe7116b80b2053f4cdc  rebase

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2752/files/e3532e24d63657cd6ad8f898916a3452f480e023..c0db7a13f295d2dee1769fe7116b80b2053f4cdc

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 05 Aug 2019 18:46:10 -0700

I've taken in all feedback and reworked this section a fair bit. It's structured differently now, PTAL.

-- 
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/2752#issuecomment-518463066

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 05 Aug 2019 18:47:46 -0700

@janaiyengar pushed 1 commit.

99c3d3f27f0f21ccdec9e298afbb80308c398ea2  fix ref

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2752/files/9f88dc3d29f074e5a9fab10595292f3783ce80fc..99c3d3f27f0f21ccdec9e298afbb80308c398ea2

---

From: Martin Thomson <[email-masked]>
Date: Tue, 06 Aug 2019 00:52:55 -0700

The wall of commits is a little disconcerting there.

-- 
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/2752#issuecomment-518553300

---

From: Martin Thomson <[email-masked]>
Date: Tue, 06 Aug 2019 01:16:46 -0700

martinthomson requested changes on this pull request.

One big problem, the rest looks like a solid improvement.

-Each endpoint independently verifies and enables use of ECN by setting the IP
-header ECN codepoint to ECN Capable Transport (ECT) for the path from it to the
-other peer. Even if not setting ECN codepoints on packets it transmits, the
-endpoint SHOULD provide feedback about ECN markings received (if accessible).
+It is possible for faulty network devices to corrupt or erroneously drop packets
+which have ECN markings.  To provide robust connectivity in the presence of such

```suggestion
with ECN markings.  To provide robust connectivity in the presence of such
```
CMOS nit

-Each endpoint independently verifies and enables use of ECN by setting the IP
-header ECN codepoint to ECN Capable Transport (ECT) for the path from it to the
-other peer. Even if not setting ECN codepoints on packets it transmits, the
-endpoint SHOULD provide feedback about ECN markings received (if accessible).
+It is possible for faulty network devices to corrupt or erroneously drop packets
+which have ECN markings.  To provide robust connectivity in the presence of such
+devices, each endpoint independently validates, and enables or disables ECN

```suggestion
devices, each endpoint independently validates ECN counts and disables ECN
if errors are detected.
```

-To verify both that a path supports ECN and the peer can provide ECN feedback,
-an endpoint sets the ECT(0) codepoint in the IP header of all outgoing
-packets {{!RFC8311}}.
+ECN validation is local to a path, and MUST be independently performed for each

```suggestion
Endpoints validate ECN for packets sent on each network path independently.
```

-To verify both that a path supports ECN and the peer can provide ECN feedback,
-an endpoint sets the ECT(0) codepoint in the IP header of all outgoing
-packets {{!RFC8311}}.
+ECN validation is local to a path, and MUST be independently performed for each
+path from an endpoint to its peer.  An endpoint thus independently validates ECN

```suggestion
An endpoint thus validates ECN
```

-If an ECT codepoint set in the IP header is not corrupted by a network device,
-then a received packet contains either the codepoint sent by the peer or the
-Congestion Experienced (CE) codepoint set by a network device that is
-experiencing congestion.
+Even if an endpoint does not use ECN markings on packets it transmits, the
+endpoint SHOULD provide feedback about ECN markings received from the peer if

No need to SHOULD here.

```suggestion
endpoint MUST provide feedback about ECN markings received from the peer if
```

-If an ECT codepoint set in the IP header is not corrupted by a network device,
-then a received packet contains either the codepoint sent by the peer or the
-Congestion Experienced (CE) codepoint set by a network device that is
-experiencing congestion.
+Even if an endpoint does not use ECN markings on packets it transmits, the
+endpoint SHOULD provide feedback about ECN markings received from the peer if
+they are accessible. Not doing so will cause the peer to disable ECN marking.

```suggestion
they are accessible. Failing to report ECN counts will cause the peer to disable ECN marking.
```

> +To start ECN validation, an endpoint SHOULD do the following when sending
+packets on a new path to a peer:
+
+* Set the ECT(0) codepoint in the IP header of early outgoing packets sent on a
+  new path to the peer {{!RFC8311}}.
+
+* If all packets that were sent with the ECT(0) codepoint are eventually deemed
+  lost {{QUIC-RECOVERY}}, validation is deemed to have failed.
+
+To reduce the chances of misinterpreting congestive loss as packets dropped by a
+faulty network element, an endpoint could set the ECT(0) codepoint in the first
+ten outgoing packets on a path, or for a period of three RTTs, whichever occurs
+first.  Alternate strategies are possible.  For example, an endpoint could send
+the first ten packets interleaved: five ECT(0)-marked packets interleaved with
+five unmarked packets.  This allows the endpoint to more clearly identify
+congestive loss as such.  Implementations MAY experiment with and use other

I'd drop the "For example" and "This allows the endpoint to more clearly identity" sentences.  Also the "Alternate strategies" as well.

+* If all packets that were sent with the ECT(0) codepoint are eventually deemed
+  lost {{QUIC-RECOVERY}}, validation is deemed to have failed.
+
+To reduce the chances of misinterpreting congestive loss as packets dropped by a
+faulty network element, an endpoint could set the ECT(0) codepoint in the first
+ten outgoing packets on a path, or for a period of three RTTs, whichever occurs
+first.  Alternate strategies are possible.  For example, an endpoint could send
+the first ten packets interleaved: five ECT(0)-marked packets interleaved with
+five unmarked packets.  This allows the endpoint to more clearly identify
+congestive loss as such.  Implementations MAY experiment with and use other
+strategies.
+
+#### Receiving ACK Frames
+
+An endpoint that sets ECT(0) or ECT(1) codepoints on packets it transmits MUST

We only mention ECT(0) up to here.  I think that we want to either mention ECT(1) in the previous section (under experimentation) or warm up to it somehow.

 * Any increase in either ECT(0) or ECT(1) counts, plus any increase in the CE
   count, MUST be no smaller than the number of packets sent with the
   corresponding ECT codepoint that are newly acknowledged in this ACK frame.
   This step detects any erroneous network remarking from ECT(0) to ECT(1) (or
   vice versa).
 
+Processing counts out of order can result in validation failure.  An endpoint

```suggestion
Processing ECN counts out of order can result in validation failure.  An endpoint
```

 * Any increase in either ECT(0) or ECT(1) counts, plus any increase in the CE
   count, MUST be no smaller than the number of packets sent with the
   corresponding ECT codepoint that are newly acknowledged in this ACK frame.
   This step detects any erroneous network remarking from ECT(0) to ECT(1) (or
   vice versa).
 
+Processing counts out of order can result in validation failure.  An endpoint
+SHOULD NOT perform this validation if the ACK frame is received in a packet with
+packet number lower than a previously received ACK frame.  Validating based on

You still have the packet number thing that we talked about removing in favour of increased largest acknowledged...

-- 
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/2752#pullrequestreview-271177366

---

From: mirjak <[email-masked]>
Date: Tue, 06 Aug 2019 02:03:52 -0700

-be resilient to network elements that corrupt ECN codepoints in the IP header or
-drop packets with ECT or CE codepoints in the IP header.
+#### Validation Outcomes
+
+If validation fails, then the endpoint stops sending ECN markings in subsequent
+IP packets with the expectation that either the network path or the peer does
+not support ECN.
+
+Upon successful validation, an endpoint can continue to set ECT codepoints in
+subsequent packets with the expectation that the path is ECN-capable.  Network
+routing and path elements can change mid-connection however; an endpoint MUST
+disable ECN if validation fails at any point in the connection.
+
+Even if validation fails, an endpoint MAY re-validate ECN on the same path to
+the peer at any later time in the connection.

Maybe also add another sentence that it should revalidate on path change?

I would also like to see the easiest option spelled out: just enable ECN on all outgoing packet as dropping is rare and it can/will be disabled anytime when no ECN feedback is received. 

-- 
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/2752#pullrequestreview-271208071

---

From: Martin Thomson <[email-masked]>
Date: Tue, 06 Aug 2019 19:03:37 -0700

martinthomson commented on this pull request.

That would be confusing.  ECN validation is performed on a per-path basis.

-- 
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/2752#discussion_r311342565

---

From: mirjak <[email-masked]>
Date: Wed, 07 Aug 2019 00:57:54 -0700

Okay, then you should say revalidation but maybe remark actually exactly this, that validation is performed on a per-path basis and has do be performed when a path change is detected.

-- 
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/2752#discussion_r311415720

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 07 Aug 2019 18:20:22 -0700

9e1257ac44cdf76f4ca87bc7e3d5ee7daf1de961  Apply suggestions from code review

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2752/files/99c3d3f27f0f21ccdec9e298afbb80308c398ea2..9e1257ac44cdf76f4ca87bc7e3d5ee7daf1de961

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 07 Aug 2019 18:22:30 -0700

9d5d575289e3c8cdcadf38e3ec5bb3f53a42e651  reflow

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2752/files/9e1257ac44cdf76f4ca87bc7e3d5ee7daf1de961..9d5d575289e3c8cdcadf38e3ec5bb3f53a42e651

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 07 Aug 2019 18:36:08 -0700

d91799d50a76b2e9bcc00e22deebc1c31fe30816  comments

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2752/files/9d5d575289e3c8cdcadf38e3ec5bb3f53a42e651..d91799d50a76b2e9bcc00e22deebc1c31fe30816

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 07 Aug 2019 18:46:11 -0700

@janaiyengar pushed 2 commits.

86eaad8e15dc026bbe3d87c4fe3da3425b2a7a0b  use largest acked, not packet number
ee89e45f5c47a6c17c848e43f360b88baabb0d8c  the best words

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2752/files/d91799d50a76b2e9bcc00e22deebc1c31fe30816..ee89e45f5c47a6c17c848e43f360b88baabb0d8c

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 07 Aug 2019 18:48:18 -0700

janaiyengar commented on this pull request.

comments incorporated. @martinthomson: I've changed the reordering heuristic to be about largest acked as we've previously discussed, and I think I have it right. PTAL.

Added some mentions of it above

That's already said above in the 2nd para of the "ECN validation" section. The point of this sentence here is that validation failure does not mean an endpoint can't try again for this path.

done, done, and done.

I think I have it now, PTAL.

-- 
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/2752#pullrequestreview-272305004

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 07 Aug 2019 18:49:30 -0700

08ed6f08a0a67f38737fb1b95c6e923fc2dd5911  lint

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2752/files/ee89e45f5c47a6c17c848e43f360b88baabb0d8c..08ed6f08a0a67f38737fb1b95c6e923fc2dd5911

---

From: Martin Thomson <[email-masked]>
Date: Wed, 07 Aug 2019 18:55:35 -0700

martinthomson approved this pull request.

Minor nits only.  Thanks for getting the largest acknowledged thing.

> -reduced throughput or other undesirable side-effects.  To reduce this risk, an
-endpoint uses the following steps to verify the counts it receives in an ACK
-frame.
+first.  Implementations MAY experiment with and use other strategies.  An

I would make a new paragraph here that says this:

Implementations MAY experiment with and use other strategies for use of ECN.  Other methods of probing paths for ECN support are possible, as are different marking strategies, including those that use ECT(1).

+Processing ECN counts out of order can result in validation failure.  An
+endpoint SHOULD NOT perform this validation if this ACK frame does not advance
+the largest packet number acknowledged in this connection.

Your framing makes me ask a question: Is this test connection-scoped, or just path-scoped?  I think that either works about as well as any other, but the path-scoped one might be more correct.

But then path-scoped is probably tricky to implement.  So let's not worry about that.

Drop "to the peer".

I'm not happy about the hyphenated "re-validate", but I'm short on rephrasing suggestions, sorry.

-- 
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/2752#pullrequestreview-272308542

---

From: mirjak <[email-masked]>
Date: Thu, 08 Aug 2019 02:42:24 -0700

I don't think normative language is needed 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/2752#discussion_r311946123

---

From: mirjak <[email-masked]>
Date: Thu, 08 Aug 2019 02:56:30 -0700

+packets on a new path to a peer:
+
+* Set the ECT(0) codepoint in the IP header of early outgoing packets sent on a
+  new path to the peer {{!RFC8311}}.
+
+* If all packets that were sent with the ECT(0) codepoint are eventually deemed
+  lost {{QUIC-RECOVERY}}, validation is deemed to have failed.
+
+To reduce the chances of misinterpreting congestive loss as packets dropped by a
+faulty network element, an endpoint could set the ECT(0) codepoint in the first
+ten outgoing packets on a path, or for a period of three RTTs, whichever occurs
+first.  Implementations MAY experiment with and use other strategies.  An
+endpoint could send the first ten packets interleaved: five packets marked with
+ECT(0) or ECT(1) interleaved with five unmarked packets.  An endpoint could also
+simply send all packets marked with ECT(0) or ECT(1) until validation fails.

Maybe say: "When the expected risk of ECN-based blackholing is low, an endpoint can also
	simply send all packets marked with ECT(0) until validation fails."
I would also like to point people to some measurement data, e.g.: "Recent studies have detected potential ECN-related connectivity problems in less than 0.3% [ECNmeasure]"

[ECNmeasure] Brian Trammell, Mirja Kühlewind, Piet De Vaere, Iain R. Learmonth, and Gorry Fairhurst. 2017. Tracking transport-layer evolution with PATHspider. In Proceedings of the Applied Networking Research Workshop (ANRW '17). ACM, New York, NY, USA, 20-26. DOI: https://doi.org/10.1145/3106328.3106336

RFC8311 does not define use of ECT(1) as interchangeable with ECT(1) anymore and therefore advises endpoints to only use ETC(0) which classic ECN. I think it's right to only talk about ECT(0) here, or if you want to mention that ECT(1) should also use for experimentation with new ECN based signal approaches, you have to point to RFC8311.

-- 
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/2752#pullrequestreview-272462951

---

From: Martin Thomson <[email-masked]>
Date: Thu, 08 Aug 2019 07:03:53 -0700

A problem here is that the text mandates use of ECT(0), which might preclude use of something like L4S on a strict reading.  Also, we need a reason to mention ECT(1) later.

-- 
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/2752#discussion_r312053034

---

From: mirjak <[email-masked]>
Date: Thu, 08 Aug 2019 08:58:46 -0700

RFC8311 says: "Protocols and senders MUST NOT use the ECT(1)
      codepoint to indicate ECT unless otherwise specified by an
      Experimental RFC in the IETF document stream."
So I don't think we should talk about use of ECT(1) without a pointer to RFC8311.

However, for this sentence I still don't see why normative language is needed.

And If think if we want to say something about ECT(1) we should rather say something like: "ECT(1) is reserved for experiments by RFC8311. If such an experiment is implemented, the described validation methods might apply as well to ETC(1)." However, that actually doesn't say much...

-- 
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/2752#discussion_r312115463

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 08 Aug 2019 13:20:07 -0700

78a9f6dbb9fcfebdfdca7723526c5d9370429f92  more words

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2752/files/08ed6f08a0a67f38737fb1b95c6e923fc2dd5911..78a9f6dbb9fcfebdfdca7723526c5d9370429f92

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 08 Aug 2019 13:20:31 -0700

Thanks for the text, @martinthomson. I've tried to wrestle the text to resolve these concerns, take a look. @mirjak, the normative exists here because there's a SHOULD above on a specific sending pattern (see line 3133).

I'm not sure that we need to say anything here about the prevalence of ECN blackholing. No matter what the prevalence, this spec will have to specify methods that work when ECN blackholing is a problem. It seems to me that this text probably belongs in the applicability draft.

I think we only need to specify one method that can be used as a default, and suggest that implementations can use others too. I'm going with the suggestion of removing other methods entirely from this text because I don't think we need to discuss considerations of using other methods. If I'm in the minority, then I would suggest that we still keep it out of this PR, and add more methods in a separate PR.

I've cited 8311 for the text on sending ECT(1). This text is about what to do when receiving ECT(0) or ECT(1), and so I'm not citing 8311 here.

Unless you're suggesting that we scrub out all mentions of ECT(1) in the text here. I'm not sure that's necessary though, since the rules of validation do not change even when a future spec allows the use of ECT(1).

Good point. I tried to think of ways in which the path-level largest acked goes down while the connection-level largest acked goes up, but failed. I think connection-level might be a slightly stronger constraint than we want, but I _think_ it's actually correct. 

Turns out I don't need the hyphenation.

-- 
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/2752#discussion_r312216338

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 12 Aug 2019 14:37:26 -0700

I think this is ready. Unless someone disagrees, I'll mark the corresponding issue as proposal-ready tomorrow.

-- 
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/2752#issuecomment-520605235

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Aug 2019 17:40:07 -0700

I don't think that we'll find new objections.  I marked it myself.

-- 
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/2752#issuecomment-520645420

---

From: mirjak <[email-masked]>
Date: Tue, 13 Aug 2019 02:01:33 -0700

Thanks! That's fine now. Did just reply to Martin's mail. I agree that here it should mention both codepoints.

-- 
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/2752#discussion_r313288871

---

From: ianswett <[email-masked]>
Date: Wed, 14 Aug 2019 13:56:06 -0700

ianswett approved this pull request.

Connection scoped works for me, at least for now.  When we have a way to ACK packets on different paths at the same time, we can revisit this question.

-- 
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/2752#pullrequestreview-275144175

---

From: Martin Thomson <[email-masked]>
Date: Mon, 26 Aug 2019 00:20:45 -0700

Merged #2752 into master.

-- 
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/2752#event-2582747889