Subject: [QUIC] about draft-hamilton-quic-transport-protocol-00

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 6 Oct 2016 11:37:23 +0200

Hi,

Thanks for the document. I have been reading 
draft-hamilton-quic-transport-protocol-00 and I find it not easy to 
read, probably because it is an early version and mostly because of my 
own limitations.

I attach a few comments and questions regarding the draft. Hope you find 
them useful.

Section 3.5 on Stream and Connection Flow control.

Is the offset announced for the connection the sum of the offsets 
announced for each of the stream of that connection?

If so, it seems redundant to announce both of them, no?

If it is not, I am uncertain how this would work. If the connection one 
is larger than the sum of the streams one, I am not sure how can the 
sender use the remaining buffer, since it cannot allocate it any 
existing stream. Is this meant to the be used for new streams? If the 
sum of the streams one is higher than the connection buffer, then i 
guess the sender needs to to a double check, first for available rcv 
window in the stream and then available rcv window in the connection. 
Not sure what is the gain of having both. Maybe it is worthwhile making 
explicit in this section why this is useful?

Section 3.7 on Resilience to NAT Rebinding.

I assume that the same mechanisms that allow the connection to survive a 
nat rebinding would be also useful to support some simple forms of mobility?

I mean, probably these mechanisms are enough to support the client 
changing IP address (for instance when doing a handover from cellular to 
wifi)?

I guess they are not enough to support more complex mobility scenarios, 
such as simultaneous movement of both endpoints, but in any case, it may 
be worthwhile mentioning this mobility support in this section?

Section 4.1 on Version Negotiation

I understand that during version negotiation, the following information 
is exchanged: version, version flag, connection ID, and in some cases 
the server's supported versions. I understand that all this information 
is exchanged before the crypto handshake, so it is exchange in clear 
text and without authentication. Since in section 3.6 it is claimed that 
packets are always authenticated, I guess we have a (mild) contradiction 
here (i understand you verify this later on once the crypto has been 
exchanged). In any case, maybe it is worthwhile to explicitly state in 
this section that this information is exchanged in plain text and non 
authenticated. Also, the last paragraph of this section states that 
there are other transport parameters exchanged in the connection 
establishment. I assume that those are exchanged after the crypto, so 
they are encrypted and authenticated? Is there any other transport 
parameter exchanged in clear text? Probably it would be useful to make 
this explicit?

In section 4.2.1.2 on Required Transport Parameters.

One thing I am missing here (probably because suffering a TCP bias) is 
the initial packet sequence number to be used in the connection.

Do you always use 0 as initial PSN? If so, this is because you assume 
that the crypto mechanisms established during the crypto handshake will 
prevent packet form previous connections to re-emerge later on and be 
confused for packets in the new connection? If this is the case, maybe 
you should state it explicitly in section 4.2.3?

However, from reading section 4.2.2 it seems that multiple connections 
between two endpoints can reuse the same crypto material, is that the case?

In this case, does each connection uses 0 as initial PSN? How can you 
guarantee in this case that old packets with same PSN will no re surface 
and appear as packet of a new connection, since they can be using the 
same PSN?

Section 4.2.2 on Proof of Source Address Ownership.

I understand that the STK provides less protection than a reachability 
check at the beginning of each connection, correct?

I mean, the STK proves that the client was once in that location and it 
can later leave the location and because it still has the STK, it can, 
by spoofing the source address, pretend to still be there, since only 
the STK is enough to pass this test.

This means that for instance, an attacker can download a large file by 
simply sending paced ACKs to any location it once was (given that the 
PSN initial number is always 0, it doesnt even needs to guess the PSNs), 
correct?

Maybe this is acceptable, but maybe it is worthwhile stating it in the 
security considerations section?

Section 4.2.3 on Crypto Handshake Protocol features

In the bullet about Connection establishment in 0-RTT, it requires 0-RTT 
connection establishment for subsequent connections between the same two 
endpoints, in the subsequent connections, the client and server roles 
must be preserved or they can be changed?

I mean, suppose that host A initiates a quic connection to host b. Does 
this condition requires that a future connection (with the same ports) 
initiated from host b to host A should be established in 0-RTT?

I think this should be made explicitly because mixed with the STK, I 
believe it changes the threat model significantly.

Nit: the paragraph on the bullet on Server Config Update is truncated.

Section 5.1 on Life of a stream.

