Re: Consensus Calls for Late Stage Documents

[Tommy Pauly <[e-mail]>]

Hi Jana,

That definitely makes sense that we don't want to spend too much time in the text on a non-recommended case, such as not pacing. Let's use the new PR to discuss any text reworking that can get closer to that goal, while clarifying the recommendations.

With regards to #3232, one of the things we found in testing was that it could (a) still allow an implementation to be vulnerable to too much bursting (the original problem), but more importantly (b) locked receivers into an ack pattern of acking every other packet. My main concern is that this causes problems if receivers want to experiment with and change acking strategies going forward in way that otherwise would be fine.

Best,
Tommy

> On Jan 15, 2020, at 2:42 PM, Jana Iyengar <[e-mail]> wrote:
> 
> 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] <mailto:[e-mail]>> wrote:
> 
> 
>> On Jan 15, 2020, at 2:16 PM, Jana Iyengar <[e-mail] <mailto:[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] <mailto:[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 <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 <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] <mailto:[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 <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 <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 <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 <https://github.com/quicwg/base-drafts/pull/3248>>
>>> 
>>> * #3245: Make RFC 6928 normative
>>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3287 <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 <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 <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 <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 <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 <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 <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 <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 <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 <https://github.com/quicwg/base-drafts/pull/3099>>
>>> 
>>> 
>>> --
>>> Mark Nottingham   https://www.mnot.net/ <https://www.mnot.net/>
>>> 
>> 
>