Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-13.txt - ACK Thining

[Gorry Fairhurst <[e-mail]>]

I see this rev introduced a section on ACK Filtering, which I have 
specific comments on. We need to consider the cost of sending ACKs - 
especially anything that results in them being large - however, this 
needs to be done by choosing a default at the receiver - not as an 
adaptation, the adaption if necessary needs to be introduce more ACKs 
when this is beneficial, as in some cases for DAAS, not in trying to 
figure something from delayed or "missing" ACKs.

1) So let me say first that I think the suggestion for updating the 
receiver to thin, and every 2-6 packets seems reasonable.

     “MUST immediately send an ACK once 'n' CE marks have arrived since
       the previous ACK, where 'n' SHOULD be 2 and MUST be no greater
       than 6.”

I do agree that endpoints can do much more to reduce the return path 
capacity that they consume - and that the endpoints have the opportunity 
to encode the feedback information more efficiently than can be done by 
a device (or queue) in the network. From our experiments, n=10 would 
also often be likely OK.

2. Althouigh in some cases a receiver can predict a good "n", I do not 
believe a receiver can typically find out how to choose “n” by observing 
the ACKs on a connection.

Sure, if the path is modelled as a simple bit-congestive path that has a 
queue, then you could monitoring timing/loss of packets and determine a 
rate that tries not to fill a queue. I would not know how common such a 
bottleneck link is.

I do know that many bottleneck links are much more complex and need to 
consider the scheduling transmission of small ACK packets on the return 
path performance. In many radio technologies, the overhead from 
transmission of ACKs is proportionally much higher than for data 
segments. These layer 2s are often constrained in terms of packets (e.g. 
where lower layer framing and transmission scheduling is an important 
consideration to the efficiency/cost of using the service). This has 
often been “fixed” using ACK Thinning or PEPs. Protocols that send fewer 
ACKs/data packet are not impacted.


2. I do not believe a receiver can find out how top to choose “n” by 
observing the ACKs received on a connection.

Sure, if the path is modelled as a simple bit-congestive path that has a 
queue, then you could monitoring timing/loss of packets and determine a 
rate that tries not to fill a queue. I would not know how common such a 
bottleneck link is.

I do know that many bottleneck links are more complex and needs to 
consider the scheduling transmission of small ACK packets on the return 
path performance. In many radio technologies, the overhead from 
transmission of ACKs is proportionally much higher than for data 
segments -  These layer 2s are constrained in terms of packets (e.g. 
where lower layer framing and transmission scheduling is an important 
consideration to the efficiency/cost of using the service). This has 
often been “fixed” using ACK Thinning or PEPs. Protocols that send fewer 
ACKs/data packet are not impacted.

Scheduling (at the IP layer,can also often result in variations in 
timing - something that is hard to predict and I would suggests make 
automated selection of “n” very hard, and the need to thin is often not 
directly visible to a user of the path. Traffic multiplexed with 
protocols that use different ACK policies (perhaps QUIC?) also make this 
sort of detection less reliable.

3) A queue might be competing for scheduling opportunities against other 
IP flows (e.g., WFQ), or competing for transmission opportunities with a 
shared resource (common in radio links).

ACKs can and do take transmission opportunities away from the resource 
pools that would be used by other services that share the same resource 
pool. This can be reduced by some form of per-flow scheduling with 
deeper per-flow queues - but that in itself can induce unwanted coupling 
between flows - limiting the peak rate of one flow, to achieve a higher 
ACK ratio for another flow.

Consider a QUIC flow sharing a return path with a TCP flow, the higher 
rate of larger QUIC ACKs reduces the transmission opportunities for TCP 
ACKs, which in turn suppresses the TCP flow, limiting the overall system 
performance. If the ACKs use the same transmission resource, they could 
take directly away from transmission opportunities in the forward 
direction, but even if they do not - the rate of ACKs retuned impacts 
the sending rate end to end.

4) The new section adds some cross-layer requirements on sub-IP layers, 
which seem to imply more complexity. I’m not comfortable with such a 
proposal.

It seems that the text suggests not implement thinning and that these 
systems implement logic to detect the presence of the option by 
observing SYNs and then configure the link to do something special. I 
don’t think think this is the correct approach - the result will be 
throttling of the connection speed. Is it necessary that the sub-IP 
layer does not implement thinning for connections that use AccECN feedback?

When the text says: “SHOULD preserve the timing of each ACK”
- does that imply that nodes need to discard rather than delay packets 
when link scheduling or transmission scheduling is used. This seems a 
very odd requirement, it might be better too simply strip-out the AccECN 
option or discard all packets that set this.

I can’t see how queuing the ACKs, or deleting ACKs rather than queuing 
them would improve the performance of AccECN TCP connections.

Gorry