It states that quic accommodates the possibility of out-of-order 
delivery. Do you mean out of order delivery within the same stream or 
across streams? clarify?

I understand that the creation of a stream is very lightweight and a new 
stream is established by simply data with a new stream id, correct?

I also understand that the initial stream sequence number is always 0, 
correct? (I mean, the offset of the current data to the beginning of the 
streams is included, and the initial packet has offset 0).

So, similar to the question i posed about the initial PSN, how does quic 
prevent old packets to reappear and be confused as being part of the new 
stream while they were part of an older stream? It cannot be done using 
the offset, since for all connection it starts in 0. I guess it could be 
done using the PSN, but then the receiver needs to check that all PSN of 
packets for a new stream are higher than the PSN of the packet that 
terminated the older stream, is this the proposed approach?

Probably it is worthwhile clarifying what are the means that quic deals 
with old packets re emerging after the connection/stream has ended, 
given that it does not relies on the sequence number to do so, afaict.

In particular, in section 5.1.1 it states that a stream is open by 
sending or receiving a data packet with that particular stream ID. I 
assume that the data packet MUST contain a 0 offset to create the new 
stream? is this correct?

Section 5.2 on Stream Identifiers.

I guess you should reserve a range of identifiers for future use, in 
case other "special" streams are needed in the future?

Section 5.4 on Sending and Receiving data.

Is the initial offset for the data packet sent on a stream set to zero? 
If this is the case, would be good to state it.

Section 6. on Packetization and reliability. What is the initial PSN in 
a given connection? State it explicitly.

It is stated that a sender MAY wait for a short period of time to bundle 
multiple frames. I guess it would be useful to provide guidance on what 
you consider a short period of time. Is that 500ms as in the delayed 
acks or are you thinking much less?

Later on, it states that only ACK, STOP_WAITING and PADDING frames MUST 
not be retransmitted, but all other frames must be retransmitted. This 
implies than that WINDOW_UPDATE and BLOCKED frames must be 
retransmitted, but i am not sure if this makes sense. I mean, maybe 
there were other WINDOW_UPDATE frames than were sent after this one so 
retransmitting this one probably doesnt make sense, since the 
information it contains may be stalled, no?

I still dont understand why having both connection and stream flow 
control is useful. I would assume that only stream flow control would be 
useful. Or having one or the other in a given connection, but i fail to 
understand why is useful to have both of them simultaneously in the same 
connection.

Section 6 states

    Regular QUIC Packets are "containers" of frames; a packet is never
    retransmitted whole, but frames in a lost packet may be rebundled and
    transmitted in a subsequent packet as necessary.

So, let me see if i understand this.

This means that if the sender sends packet with PSN 5, and if the packet 
is lost (i.e. there is a timeout for that packet), the packet with PSN 5 
NOT retransmitted. the frames in the packet with PSN 5 are then 
retransmitted in other packets with other PSN (other than 5). If this 
correct?

This means that there will be holes in the sequence of packets received 
by the receiver i.e. any packet that get's lost, is simply lost and will 
never be received by the receiver. Am i understanding this correctly?

    A receiver acknowledges receipt of a received packet by sending one
    or more ACK frames containing the PSN of the received packet.  To
    avoid perpetual acking between endpoints, a receiver MUST NOT
    generate an ack in response to every packet containing only ACK
    frames.

Does this means that ACKs transmission is unreliable, correct?

Since packets are never retransmitted with the same PSN, this basically 
means that if an ACK is lost, then the sender gives up on this packet 
and eventually will retransmit the data in other packets with a 
different PSN, correct?

Section 7.1.1 on Mid-stream RST_STREAM

After a RST, when the stream identifier can be reused? probably some 
guidance about this would be useful.

Section 7.1.4.

Is the BLOCKED frame reliably transmitted? I assume it is, but, does it 
make sense?

I mean, if a sender sends a blocked frame and it get's lost, but after 
that the receiver open the window, then retransmitting the BLOCKED frame 
is not useful (doesnt harm neither i guess)

OTOH, what if the BLOCKED frame get's lost? Do we end up with the silly 
window syndrome?

I guess we could do what TCP does i.e. periodically transmit the BLOCKED 
msg when there is no window (which is different from reliably 
transmitting the BLOCKED message, since it is periodically sent only 
when the window is 0)

Section 8 on connection termination

After a connection close, does the same stream identifier can be reused 
for a new connection? shouldnt also be a hold time to avoid delayed 
packets of the old connection? How much time would be safe?

