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

[Rahul Jadhav <[e-mail]>]

Thanks Gorry for the feedback and for providing the refs of work in the
context. Sorry for the late reply. It took me some time to get a handle on
the refs you provided.
Please find my [RJ] comments inline.

Best,
Rahul

On Wed, 29 Apr 2020 at 21:30, Gorry Fairhurst <[e-mail]> wrote:

>
> This email contains comments on comments on
> draft-li-tcpm-advancing-ack-for-wireless-00
>
> I think this draft touches on a specific topic, but I am unsure of the
> maturity of the current proposal with respect to the TCPM working group.
>
> I suggest you refer to RFC3449, it still contains a list of different
> in-network modifications to ACKs, which I think remain widely deployed
> in this type of network.
>

[RJ] RFC 3449 provides great ref points and it solidly sets the context.
However, it does not attempt to provide any solution space beyond the
constraints of TCP. Section 5 provides leads to enhancing TCP performance
using transparent modifications. I find that section 5 of RFC 3449 tries to
tackle issues such as Traffic burst, releasing CWND etc but it does not
look into the impact of RTT estimation because of ACK reduction.
Our attempt is different in the following ways:
a) Relook at protocol extensions to alleviating the impact of ACK
reduction. One example is alleviating the error in RTT estimation by using
protocol extensions and a one-way delay factor.
b) Not necessarily all the primitives can be applied generically and across
all apps. Don’t intend to be a generic solution but provide primitives for
specific scenarios.
c) Attempt for drastic ACK reduction (not just by a factor of 2x or 10x but
may be > 100x)
I agree that such a proposal may be beyond the scope of TCPM, but this may
be a good place to have this discussion.


>
> The draft says:
> “An upper bound of L can also be derived according
>     to the loss rate on the data path (plr_data) and the ack path
>     (plr_ack), i.e., L <= feedback_info/(plr_data*plr_ack), where
>     feedback_info denotes the amount of information carried by an ACK.”
> - which reads a little like the mechanisms in TCP NCR/ACK-CC/RFC4341. If
> L is computed from feedback loss information, it can not be set to
> appropriately compensate for radio resource cost - the ACK rate can grow
> to fill the available return  bottleneck capacity.
>

[RJ] RFC4341 was a refreshing read. Sections 6.1.x provide an explanation
about increasing/decreasing ACK ratio based on congestion feedback and that
is something to get inspired from. However (surprisingly) there is no
mention of any handling of side-effects resulting from ACK reduction in
this RFC. Also handling app-limited traffic is something that is not
considered by any of these designs (including ours). ACK-CC uses CCID-2
(RFC 4341) as the basis and explains the possible complications but also
does not give any indication of how to handle the impact. RTT estimation is
greatly impacted because of ACK reduction and either of these works does
not provide any possible solution towards this. We found that
rate-based/delay-based CC (especially BBR, Copa) has a big impact because
of this.
Btw, I am not sure if I understand what TCP NCR refers to? Can you please
provide a link? Thanks


> - In contrast, an L that is based on target asymmetry, e.g. L=10 does
> not have this drawback, although in our work we argue that this is also
> important for a large BDP.
>
> I agree the value beta = 4 is probably a suitable general update
> interval, but expect that my thoughts on this are based on sender pacing
> of the transmission. Have you thought about the pacing requirements of
> your method? It seems that mitigating bursts is going to be an important
> design for a stretch-ack proposal, but there are downsides to excessive
> pacing likely in a wireless case. Have you considering the implications
> of pacing?
>

[RJ] In our use-case, pacing was degrading the performance because of the
impact on wireless link-layer aggregation. What we tried is applying
rate-based pacing on a bunch/burst of data packets released on receiving an
ACK. We haven’t tried many experiments with pacing in general and it is an
important aspect to cover. I find that RFC 3449 provides a good context for
handling the pacing aspects.


>
> Once the cwnd, rwnd >> flow’s required BDP, the effect of L on the
> growth of cwnd becomes rather small. Of course there can be
> considerations also in the case of loss for thin flows, where the time
> to detect a tail loss would be increased by rtt/beta.
> What do you mean by:
> “Latency-sensitive transport usually has a small BDP,
>     in the case of application limitation, the latency of thin flows
>     might be enlarged due to a large L.”?
>

[RJ] This is a misleading statement. What we wanted to say is,
"Latency-sensitive flows (such as RPCs) and application-limited flows
having a relatively low-throughput suffer more from ACK-reduction as L
grows."

>
> When I read this, I did not understand how the two endpoints agreed on
> the input values that would be needed to perform the mitigation to ACK
> rate.
>

[RJ] There are set of TCP extensions on which it relies namely, to
handshake one-way-delay from (data) receiver and ACK rate (as defined in
ACK-CC). We haven’t talked about the extensions in the draft as of now.


>
> Changing the ACK frequency dynamically implies the need for signalling,
> and flows that change between application-limited and cwnd-limited would
> then need to be considered. Does anything need to be done to avoid
> oscillation in the ACK policy?
>

[RJ] Imo, avoiding oscillations is needed. Again RFC 4341 section 6.1.2
provides good handling (a function of RTT and configurable threshold) for
avoiding such oscillations and mostly I see that the same mechanism fits
generically for any dynamic ACK reduction mechanism.
Quoting verbatim:
"The sender need not keep Ack Ratio completely up to date.  For
   instance, it MAY rate-limit Ack Ratio renegotiations to once every
   four or five round-trip times, or to once every second or two.  The
   sender SHOULD NOT attempt to renegotiate the Ack Ratio more than once
   per round-trip time.  Additionally, it MAY enforce a minimum Ack
   Ratio of two, or it MAY set Ack Ratio to one for half-connections
   with persistent congestion windows of 1 or 2 packets."


>
> One last thing I am curious about is how your proposal will interact
> with methods such as ACK Thinning at the network layer, I’d hope there
> are only positive benefits when both schemes are used. Do you have
> experience of this?
>

[RJ] The ACK reduction impact handling primitives worked in favor of
alleviating the impact of ACK thinning either by transport or
network/link-layer. We do not have numbers showing the difference though.
It would have been nice to document these results.


>
> Best wishes,
>
> Gorry Fairhurst
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>