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

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

What I meant with "new mechanism, yet to be specified" is that
we could, at some point, decide to specify an ACK congestion
control mechanism which would, under controlled conditions,
reduce the ACK rate, and override this MUST with something
else (i.e. update RFC 2581bis) - but since such a mechanism
does not (yet) exist, 2581bis isn't the right place for this.

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

It wouldn't rule this out from future RFCs on TCP, and TCP
implementations that are based on them. It merely rules it
out of future TCP implementations (and here, I would argue
that a larger step is needed for proper ACK congestion
control than the flexibility that is granted by the SHOULD
in RFC 2581).

Cheers,
Michael

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