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

[Gorry Fairhurst <[e-mail]>]

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.

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.
- 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?

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.”?

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.

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?

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?

Best wishes,

Gorry Fairhurst