Re: PADDING vs PING

[Roberto Peon <[e-mail]>]

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 <[e-mail]>
Date: 3/19/18 8:35 AM (GMT-08:00)
To: "Lubashev, Igor" <[e-mail]>
Cc: IETF QUIC WG <[e-mail]>, Martin Thomson <[e-mail]>
Subject: Re: PADDING vs PING

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=[e-mail]<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.

-----Original Message-----
From: Martin Thomson [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Monday, March 19, 2018 2:37 PM
To: Lubashev, Igor <[e-mail]<mailto:[e-mail]>>
Cc: IETF QUIC WG <[e-mail]<mailto:[e-mail]>>
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=[e-mail]<mailto:[e-mail]>> 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