Section 10.4

I understand ACK frames are unreliably transmitted.

Also, I understand that packets are never retransmitted with the same 
PSN. So, if a packet is lost, there will be a hole in the receiver for 
that PSN and the data will be sent in other packets with othew PSN. 
Hence, you cannot have cummulative acks.

So, this means that it is possible for a packet to be received by the 
receiver but that all the ACKs for that packet to be lost on the way 
back and then the sender will timeout and retransmit, right? (I guess 
that is ok, since data will be retransmitted in other packets)

Let me verify that I understand when a stop waiting frames should be 
sent by the sender. I guess that a sender should send a given PSN X in a 
stop waiting frame if all the packet with PSN lower than X have been 
received or have timed out, correct?

Regards, marcelo

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 6 Oct 2016 12:41:59 -0700

Thanks much, Marcelo! There's definitely work to be done on the draft, so
comments are very appreciated!
I'll be revising the draft soon, so will respond to your detailed comments
soon.

On Thu, Oct 6, 2016 at 2:37 AM, marcelo bagnulo braun <[email-masked]>
wrote:

> Hi,
>
>
> Thanks for the document. I have been reading draft-hamilton-quic-transport-protocol-00
> and I find it not easy to read, probably because it is an early version and
> mostly because of my own limitations.
>
> If it is not, I am uncertain how this would work. If the connection one is
> larger than the sum of the streams one, I am not sure how can the sender
> use the remaining buffer, since it cannot allocate it any existing stream.
> Is this meant to the be used for new streams? If the sum of the streams one
> is higher than the connection buffer, then i guess the sender needs to to a
> double check, first for available rcv window in the stream and then
> available rcv window in the connection. Not sure what is the gain of having
> both. Maybe it is worthwhile making explicit in this section why this is
> useful?
>
>
> such as simultaneous movement of both endpoints, but in any case, it may be
> worthwhile mentioning this mobility support in this section?
>
>
> I understand that during version negotiation, the following information is
> exchanged: version, version flag, connection ID, and in some cases the
> server's supported versions. I understand that all this information is
> exchanged before the crypto handshake, so it is exchange in clear text and
> without authentication. Since in section 3.6 it is claimed that packets are
> always authenticated, I guess we have a (mild) contradiction here (i
> understand you verify this later on once the crypto has been exchanged). In
> any case, maybe it is worthwhile to explicitly state in this section that
> this information is exchanged in plain text and non authenticated. Also,
> the last paragraph of this section states that there are other transport
> parameters exchanged in the connection establishment. I assume that those
> are exchanged after the crypto, so they are encrypted and authenticated? Is
> there any other transport parameter exchanged in clear text? Probably it
> would be useful to make this explicit?
>
>
> One thing I am missing here (probably because suffering a TCP bias) is the
> initial packet sequence number to be used in the connection.
>
> Do you always use 0 as initial PSN? If so, this is because you assume that
> the crypto mechanisms established during the crypto handshake will prevent
> packet form previous connections to re-emerge later on and be confused for
> packets in the new connection? If this is the case, maybe you should state
> it explicitly in section 4.2.3?
>
> and appear as packet of a new connection, since they can be using the same
> PSN?
>
>
> can later leave the location and because it still has the STK, it can, by
> spoofing the source address, pretend to still be there, since only the STK
> is enough to pass this test.
>
> simply sending paced ACKs to any location it once was (given that the PSN
> initial number is always 0, it doesnt even needs to guess the PSNs),
> correct?
>
> endpoints, in the subsequent connections, the client and server roles must
> be preserved or they can be changed?
>
> It states that quic accommodates the possibility of out-of-order delivery.
> Do you mean out of order delivery within the same stream or across streams?
> clarify?
>
> stream while they were part of an older stream? It cannot be done using the
> offset, since for all connection it starts in 0. I guess it could be done
> using the PSN, but then the receiver needs to check that all PSN of packets
> for a new stream are higher than the PSN of the packet that terminated the
> older stream, is this the proposed approach?
>
> with old packets re emerging after the connection/stream has ended, given
> that it does not relies on the sequence number to do so, afaict.
>
> In particular, in section 5.1.1 it states that a stream is open by sending
> or receiving a data packet with that particular stream ID. I assume that
> the data packet MUST contain a 0 offset to create the new stream? is this
> correct?
>
>
> I guess you should reserve a range of identifiers for future use, in case
> other "special" streams are needed in the future?
>
>
> Is the initial offset for the data packet sent on a stream set to zero? If
> this is the case, would be good to state it.
>
>
> Section 6. on Packetization and reliability. What is the initial PSN in a
> given connection? State it explicitly.
>
> multiple frames. I guess it would be useful to provide guidance on what you
> consider a short period of time. Is that 500ms as in the delayed acks or
> are you thinking much less?
>
> implies than that WINDOW_UPDATE and BLOCKED frames must be retransmitted,
> but i am not sure if this makes sense. I mean, maybe there were other
> WINDOW_UPDATE frames than were sent after this one so retransmitting this
> one probably doesnt make sense, since the information it contains may be
> stalled, no?
>
> I still dont understand why having both connection and stream flow control
> is useful. I would assume that only stream flow control would be useful. Or
> having one or the other in a given connection, but i fail to understand why
> is useful to have both of them simultaneously in the same connection.
>
>
> Section 6 states
>
> This means that there will be holes in the sequence of packets received by
> the receiver i.e. any packet that get's lost, is simply lost and will never
> be received by the receiver. Am i understanding this correctly?
>
> means that if an ACK is lost, then the sender gives up on this packet and
> eventually will retransmit the data in other packets with a different PSN,
> correct?
>
>
> that the receiver open the window, then retransmitting the BLOCKED frame is
> not useful (doesnt harm neither i guess)
>
> msg when there is no window (which is different from reliably transmitting
> the BLOCKED message, since it is periodically sent only when the window is
> 0)
>
>
> for a new connection? shouldnt also be a hold time to avoid delayed packets
> of the old connection? How much time would be safe?
>
> Section 10.4
>
> Also, I understand that packets are never retransmitted with the same PSN.
> So, if a packet is lost, there will be a hole in the receiver for that PSN
> and the data will be sent in other packets with othew PSN. Hence, you
> cannot have cummulative acks.
>
> receiver but that all the ACKs for that packet to be lost on the way back
> and then the sender will timeout and retransmit, right? (I guess that is
> ok, since data will be retransmitted in other packets)
>
> Let me verify that I understand when a stop waiting frames should be sent
> by the sender. I guess that a sender should send a given PSN X in a stop
> waiting frame if all the packet with PSN lower than X have been received or
> have timed out, correct?
>
> Regards, marcelo
>
> _______________________________________________
> QUIC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/quic
>

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 19 Oct 2016 22:49:16 -0700

