Subject: PADDING vs PING

From: "Lubashev, Igor" <[email-masked]>
Date: Mon, 19 Mar 2018 14:23:19 +0000

Since 4 proposals is not enough, let me propose the 5th one, which is an extension of Subodh's proposal.

  1.  PADDING does NOT count for bytes-in-flight (and does not require ACKs) when it is a part of ACK+PADDING packets.
  2.  PADDING does count for bytes-in-flight and does require ACKs otherwise (including in PADDING-only packets).
  3.  The difference between PADDING and PING in non-(ACK+PADDING) packets is that PING requires an ACK to be sent ASAP, while ACKing PADDING can be delayed, if the receiver does some ACK coalescing.

  *   Igor

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Mar 2018 14:36:40 +0000

The current text counts ACK towards bytes in flight when there are
other frames present, so you just described Option 2.  Albeit more
precisely.

The key is that packets that comprise only (ACK[, PADDING]) count
toward bytes in flight.  That is, the packet counts or not, but the
content determines the answer.

On Mon, Mar 19, 2018 at 2:23 PM, Lubashev, Igor
<ilubashe=[email-masked]> wrote:
> Since 4 proposals is not enough, let me propose the 5th one, which is an
> extension of Subodh’s proposal.
>
>
>
> PADDING does NOT count for bytes-in-flight (and does not require ACKs) when
> it is a part of ACK+PADDING packets.
> PADDING does count for bytes-in-flight and does require ACKs otherwise
> (including in PADDING-only packets).
> The difference between PADDING and PING in non-(ACK+PADDING) packets is that
> PING requires an ACK to be sent ASAP, while ACKing PADDING can be delayed,
> if the receiver does some ACK coalescing.
>
>
>
> Igor

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Mar 2018 14:36:40 +0000

---

From: "Lubashev, Igor" <[email-masked]>
Date: Mon, 19 Mar 2018 15:02:46 +0000

Very well.  So it is Option 2.  One thing I did want to propose that we make the "ACK expectations" of PADDING and PING clear.  Bother require ACKs (except for ACK+PADDING packets), but PING requires an immediate ACK, while PADDING allows for a delay.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Monday, March 19, 2018 2:37 PM
To: Lubashev, Igor <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: PADDING vs PING

The current text counts ACK towards bytes in flight when there are other frames present, so you just described Option 2.  Albeit more precisely.

The key is that packets that comprise only (ACK[, PADDING]) count toward bytes in flight.  That is, the packet counts or not, but the content determines the answer.

On Mon, Mar 19, 2018 at 2:23 PM, Lubashev, Igor <ilubashe=[email-masked]> wrote:
> Since 4 proposals is not enough, let me propose the 5th one, which is 
> an extension of Subodh’s proposal.
>
>
>
> PADDING does NOT count for bytes-in-flight (and does not require ACKs) 
> when it is a part of ACK+PADDING packets.
> The difference between PADDING and PING in non-(ACK+PADDING) packets 
> is that PING requires an ACK to be sent ASAP, while ACKing PADDING can 
> be delayed, if the receiver does some ACK coalescing.
>
>
>
> Igor

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 19 Mar 2018 15:34:31 +0000

For the record, I'll reiterate what I said at the mic (also what Christian
said), which Martin called option 3:
*The PADDING frame counts towards bytes-in-flight but does not generate an
ACK.*

Rationale: This keeps the rule simple and consistent with regard to PADDING
frames. We expect that padding will commonly be used for packets carrying
data. In this case, this is basically option (2), which states that PADDING
frames if carried in packets containing non-ACK frames count towards bytes
in flight. In the exceptional case that PADDING is used with ACK-only
packets, this makes it the sender's problem to "do the right thing": the
sender periodically sends an ACK-generating frame and figures out a time to
clear out the in-flight.

On Mon, Mar 19, 2018 at 3:02 PM, Lubashev, Igor <
ilubashe=[email-masked]> wrote:

> Very well.  So it is Option 2.  One thing I did want to propose that we
> make the "ACK expectations" of PADDING and PING clear.  Bother require ACKs
> (except for ACK+PADDING packets), but PING requires an immediate ACK, while
> PADDING allows for a delay.
>
> The current text counts ACK towards bytes in flight when there are other
> frames present, so you just described Option 2.  Albeit more precisely.
>
> The key is that packets that comprise only (ACK[, PADDING]) count toward
> bytes in flight.  That is, the packet counts or not, but the content
> determines the answer.
>

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 19 Mar 2018 15:34:31 +0000

---

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 19 Mar 2018 16:08:27 +0000

On 2018-3-19, at 15:34, Jana Iyengar <[email-masked]> wrote:
> 
> For the record, I'll reiterate what I said at the mic (also what Christian said), which Martin called option 3:
> The PADDING frame counts towards bytes-in-flight but does not generate an ACK.
> 
> Rationale: This keeps the rule simple and consistent with regard to PADDING frames. We expect that padding will commonly be used for packets carrying data. In this case, this is basically option (2), which states that PADDING frames if carried in packets containing non-ACK frames count towards bytes in flight. In the exceptional case that PADDING is used with ACK-only packets, this makes it the sender's problem to "do the right thing": the sender periodically sends an ACK-generating frame and figures out a time to clear out the in-flight.

FWIW, this works for my particular use of padding, i.e., the need to lay out stream data at a fixed offset for zero-copy. Any frames that are dynamically generated by the stack (such as ACK frames) don't have that need, and I only ever pad packets that contain stream frames.

Lars

---

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 19 Mar 2018 16:08:27 +0000

Lars

---

From: Roberto Peon <[email-masked]>
Date: Mon, 19 Mar 2018 16:11:16 +0000

Given that a smart attacker would be able to infer the fact that padding was used from the lack of an ack, it would seem to more poorly serve its security role without the ack.

For things like bandwidth estimation, it would be nice-to-have the option of getting acks (without requiring rexmission).
I'm thinking about bandwidth probing for video quality selection, as an example. In such a case, since the video data is sent ar ita bitrate,  there aren't  enough bursts to measure the channel bandwidth much beyond the video bitrate.

Delaying some video data so as to better measure bandwidth would make it less interactive, so not the best option.

And then there is the fun bit of needing to signal that the probed data should not be rexmitted if we used something other than padding.

 Padding fits the role nicely here, but only if it is acked.

-=R

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: Jana Iyengar <[email-masked]>
Date: 3/19/18 8:35 AM (GMT-08:00)
To: "Lubashev, Igor" <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>, Martin Thomson <[email-masked]>
Subject: Re: PADDING vs PING

On Mon, Mar 19, 2018 at 3:02 PM, Lubashev, Igor <ilubashe=[email-masked]<mailto:ilubashe=40akamai.com@dmarc...ietf.org>> wrote:
Very well.  So it is Option 2.  One thing I did want to propose that we make the "ACK expectations" of PADDING and PING clear.  Bother require ACKs (except for ACK+PADDING packets), but PING requires an immediate ACK, while PADDING allows for a delay.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Mar 2018 16:55:36 +0000

A particular challenge with this proposal is that it counts the size
of *frames* rather than the size of *packets*.

The current text assumes that the size of packets is what matters.  So
you are proposing a fairly fundamental change.

Given that I think we have to assume that the bytes in flight for a
given packet is observable based on how the endpoint manifests its
congestion control, then any sort of accounting on a frame-by-frame
basis is potentially a way to - in this case - allow an observer to
recover the size of ACK frames.  Not sure how much value that is, but
it might work at odds with padding strategies.

On Mon, Mar 19, 2018 at 3:34 PM, Jana Iyengar <[email-masked]> wrote:
> On Mon, Mar 19, 2018 at 3:02 PM, Lubashev, Igor

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Mar 2018 16:55:36 +0000