On Fri, 9 Oct 2015, Joe Touch wrote:
Dave in particular wanted some specific reasons this is a bad idea as
presented. Here is my summary.
The rest of this discussion should happen on TCPM.
Joe
---
1) *you* shouldn't be using a mechanism that destroys information for others
whether the timestamps or ACK stream spacing has any
meaning is for the receiver - not you - to decide
The temporal spacing is already lost.
2) *you* don't know where your mechanism will have an impact
those clumped ACKs might be spaced out further
downstream
even if you have a rule of "I'll only gather 3 ACKs",
you can't know if another box - including yours -
downstream might gather those composite ACKs further
3) you claim this might be safe *if* AQM is widely deployed
but *you* don't appear to be making that determination
*before* deploying your approach
also, AQM is in the opposite direction, and unless
you deploy this with enough state to track the fact
that your box is seeing traffic in both directions,
you shouldn't be turning it on at all
this discussion started in the context of AQM. AQM is needed in both directions,
it's not a one-direction only thing.
As others have noted, the SHOULD of ACK requirements can be exceeded,
but only with careful consideration of the potential impact. That
careful consideration does not consist of "I turned it on and I didn't
hear anyone scream".
that's not the only consideration here. There's also the consideration that the
ACK stream is already badly distorted.
As it turns out (as discussed on the other thread), the RFC actually recommends
what we was proposed (with some additional nuances)
David Lang
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