Hi Marcelo,

Thanks much again for your detailed read of the document. Reponses inline:

> both. Maybe it is worthwhile making explicit in this section why this is

Yes, like HTTP/2 flow control
<http://httpwg.org/specs/rfc7540.html#rfc.section.5.2>, the offset is
announced at both the connection-level and the stream-level. The general
intuition is exactly the same as with HTTP/2 -- that the connection-level
window provides an upper bound on the memory commitment at the receiver for
this connection. The expectation is that this window will be larger than
any one stream's window. This is so that even if one stream were to be
blocked (meaning that the receiver was not draining a stream), that stream
would not consume the entire receiver buffer and allow other stream(s) to
proceed.

Does this make sense? This is basically what the text in the draft says,
but if you think it can be clarified further, let me know.

> worthwhile mentioning this mobility support in this section?

That's correct -- this is enough to handle what we call "connection
migration". I was considering making that section heading "Connection
Migration and Resilience to NAT Rebinding", so I'll do that.

On simultaneous mobility -- I have to think more about this, but it seems
plausible with the connection ID as well. Basically, since the key still
protects the header (including the connection ID), and proof of ownership
of the key should be enough to authenticate the endpoint, so I think this
is reasonable. I'll add a note about this to the spec as well.

This mechanism isn't adequate to do general-purpose multipath (MPTCP-style)
however. That will need more bells and whistles.

> this information is exchanged in plain text and non authenticated.

Yes, this is correct. Clarified text: "The version negotiation packet is
unencrypted and exchanged without packet-level authentication. Therefore,
in order to avoid downgrade attacks, the client and server MUST include
their supported versions later in their corresponding crypto handshake
data."

I've also modified text in 3.6: "Generally, QUIC packets are always
authenticated and typically the payload is fully encrypted. The parts of
the packet header which are not encrypted are still authenticated by the
receiver, so as to thwart any packet injection or manipulation by third
parties. Some early handshake packets, such as the version negotiation
packet, are not encrypted, but information sent in these unencrypted
handshake packets is later verified under crypto cover."

