Re: too much call to SetLossDetectionTimer()?

[Jana Iyengar <[e-mail]>]

This is fine, I'd argue... it's unnecessary, but it doesn't break anything.
And the pseudo code is meant to clarify the text, rather than simply be
used verbatim in implementations anyways.

On Thu, Sep 10, 2020 at 8:27 AM Ian Swett <ianswett=
[e-mail]> wrote:

> Good point, this is typically unnecessary.  However, I think it also may
> be clearer to call it here than not?  Alternatively, we could add a comment
> and an assert.
>
> On Thu, Sep 10, 2020 at 10:10 AM newbie quic <[e-mail]> wrote:
>
>> Hello,
>>
>> I have a question about the pseudo-code found in
>> draft-ietf-quic-recovery-30.txt.
>>
>> Especially the part where at least one ack-eliciting packet is sent from
>> OnLossDetectionTimeout(). In every cases, we finally set the loss
>> detection/PTO timer calling SetLossDetectionTimer():
>>
>>      if (bytes_in_flight > 0):
>>          // PTO. Send new data if available, else retransmit old data.
>>          // If neither is available, send a single PING frame.
>>          _, pn_space = GetPtoTimeAndSpace()
>>         SendOneOrTwoAckElicitingPackets(pn_space)
>>      else:
>>          assert(!PeerCompletedAddressValidation())
>>          // Client sends an anti-deadlock packet: Initial is padded
>>          // to earn more anti-amplification credit,
>>          // a Handshake packet proves address ownership.
>>          if (has Handshake keys):
>>               SendOneAckElicitingHandshakePacket()
>>          else:
>>               SendOneAckElicitingPaddedInitialPacket()
>>
>>      pto_count++
>>      SetLossDetectionTimer()
>>
>> Then as a sent ack-eliciting packet must be considered as in flight,
>> OnSentPacket() will also make a call to SetLossDetectionTimer().
>>
>>
>> Regards.
>>
>