Re: Consensus Calls for Late Stage Documents

[Jana Iyengar <[e-mail]>]

Tommy,

The draft currently says that senders SHOULD pace, and PR 3351 gets into
more detailed guidance for a sender that does not follow our
recommendation. I have questions about the specific guidance in that PR,
but more to the point here, the wg was clear in Singapore that we should
not do more pseudo-code for cases we don't recommend. Description of more
mechanism for cases that are not recommended falls in a similar category.

PR 3232 is meant to be a safety mechanism to protect a network from a
sender that does not follow our recommendation to pace. I'm not opposed to
making such a sender performant, but it seems to me that we do not need to
get into this in the spec.

Perhaps it might help if we added a note about how a non-paced sender might
encounter performance issues?

- jana

On Wed, Jan 15, 2020 at 2:26 PM Tommy Pauly <[e-mail]> wrote:

>
>
> On Jan 15, 2020, at 2:16 PM, Jana Iyengar <[e-mail]> wrote:
>
> Vidhi,
>
> The current draft already recommends use of a pacer, and your PR 3351
> suggests a mechanism that an endpoint can use for doing it. That still
> doesn't obviate the earlier need to specify a requirement for endpoints
> that do not implement any pacing.
>
> Basically, codifying an example pacer does not change the premise of PR
> 3232 - that implementations might choose to not pace.
>
> Said differently, even if we were to specify one way of pacing, as PR 3351
> does, PR 3232 still applies. I don't think we need to hold off on PR 3232
> based on PR 3351.
>
>
> We can discuss more on the issues/PRs, but one quick note on why we'd like
> to hold off on merging anything just yet:
>
> In our testing, the specific solution described in #3232 can actually
> cause some issues with underutilizing the link that are undesirable. Beyond
> that, it still leaves edge cases open in which burst can still occur, which
> is the problem originally described in #3094. The new PR is describing
> another approach to solve #3094.
>
> The main spirit of the new PR is noting that the main problem with
> non-pacing implementations being too bursty is that the burst limit
> specified in the pacing section today gives a byte limit, but no time
> limit. It should be sufficient to specify some bounds on the delay between
> bursts to solve the problem described in #3094, without locking
> implementations into a specific congestion-control relationship with the
> number of ack packets (not just acked bytes as it is today).
>
> Best,
> Tommy
>
>
> - jana
>
> On Wed, Jan 15, 2020 at 1:47 PM Vidhi Goel <vidhi_goel=
> [e-mail]> wrote:
>
>> Hi Mark,
>>
>> * #3094: congestion window increase on every ACKed packet could result in
>> bursty sends
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3232>
>>
>>
>> We would like to hold off on this change as we are working on specifying
>> Pacing mechanism which would allow the implementations to decouple
>> congestion window increase from sending rate and thus eliminate the need
>> for 2MSS limit during slow start.
>> Below is the PR:
>> https://github.com/quicwg/base-drafts/pull/3351
>>
>> I will create a issue to start the discussion.
>>
>> Thanks,
>> Vidhi
>>
>> On Jan 5, 2020, at 7:56 PM, Mark Nottingham <[e-mail]> wrote:
>>
>> Happy New Year, Working Group.
>>
>> The following issues have proposals for resolution, and discussion so far
>> seems to support consensus to accept them. If you object, please do so on
>> the issue or in response to this message (changing the Subject
>> appropriately!). Absent any pushback, we'll direct the editors to
>> incorporate them late next week.
>>
>> See <https://github.com/quicwg/base-drafts/projects/5> for the current
>> state of issues in the Late Stage process, itself defined at <
>> https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md>.
>>
>> * #3274: Encrypting Retry token
>>   The proposal is <https://github.com/quicwg/base-drafts/issues/3274>
>>
>> * #3247: I am concerned the congestion control text is too permissive.
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3248>
>>
>> * #3245: Make RFC 6928 normative
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3287>
>>
>> * #3244: Can we make a normative ref to  RFC8085?
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3248>
>>
>> * #3243: Add caution when using IW10 and fragmentation
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3280>
>>
>> * #3152: Client storage of tokens should be independent of other stored
>> state
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3150>
>>
>> * #3142: It is unspecified how a server sends Handshake packets during /
>> after migration
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3145>
>>
>> * #3094: congestion window increase on every ACKed packet could result in
>> bursty sends
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3232>
>>
>> * #3014: Handling of corrupt Retry packets
>>   The proposal is <https://github.com/quicwg/base-drafts/issues/3274>
>>
>> * #2863: unrecoverable loss pattern leads to deadlock
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3145>
>>
>> * #2789: Use a higher seed RTT for new paths
>>   The proposal is to close with no action.
>>
>> * #2744: Idle Timer Can Fire Even with Outstanding Data to Send
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3266>
>>
>> * #2602: Idle timeout needs more description and a recommendation
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3099>
>>
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>>
>>
>