Also, the last paragraph of this section states that there are other
> transport parameters exchanged in the connection establishment. I assume
> that those are exchanged after the crypto, so they are encrypted and
> authenticated? Is there any other transport parameter exchanged in clear
> text? Probably it would be useful to make this explicit?
>

Yeah, currently the transport params sent by the client are sent in clear
text, but again, later verified since the key derivation includes the
handshake packets. This would be a requirement of the handshake protocol.
I've added some text in the Crypto Handshake Protocol Features section:
"Transport Negotiation: The crypto handshake MUST provide a mechanism for
the transport component to exchange transport parameters and Source Address
Tokens. To avoid downgrade attacks, the transport parameters sent and
received MUST be verified before the handshake completes successfully."

> it explicitly in section 4.2.3?

Correct. Zero is always the initial PSN, and yes, there should be no
confusion with packets from other (previous) connections, since the key for
this connection should be different. This should be a requirement of the
crypto handshake, so thanks for pointing it out. I've added the following
to section 4.2.3: "The crypto handshake MUST ensure that the final
negotiated key is distinct for every connection between two endpoints."

> and appear as packet of a new connection, since they can be using the same

Multiple connections do not share the same final crypto key. What in
Section 4.2.2 led you to believe that?

I'll respond to the rest of the comments tomorrow.

Thanks again,
- jana

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 20 Oct 2016 19:49:09 -0700

Hi Marcelo,

Thank you again for your really careful and deep dive in to the spec!
Responses for rest of the comments inline:

> check at the beginning of each connection, correct?

The STK provides proof of IP ownsership. A client includes the source
address token (which was issued by the server to it in a previous
connection) to demonstrate ownership of it's IP address. If the client has
moved to a different IP address, if the token is too old, or if the client
doesn’t have a token, then the server rejects the connection and issues a
fresh token to the client. This is very similar to TFO's cookie, as the
draft notes.

I mean, the STK proves that the client was once in that location and it can
> later leave the location and because it still has the STK, it can, by

Yes, this is a legitimate attack vector. I'll note (also in the draft) that
there are two simple mitigations. I've added the following text in Security
Considerations. Make sense?
"
Spoofed Ack Attack

An attacker steals the victim's STK, spoofs the victim's IP, and initiates
a 0-RTT connection with a server on the victim's behalf. The attacker then
spoofs ack packets to the server which cause the server to potentially
drown the victim in data.

There are two possible mitigations to this attack. The simplest one is that
a server can unilaterally create a gap in the PSN space. In the non-attack
scenario, the client will send back NACKs for the PSNs in the gap, but the
server will eventually send a STOP_WAITING frame for those packets. In the
attack scenario, the attacker may ack a packet in the gap. If the server
sees an ack for a packet that was never sent, the connection can be aborted.

The second mitigation is that the server can require that acks for sent
packets match the encryption level of the sent packet. This mitigation is
useful if the connection has an ephemeral forward-secure key that is
generated and used for every new connection. If a packet sent is encrypted
with a forward-secure key, then any acks that are received for them must
also be forward-secure encrypted. Since the attacker will not have the
forward secure key, the attacker will not be able to generate
forward-secure encrypted ack packets.
"

> believe it changes the threat model significantly.

The presumption certainly was that the roles are preserved. With QUIC's
current (non-TLS) crypto handshake, there are very clear roles, and I
believe that TLS also has a clear expectation of client/server roles. That
said, I think this consideration belongs in either the TLS mapping document
(or in TLS itself) since that document should handle any threat models that
arise from it's 0-RTT implementation with an STK and/or TFO cookie. Is
there any clarification that you think might be useful to add to the crypto
handshake requirements section?

> Nit: the paragraph on the bullet on Server Config Update is truncated.

Removed the truncated sentence -- thanks!

> Do you mean out of order delivery within the same stream or across streams?

Across streams. I've changed the text to: "the possibility of out-of-order
delivery due to the use of multiple streams in QUIC"

> stream is established by simply data with a new stream id, correct?

Correct.

> streams is included, and the initial packet has offset 0).

Correct.

> that it does not relies on the sequence number to do so, afaict.

Within the connection, the Section 5.2 says " A QUIC endpoint MUST NOT
reuse a StreamID on a given connection," so such STREAM frames will be
considered duplicates. Do you think this can be clarified better somewhere?

