Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use time_of_last_sent_packet #923

Merged
merged 2 commits into from Nov 30, 2017
Merged

Use time_of_last_sent_packet #923

merged 2 commits into from Nov 30, 2017

Conversation

ianswett
Copy link
Contributor

time_of_last_sent_packet should be used to set the loss detection timer, instead of using now.

Fixes #540

time_of_last_sent_packet should be used to set the loss detection timer, instead of using now.
@@ -687,7 +687,7 @@ Pseudocode for SetLossDetectionAlarm follows:
alarm_duration = alarm_duration * (2 ^ handshake_count)
else if (loss_time != 0):

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is also weird, it's possible that loss_time is greater than tlp timer or RTO, shouldn't we take the min(loss_time, rto_timer, tlp_timer) as the early retransmit timer, or at least min(loss_time, rto)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont think this is an issue. This is at the beginning of the connection, and loss_time only applies to early retransmit. It's possible that loss_time is > TLP or RTO period, but that would be very very strange.

@@ -701,7 +701,8 @@ Pseudocode for SetLossDetectionAlarm follows:
alarm_duration = max(alarm_duration, kMinRTOTimeout)
alarm_duration = alarm_duration * (2 ^ rto_count)

loss_detection_alarm.set(now + alarm_duration)
loss_detection_alarm.set(time_of_last_sent_packet

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for handshake packets should this be the time since the last handshake packet was transmitted?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point, given the other packets are not decryptable, and hence will not generate an acknowledgement until the handshake completes, #962 filed.

@siyengar
Copy link

github won't let me comment on the particular line of code, however

in detect loss packets the delay until lost is also wrong, it should be

1/8 * max(srtt, lrtt) vs 9/8 -> or maybe it should be 1 /4 because we should at least wait for a 1/4 rtt
and it should be timereordering vs 1 + timereordering.

@@ -687,7 +687,7 @@ Pseudocode for SetLossDetectionAlarm follows:
alarm_duration = alarm_duration * (2 ^ handshake_count)
else if (loss_time != 0):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont think this is an issue. This is at the beginning of the connection, and loss_time only applies to early retransmit. It's possible that loss_time is > TLP or RTO period, but that would be very very strange.

@janaiyengar janaiyengar merged commit 91b0dbe into master Nov 30, 2017
@MikeBishop MikeBishop deleted the ianswett-setlossdetection branch January 21, 2018 04:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants