{"action":"created","issue":{"url":"https://api.github.com/repos/quicwg/base-drafts/issues/961","repository_url":"https://api.github.com/repos/quicwg/base-drafts","labels_url":"https://api.github.com/repos/quicwg/base-drafts/issues/961/labels{/name}","comments_url":"https://api.github.com/repos/quicwg/base-drafts/issues/961/comments","events_url":"https://api.github.com/repos/quicwg/base-drafts/issues/961/events","html_url":"https://github.com/quicwg/base-drafts/issues/961","id":277307346,"number":961,"title":"Ack delay in SRTT computation","user":{"login":"janaiyengar","id":11067604,"avatar_url":"https://avatars2.githubusercontent.com/u/11067604?v=4","gravatar_id":"","url":"https://api.github.com/users/janaiyengar","html_url":"https://github.com/janaiyengar","followers_url":"https://api.github.com/users/janaiyengar/followers","following_url":"https://api.github.com/users/janaiyengar/following{/other_user}","gists_url":"https://api.github.com/users/janaiyengar/gists{/gist_id}","starred_url":"https://api.github.com/users/janaiyengar/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/janaiyengar/subscriptions","organizations_url":"https://api.github.com/users/janaiyengar/orgs","repos_url":"https://api.github.com/users/janaiyengar/repos","events_url":"https://api.github.com/users/janaiyengar/events{/privacy}","received_events_url":"https://api.github.com/users/janaiyengar/received_events","type":"User","site_admin":false},"labels":[{"id":481873040,"url":"https://api.github.com/repos/quicwg/base-drafts/labels/-recovery","name":"-recovery","color":"fbca04","default":false}],"state":"open","locked":false,"assignee":{"login":"janaiyengar","id":11067604,"avatar_url":"https://avatars2.githubusercontent.com/u/11067604?v=4","gravatar_id":"","url":"https://api.github.com/users/janaiyengar","html_url":"https://github.com/janaiyengar","followers_url":"https://api.github.com/users/janaiyengar/followers","following_url":"https://api.github.com/users/janaiyengar/following{/other_user}","gists_url":"https://api.github.com/users/janaiyengar/gists{/gist_id}","starred_url":"https://api.github.com/users/janaiyengar/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/janaiyengar/subscriptions","organizations_url":"https://api.github.com/users/janaiyengar/orgs","repos_url":"https://api.github.com/users/janaiyengar/repos","events_url":"https://api.github.com/users/janaiyengar/events{/privacy}","received_events_url":"https://api.github.com/users/janaiyengar/received_events","type":"User","site_admin":false},"assignees":[{"login":"janaiyengar","id":11067604,"avatar_url":"https://avatars2.githubusercontent.com/u/11067604?v=4","gravatar_id":"","url":"https://api.github.com/users/janaiyengar","html_url":"https://github.com/janaiyengar","followers_url":"https://api.github.com/users/janaiyengar/followers","following_url":"https://api.github.com/users/janaiyengar/following{/other_user}","gists_url":"https://api.github.com/users/janaiyengar/gists{/gist_id}","starred_url":"https://api.github.com/users/janaiyengar/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/janaiyengar/subscriptions","organizations_url":"https://api.github.com/users/janaiyengar/orgs","repos_url":"https://api.github.com/users/janaiyengar/repos","events_url":"https://api.github.com/users/janaiyengar/events{/privacy}","received_events_url":"https://api.github.com/users/janaiyengar/received_events","type":"User","site_admin":false}],"milestone":null,"comments":0,"created_at":"2017-11-28T09:08:44Z","updated_at":"2017-11-28T13:34:25Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"The recovery draft (and GQUIC) use ack delay in SRTT computations, but with the caveat that \"the ack delay field from the ACK frame SHOULD be subtracted from the RTT as long as the result is positive.\" \r\n\r\nThe ack delay may be too large if the peer's clock was adjusted, but it can also happen if the peer uses a very granular clock, which can lead to arbitrarily large ack delays.\r\n\r\nThere are a few ways to deal with this, including:\r\n1. current text, which simply drops the problematic ack delays,\r\n2. ignore ack delays from a peer that screws up once (ack delay > measured RTT),\r\n3. ignore RTT sample that contains problematic ack delay.\r\n\r\n(1) is a bit aggressive. (2) is conservative: If ack delay is screwed up then you won't always be able to detect it, but once can be treated as a signal to not trust this peer's ack delays. (3) has been proposed but I'm not sure it addresses the right thing -- the RTT sample isn't bad, the ack delay is.\r\n\r\nI'm leaning towards (2)."},"comment":{"url":"https://api.github.com/repos/quicwg/base-drafts/issues/comments/347524701","html_url":"https://github.com/quicwg/base-drafts/issues/961#issuecomment-347524701","issue_url":"https://api.github.com/repos/quicwg/base-drafts/issues/961","id":347524701,"user":{"login":"ianswett","id":20072817,"avatar_url":"https://avatars1.githubusercontent.com/u/20072817?v=4","gravatar_id":"","url":"https://api.github.com/users/ianswett","html_url":"https://github.com/ianswett","followers_url":"https://api.github.com/users/ianswett/followers","following_url":"https://api.github.com/users/ianswett/following{/other_user}","gists_url":"https://api.github.com/users/ianswett/gists{/gist_id}","starred_url":"https://api.github.com/users/ianswett/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ianswett/subscriptions","organizations_url":"https://api.github.com/users/ianswett/orgs","repos_url":"https://api.github.com/users/ianswett/repos","events_url":"https://api.github.com/users/ianswett/events{/privacy}","received_events_url":"https://api.github.com/users/ianswett/received_events","type":"User","site_admin":false},"created_at":"2017-11-28T13:34:25Z","updated_at":"2017-11-28T13:34:25Z","author_association":"CONTRIBUTOR","body":"If your first theory is correct, this is due to clock jump, then 2 seems like the wrong approach, since it means one bad ack delay is likely to be isolated.\r\n\r\n4. An improvement to #1 might be to ignore the ack delay any time the resulting RTT is less than min_rtt.  We'd have to define min_rtt, which we currently don't, but that puts a tighter bound on reasonable use of ack delay than just 'must result in a positive RTT signal'.  This makes it much harder to intentionally use the ack delay to manipulate the peer's SRTT, which seems nice.\r\n\r\nSo I lean towards 4 and I think my least favorite is 4, the more I think about it, because I fear going a long time without an RTT sample, and the goal should be to never be worse than TCP's RTT signaling."}}
{"actor":{"display_login":"ianswett"}}