Re: PADDING vs PING

[Martin Thomson <[e-mail]>]

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 <[e-mail]> 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.
>
>
>
> On Mon, Mar 19, 2018 at 3:02 PM, Lubashev, Igor
> <ilubashe=[e-mail]> 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]]
>> Sent: Monday, March 19, 2018 2:37 PM
>> To: Lubashev, Igor <[e-mail]>
>> Cc: IETF QUIC WG <[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]> 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
>>
>