Re: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00

Michael Welzl wrote:
>>> There's been some talk lately about reverse path congestion control. 
>>> (This would be much harder with TCP than DCCP, but maybe someone can 
>>> figure it out?)
>> By reverse path, you mean ACK congestion control? Data transfer can be
>> bi-directional.
> 
> Funny enough, I stumbled over this SHOULD when thinking about ACK
> congestion control, where it could be useful for the sender to be
> able to count the number of ACKs that the receiver would normally
> have to send during a loss period.
> 
> In any case, it's the concern of a new mechanism, yet to be specified,
> how to do ACK congestion control, and not the concern of RFC 2581 -
> using a SHOULD instead of a MUST for sending ACKs to out-of-order
> segments doesn't implement or even help ACK congestion control,
> but it actually seems to be a hindrance.

On the other hand, I don't know how you could possibly hope to do ACK 
congestion control when congestion on the forward path MUST cause you to 
suddenly double your rate of sending ACKs.

This also leads to another possible reason why you might want to 
continue delayed ACK during reordering/loss: on half-duplex links, 
especially wireless which may have a high per-packet cost, doubling your 
ACK rate in response to congestion actually makes the congestion worse.

I don't really want to get into defending specifics of any of these 
general ideas, but I'm just trying to say I wouldn't want to entirely 
rule out any of these ideas from future TCP, unless a strong case is 
made to do so.

   -John

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm