On Fri, 9 Oct 2015, Joe Touch wrote:
On 10/9/2015 11:52 AM, David Lang wrote:
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.
You don't know that won't be restored downstream.
it can only be restored by further delaying the arrival of the ACKs (you can't
send an 'fixed' ACK before you receive the one that was delayed (I'm trying to
avoid the phrase 'Delayed ACK' to avoid confusion)
This will have further detrimental effects on your throughput.
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.
Needed, but you don't *know* it's deployed on both path directions. The
reverse path could be taking a different route.
AQM is needed on any bottleneck link. If the link isn't a bottleneck, the data
rate isn't too high.
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.
It's not distorted at all - it's queued up and waiting its turn.
the temporal spacing of the ACKs is lost. They won't be sent out at spaced
intervals, they will be sent out in a burst at line speed (whatever that is).
As it turns out (as discussed on the other thread), the RFC actually
recommends what we was proposed (with some additional nuances)
Assuming that you know what you can't know and assuming that you don't
care whether your actions affect what others have a right to assume.
Actually, the router does know that the ACK stream is being quantitized. It's
doing the quatitization (wifi aggregation, DOCSIS on cable, satellite transmit
slots, LTO Cell networks, or AQM queue selection)
What it can't know is if anything else would try to slow traffic further by
trying to delay ACKs more to restore spacing (RFC3449 talks about the problems
of doing this and recommends against it).
So the only thing remaining is what assumptions other things have the right to
make. Given how common wireless (Wifi and Cell) networks are, anything that
makes an assumption that ACKs are flowing back as the traditional wired networks
handled them is broken today.
If some RFC needs to be updated to make everyone recognize this, then the RFC
needs to be updated.
But people actually working with servers and the real Internet are seeing these
effects today.
David Lang
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
