Subject: [quicwg/base-drafts] Rework the ACK frame (#644)

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Jun 2017 15:35:47 -0700

There are MANY open issues on this.  Maybe we need to take a hollistic take on this.

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

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 20 Jun 2017 18:25:44 -0700

Possibly included: #423 #230 #506 #507 #563 #601 #613 

-- 
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/644#issuecomment-309936200

---

From: MikkelFJ <[email-masked]>
Date: Thu, 22 Jun 2017 07:46:36 -0700

#221 references 0RTT ACKs in TLS.
For other cleartext ACKs the text is a bit vague :

>An endpoint SHOULD use data from unprotected or 0-RTT-protected "ACK"
   frames only during the initial handshake and while they have
   insufficient information from 1-RTT-protected "ACK" frames.  Once
   sufficient information has been obtained from protected messages,
   information obtained from less reliable sources can be discarded.

Ignoring 0-RTT:
Does this mean cleartext ACK can remain valid after handshake? Considering constraints on cleartext content (stream 0 + ACK only), I don't think it is relevant anymore, but if it is relevant, would that not follow automatically: if a packet is not acknowledged and not retransmitted, that ack is relevant, otherwise it is not - same as any ACK?

If the text means remains relevant until handshake or sufficient information obtained - that would not be possible before handshake anyway?

-- 
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/644#issuecomment-310402443