> the data packet MUST contain a 0 offset to create the new stream? is this

Not necessarily, since the packet containing a STREAM frame with a 0 offset
may have been dropped in the network. A STREAM frame with an offset > 0 may
be accepted, but the data will not get delivered to the application until
the intiial gap within the stream is filled.

> other "special" streams are needed in the future?

I'm not sure what the point of reserving any  would be, since if a special
stream is needed in the future, this usage can be negotiated with either an
option or with a version change.

> this is the case, would be good to state it.

I've added this sentence: "The first byte of data that is sent on a stream
has the stream offset 0."

> given connection? State it explicitly.

Added "The initial PSN used, at both the client and the server, MUST be 0.
That is, the first packet in both directions of the connection MUST have a
PSN of 0."

> are you thinking much less?

MUCH less. This is definitely a MAY, and I am not sure if recommending
something here makes sense, since the expectations in any deployment will
be different about how much waiting makes sense. How's the following: "An
implementation may use heuristics about expected application sending
behavior to determine whether and for how long to wait. This waiting period
is an implementation decision, and an implementation should be careful to
delay conservatively, since any delay is likely to increase
application-visible latency."

Later on, it states that only ACK, STOP_WAITING and PADDING frames MUST not
> be retransmitted, but all other frames must be retransmitted. This implies
> than that WINDOW_UPDATE and BLOCKED frames must be retransmitted, but i am
> not sure if this makes sense. I mean, maybe there were other WINDOW_UPDATE
> frames than were sent after this one so retransmitting this one probably
> doesnt make sense, since the information it contains may be stalled, no?
>

You're correct that WINDOW_UPDATE and BLOCKED frames are retransmitted.
It's hard to construct a scenario however where a WINDOW_UPDATE frame keeps
getting dropped, but the client still sends enough data to cause a new
revised WINDOW_UPDATE frame to be sent... I agree that in this case the
sender would be retransmitted useless information, but I don't think we
need to optimize for this case.

> is useful to have both of them simultaneously in the same connection.

I've answered this above, let me know if there's more clarification that
can be had in the doc.

Section 6 states
> retransmitted in other packets with other PSN (other than 5). If this

Correct.

> be received by the receiver. Am i understanding this correctly?

Correct.

> Does this means that ACKs transmission is unreliable, correct?

Correct.

> eventually will retransmit the data in other packets with a different PSN,

Correct.

> guidance about this would be useful.

As I clarified above, a stream ID can never be reused.

Section 7.1.4.
> Is the BLOCKED frame reliably transmitted? I assume it is, but, does it

Yes, it is reliably transmitted.

> OTOH, what if the BLOCKED frame get's lost? Do we end up with the silly

The BLOCKED frame is really a debugging frame... it's good to know at the
receiver that the sender was flow control blocked. Since the receiver is
expected to have sent a WINDOW_UPDATE well in advance, and since the
BLOCKED frame is not a required part of the flow control machinery, it
doesn't cause SWS. It's currently required for the sender to send, but not
required to be processed by the receiver beyond maybe logging it somewhere.
I've modified the text in Section 7.1.4 to say:

"If a sender does not receive a WINDOW_UPDATE frame when it has run out of
flow control credit, the sender will be blocked and MUST send a BLOCKED
frame. A BLOCKED frame is expected to be useful for debugging at the
receiver. A receiver SHOULD NOT wait for a BLOCKED frame before sending
with a WINDOW_UPDATE, since doing so will cause at least one roundtrip of
quiescence. For smooth operation of the congestion controller, it is
generally considered best to not let the sender go into quiescence if
avoidable. To avoid blocking a sender, and to reasonably account for the
possibiity of loss, a receiver should send a WINDOW_UPDATE frame at least
two roundtrips before it expects the sender to get blocked."

Is that clearer?

> of the old connection? How much time would be safe?

Do you mean Connection ID? Again, since the expectation is that the keys
will be different. Of course that depends on the KDF, but that depends on
the crypto protocol in use. I think the clarification that I added above to
the crypto requirements should be enough. What do you think?

> cannot have cummulative acks.

Correct.

> ok, since data will be retransmitted in other packets)

Correct.

> waiting frame if all the packet with PSN lower than X have been received or

Correct. I would say when all PSNs <= X are no longer considered in flight.

Thanks again,
- jana