Subject: [quicwg/base-drafts] Clarify initial UDP datagram padding (#2519)

From: Dmitri Tikhonov <[email-masked]>
Date: Wed, 13 Mar 2019 07:47:10 -0700

[Section 8.1 of the transport draft](https://tools.ietf.org/html/draft-ietf-quic-transport-19#section-8.1) states:

```
   Clients MUST pad UDP datagrams that contain only Initial packets to
   at least 1200 bytes.
```

This seemingly says that the first UDP datagram that has two coalesced packets, Initial and 0-RTT, can be smaller than 1200 bytes.  I don't believe that's the intention.

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

---

From: ianswett <[email-masked]>
Date: Wed, 13 Mar 2019 07:50:26 -0700

Agreed, I believe the "only" needs to removed unless I'm missing some other intent.

-- 
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/2519#issuecomment-472454716

---

From: Martin Thomson <[email-masked]>
Date: Wed, 13 Mar 2019 21:36:40 +0000 (UTC)

I don't think that is sufficient.  The intent of this was to allow the client to send Initial packets that acknowledge server Initial packets without padding to 1200.

-- 
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/2519#issuecomment-472615572

---

From: ianswett <[email-masked]>
Date: Wed, 13 Mar 2019 22:25:39 +0000 (UTC)

Given PADDING is supposed to count towards bytes in flight, but it's not ack-eliciting, a special case for ACK-only packets makes sense.  I'd be inclined to specify ACK-only packets as the exception, opposed to basing it on receiving an ACK of handshake or some other mechanism.

-- 
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/2519#issuecomment-472630210

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 13 Mar 2019 22:36:17 +0000 (UTC)

As stated in 
https://github.com/quicwg/base-drafts/pull/2520#discussion_r265213467, I prefer to stop requiring the use of full-sized packets once the client observes a response from server. Reasons:
* QUIC stacks would have the logic to change rules based on if the peer's address has been validated due to the 3-packet rule on the server side. It's just about using the same logic for padding on the client side.
* Implementations that prefer to pad all the Initial packets it sends can do so anyways.
* Regardless of what we decide, the server side logic would be indifferent; i.e. create new connection context only when observing a full-sized Initial packet.

-- 
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/2519#issuecomment-472633202

---

From: Martin Thomson <[email-masked]>
Date: Wed, 13 Mar 2019 18:43:29 -0700

tl;dr: we should always pad to 1200 for UDP datagrams that contain Initial packets.

The reason we pad to 1200 is to provide a server with plenty of inbound bytes so that it can send outbound bytes prior to path validation.  Padding to 1200 has sub-optimal performance in certain cases.  In particular, it makes datagrams containing a simple ACK enormous.  So the original thought was to try to find a case where we could allow for smaller datagrams to be sent.

I think that in both alternative designs we have a problem with the interaction with our DoS defense.  And while those problems might only exist in the abstract for now, I think that the best answer is to pad to 1200 always.

(I will suggest rewording the text separately.)

### Details

An ACK-only Initial packet is sent at the tail of the Initial phase.  That is the obvious candidate for consideration here.  But there are other cases where small Initial packets might be sent.

The looser requirement @kazuho suggests is less than ideal for HelloRetryRequest.  A client can receive a HelloRetryRequest and be forced to send another ClientHello.  We can't assume here that the server is using the HelloRetryRequest to validate the client address (though it certainly can).  

If the ClientHello message is small, the number of bytes that a server can send is still limited.  If the client doesn't pad, the server can still count the original ClientHello toward its budget, but it doesn't get significant additional budget from the client.  And that budget doesn't increase when packets are lost.  So it could be that the server is stuck with 3x whatever it gets in ACKs, which is not a lot.

It's worse if you consider the possibility of the ServerHello being enormous (hello PQ crypto). At this point, the server won't have validated the client address and so is still limited in what it can send.  Ideally, we want the packets to be big so that the server gets more budget for sending and isn't limited to sending tiny packets.  But if all the client sends is small ACK-only packets (under either proposed amendment, either what @ianswett or @kazuho describe), the increased allowance is very small. 

Based on this, I would suggest that we reluctantly say that all Initial-carrying datagrams need to be 1200 bytes or more.

For the case of the ACK at the tail, most of the designs proposed for key discard will result in that packet not being sent.  If it is sent, there are plenty of cases where it will be a packet with Initial (ACK), Handshake (ACK + ...Finished) and 1-RTT data, so the requirement is met without wasting bytes at all.  But for ACK of big ServerHello messages or HelloRetryRequest, the overhead is regrettably necessary.

-- 
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/2519#issuecomment-472671420

---

From: ianswett <[email-masked]>
Date: Wed, 13 Mar 2019 18:56:30 -0700

SGTM.

I agree this greatly incentivizes good coalescing, but otherwise I don't see any downsides.  And simple is good.

Even when suggesting the special case for ACK-only packets, it felt like a premature optimization.

-- 
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/2519#issuecomment-472673819

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 13 Mar 2019 19:00:16 -0700

Works for me.

It's a corner case anyways. Unless HRR is involved, client will not send an Initial in response to the server's Initial, assuming we decide to continue dropping the Initial keys when the client receives a handshake packet. 

-- 
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/2519#issuecomment-472674499

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 15 Mar 2019 13:16:05 -0700

Closed #2519 via #2520.

-- 
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/2519#event-2207518439