On Fri, 9 Oct 2015, Joe Touch wrote:
On 10/9/2015 10:58 PM, David Lang wrote:
RFC3449 doesn't completely address the current situation, but it
provides a very good place to start, and it seems to me that the
solitions it explores to address the conerns that it (and you) raise are
actually being addressed pretty completely. There are still some areas
to talk about (ECN interaction for example) and we wshould be talking
about those issues rather than arguing that the proposal violates holy
writ.
I'm OK with the recommendations for the endpoints to modify their ACK
behavior, but still am concerned that stripping out ACKs in the middle
of the network is problematic for a number of reasons, only some of
which are addressed in RFC3449 (which also recommends against deploying
them in the general Internet, so if that's your justification then it's
very clearly in direct opposition).
Remember that this can only take place when there is enough of a bottleneck that
enough of a queue has built up that multiple ack packets are sitting in the
queue waiting to be transmitted. Such a queue is only going to build up if the
link is a bottleneck [1]. As I undertsand the current Industry Best Practice,
unless you have ISPs deliberatly not upgrading (ala the Netflix fights), the
core systems almost never queue and so such algorithms would never kick in.
So even if I could wave a magic wand and deploy this on every router, it would
only have an effect in a few places. Endpoint links where the available
bandwidth drastically changes are not the exclusive list of palces that this
would effect, but I think it's pretty close.
David Lang
[1] the exception to this is when you have a hop where the transport quanomizes
the data the way Wifi and Cell networks do, So if you have a half-duplex link
like normal Wifi or a time-slot MAC like a Cell network in the middle of the
path, this sort of thing could trigger there, but I'm not convinced that it
would be a bad thing there. Full duplex Wifi links that can transmit
continuously don't need this
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
