Re: [tcpm] comments on draft-li-tcpm-advancing-ack-for-wireless

[Rahul Arvind Jadhav <[e-mail]>]

Hi Yoshi,

Thanks for the feedback. Please find the response [RJ] inline.

Best,
Rahul

From: tcpm [mailto:[e-mail]] On Behalf Of Yoshifumi Nishida
Sent: 28 April 2020 16:40
To: [e-mail] Extensions <[e-mail]>
Subject: [tcpm] comments on draft-li-tcpm-advancing-ack-for-wireless

Hello,
I've read the draft. I basically agree with the motivation of the draft although I have several comments.
My general question is how to implement this. So, I'm wondering the following points.

1: Is this receiver only logic or do we need to negotiate between endpoints beforehand? Or, is it out-of-scope?

[RJ] Currently it is out-of-scope. We deployed this in context to a specific application assuming some settings on the sender/receiver side. Settings such as `beta` (section 3.2) which dictates how aggressive the ACKing should be was assumed to be 4 in our tests. This could be parameterized and will benefit especially the high BDP paths.

2: if this is receiver only logic, you might need to consider the case where sender doesn't use ABC.

[RJ] In context to ABC, we expect that the sender follows the cwnd increments to be done as specified in RFC 3465. Most of the implementations already do that. However, as compared to delayed ACKs this draft is much more aggressive in reducing the ACK traffic and as such the cwnd increments as specified in ABC is surely going to result in bigger bursts of packets. Usually this is a bad thing, but given our use-case (local Wi-Fi use-case) we found that larger bursts actually improved the efficiency of lower level Wi-Fi aggregation. Not considering ABC on sender side has implications and we will try to address this (at-least state the implications clearly).

3: How does receiver check BW or RTTmin? 

[RJ] This is an interesting point. There is an impact on BW and RTTmin estimation on sender side especially with the likes of aggressive ACK reduction that the draft seeks. In the absence of continuous ACK feedback, we propose that the receiver aids the sender's RTTmin estimation (and in turn BW estimation) by sending explicit OWD (one-way delay) measurements. We understand that this works only for near-symmetric links, but we think it would be possible to generalize further and alleviate the risk of inaccurate RTTmin estimation. We plan to update this part in the next revision (Section 4.2 in https://tools.ietf.org/html/draft-li-quic-optimizing-ack-in-wlan-00 in QUIC WG has more details).