Re: WG last call comments on draft-ietf-quic-transport-29

[Martin Thomson <[e-mail]>]

Hi Magnus,

Thanks for taking the time to review.  These are all good.  I've opened a PR that addresses most of these, but some might require some discussion.

https://github.com/quicwg/base-drafts/pull/3881

On Thu, Jul 9, 2020, at 04:04, Magnus Westerlund wrote:
...
> 1. Section 1.3: 
> 
> x (A..B): Indicates that x can be any length from A to B; A can be
>  omitted to indicate a minimum of zero bits and B can be omitted to
>  indicate no set upper limit; values in this format always end on
>  an octet boundary
> 
> There is an upper limit based on the protocol even in these cases, 
> either due to encoding restrictions or the protocol. 2^62-1 bytes in 
> most cases for length or data limits or the per packet limit where MPS 
> will be a restriction. Should that be made more explicit. 

This is a length of a field in bits, which means that "no set upper limit" is fine in my view.  There is often an upper limit, but it depends on how much space is left in the packet.  Note that the 2^62 cap doesn't have to apply to lengths in bits.

> 2. Section 3.2, Figure 3: 
> The top most RESET_STREAM which leads to the Recv state. Shouldn't that 
> go to the RESET Recvd state immediately. If I interpret the figure it 
> will take two RESET_STREAMS until one end up in RESET RECVD

There are a few places in the diagrams where a single event causes multiple transitions.  For instance, receiving STREAM with FIN can cause a transition from the starting state, through Recv and Size Known, to Data Recvd.  I thought that we had noted that this can happen, but I see that this didn't happen.

> 3. Section 4.1: "
> 
> If a sender is blocked
>  for a period longer than the idle timeout (Section 10.2), the
>  connection might be closed even when data is available for
>  transmission."
> 
> Who may close the conenction? both peers, or the sender that is blocked 
> or the receiver?

The receiver.  Addressed in the PR.

> 4. Section 7.4.1: "
> 
>  In particular, a server that accepts 0-RTT data
>  MUST NOT set values for the following parameters (Section 18.2) that
>  are smaller than the remembered value of the parameters."
> 
> 
> So far I have not seen any definition for how long TP parameters will 
> be remembered. I guess that there is a time limit on the 0-RTT keying 
> material stored in the client that is relevant her, however this is not 
> at all referenced here. Should there be a pointer or explanation? 
> Because the above normative statement appears to be missing the tie 
> into how long the client will remember theses remembered values.

The rule is that when you remember a ticket, you need to remember a bunch of stuff with that in order for 0-RTT to work.  You don't get to remember part of that and expect to have 0-RTT work.  I've added a little more context.

I've also opened https://github.com/quicwg/base-drafts/pull/3879 to improve on the context in the -tls draft.

> 5. Section 8.1.3 and 8.1.4:
> 
> First of all I got the wrong impression of this section as the details 
> about address validation part, that you actually include the address is 
> in the next section 8.1.4. I don't know if there should be something 
> done about this or not. But my impression after 8.1.3 and before I read 
> 8.1.4 that this was not address validation, only client validation, 
> i.e. this is a client I talked to before. 
> 
> My actual question I have on these section is if it there should be 
> clarification on that the client should keep track of the token on a 
> server authority + client address/network scope. So that the client 
> will not send the token unless it is on the same network it was before. 
>
> But maybe this last is unnecessary as the server will ignore the token 
> if it doesn't match. 

Right.  The cost to the client is:

1. The server can correlate the attempt with a previous connection.
2. The client uses up the token.

I think that the text in 8.1.3 is adequate on this point.

> 6. Section 9.2:
> 
>  Receiving acknowledgments for data sent on the new path serves as
>  proof of the peer's reachability from the new address.

> So this might be an intended differenation between path validation and 
> indication of basic reachability (assuming no hostility). Maybe that 
> exception also needs to be noted in the last paragraph in Section 9.2.

Oh, good catch.  The point about acknowledgments is just wrong.  This is just old text that should have been fixed.

> 7. Section 9.3.1: 
> 
>  If an endpoint skips validation of a peer address as described in
>  Section 9.3, it does not need to limit its sending rate.
> ...
> So the question here is what is considered recently. I think the 
> lifetime of a address validation is significantly longer than the 
> validity of the congestion control state. 

This is a tough question, and entirely subjective.  No number is good here.  I've heard that some implementations limit this to a day, other to an hour.  I suspect that we just have to live with this.

I've opened an issue: https://github.com/quicwg/base-drafts/issues/3880

> 8. Section 10.1: 
> "Endpoints that have some alternative
>  means to ensure that late-arriving packets on the connection do not
>  induce a response, such as those that are able to close the UDP
>  socket, MAY use an abbreviated draining period which can allow for
>  faster resource recovery."
> 
> So to me this assumes that the underlying system will not reuse the 
> local UDP port in the time it takes to drain the network. I assume even 
> applications may shoot itself in the foot if it insist on a local 
> source port for an outgoing QUIC connections and that was recently 
> used. I assume that this will not have any significant impact on a QUIC 
> instance, and what it does to another UDP protocol is all dependent.

Yes.  I think that this generally only applies to use of ephemeral ports on client systems, where the reuse period is relatively long. 

More importantly, the consequence is that the new user of the port has to filter out some residual garbage.  As everything in QUIC is authenticated, this is not a serious problem in the same way that it might be for another protocol.

> 10. Section 10.2: "
...
> Should this really be the minimum and not the maximum. For very low 
> values of MAX_IDLE_TIMEOUT the QUIC stack is not even given a fair 
> chance of probing if the path is still there or not? And for larger 
> value the 3*PTO will always be setting the value. I would have expected 
> the maximum, that below 3*PTO it will not timeout, and when 
> MAX_IDLE_TIMEOUT > 3*PTO that value will be limit for how long probing 
> is done. 
This was found and a fix prepared already: https://github.com/quicwg/base-drafts/pull/3847

> Doesn't the rule also prevent a stack being silent for longer than 
> 3*PTOs? That appears wasteful to force continuos communication if there 
> are no data be sent. 

The 3PTO was a backstop for cases where the idle timeout was set too low relative to the RTT.  Our advice on keeping connections alive is not to do that unless you have committed state that you don't want to lose.  For instance, an HTTP client might send keep-alives only while it is waiting for a response to a request.

> 11. Section 10.3:
> 
> Such an
>  endpoint SHOULD limit the number of packets it generates containing a
>  CONNECTION_CLOSE frame.
> 
> 
> To what level should it be limited, e.g. one packet per 1/4 RTT? Or is 
> the argument that 
> Any reduction is sufficient. To me it looks like a simple packet mirror 
> on path that sends the packets back to the sender will maintain the 
> number of packets in flight unless there is a reduction factor.

This was raised in https://github.com/quicwg/base-drafts/issues/3845

I agree that this is vague.  I have proposed a solution here based on our anti-amplification limit: https://github.com/quicwg/base-drafts/pull/3864

Note also that this is limited to the duration of the closing period, so this is not a permanent state.  A small amount of amplification is likely tolerable on that time frame.

> 12. Section 12.4:
...
>  Packet Payload {
>  Frame (1..) 1...,
>  }

Yes.  Frame (8..) ..., But I don't think that we can capture the requirement to include at least one frame.  That's OK, it's just for illustration purposes :)

> 13. Section 17.2.2:
> 
> Length field for the Packet header is undefined. I would guess that it 
> contains the total length of the Initial Packet in bytes but that 
> should be defined. Applies also to the 0-RTT and Handshake packet.

They are mentioned and defined earlier, but their mentions don't reference the definition.  Fixed.

> 14. Section 17.2.5:
> 
> The value in the Unused field is selected randomly by the
>  server.
> 
> Should this say that the receiver should ignore the value in the field?

Fixed.  Thanks.

> 15. Section 19.9:
> 
> The Maximum Data (i) field as currently defined will be in many 
> connections the upper limit for how many packets can be sent in any 
> connection due to its bit limit. As this is a maximum value due to 
> usage of the variable encoding to 2^62-1 bytes. It is possible that 
> this value could be reached as around 2^52 packets approximately. An 
> QUIC packet will be possible to contain at least 1024 bytes, i.e. 10 
> bits worth of bytes. In a DC center network with larger MTUs it is 
> possible that already after 2^50 packets this value will be exhausted.
> 
> Should I simply assume that this amount of data is such a big number 
> that if an application runs into the limit forcing it to restart the 
> connection is a minor issue. However considering that the limit in 
> packets are relatively more discussed, this limit is not much discussed 
> and in fact there are no mention in 19.9 what to do if that value 
> reaches maximum that can be encoded, i.e. close the connection. 

Yes, that is the current thinking.  Note that there were proposals to scale the values in MAX_DATA to allow for more data to be sent.  However, this proposal wasn't that favourably viewed as it increased complexity quite a bit, and 2^62 is really a very big number and having to create another connection at that rate isn't that much of an imposition.

(Also, I've learned that you don't get to make many such connections before you wear out the AEAD functions we have here.)

>  16. Section 22.1.4: 
> 
> 
>    All registrations in this document are assigned a permanent status
>  and list as contact both the IESG ([e-mail]) and the QUIC
> 
>  working group ([e-mail] (mailto:[e-mail])).
> 
> 
> The IESG is recommending that registration owner for IETF STD documents 
> are IETF. The arguments are in this doc: 
> 
> https://datatracker.ietf.org/doc/draft-leiba-ietf-iana-registrations/

Corrected.  Thanks.

>  1. Section 22:
> 
> An important question that for the high level structure of the 
> registries are the question if these registries are Version 1 specific, 
> or expected to be used across multiple versions of QUIC? Because if the 
> former then the general heading for the registries should say QUIC 
> Version 1. If they are intended to be for multiple versions, what type 
> of indication for which version particular entries are valid are 
> needed? 

I think that leaving that problem to future iterations of this group is best.  I know that future me will have ample cause to resent the decisions of present me anyway.

If QUICv2 wants to reuse these, then no change is necessary.  However, if they/we want to make new registries, then renaming these registries requires little effort.