On Wed, 7 Oct 2015, Jonathan Morton wrote:
On 7 Oct, 2015, at 20:36, David Collier-Brown <[email protected]> wrote:
On 07/10/15 01:19 PM, David Lang wrote:
On Wed, 7 Oct 2015, Mikael Abrahamsson wrote:
Oh, I hope that this is an exception. Such kind of optimizations may cause
a lot of trouble since a link layer device is interfering with transport
layer semantics. We all know that exactly these kinds of interference
eventually end up in problems with end-to-end transparency and deployment
of new protocol options. At least it interferes with the ACK clocking
expectation of some congestion control algorithms...
Personally, I think you're going to see more and more of this. There are
mulitple shared access medium where you're allowed to send only part of the
time, and it's someone else who tells you when you may send.
it doesn't even require that someone else tells you when you may send. It
can just be waiting for an available transmit timeslot (Wifi for example)
collapsing multiple ACKs that are going to be sent at once is almost always
going to be a win.
I quite agree, but if there is a congestion control implementation "in the
wild" that assumes it will get a stream of acks, that one's going to need
some work (:-))
Anyone know if that's the case? The comment above suggest it may be...
It’s not “in the wild”, but this sort of thing is a headache for ELR. It
essentially means that it won’t be able to use AccECN for its feedback (since
AccECN doesn’t allow reconstructing a complex 32-packet history of ECN
codepoints from a single ACK), but must introduce some other mechanism to feed
back the required data to the sender.
but if you are getting all 32 acks at the same time, with no other packets
flowing, are you going to be able to do anything sane? do you mark every one of
the acks with ECN (sending a super-strong backoff message), or only mark one of
the acks (sending a weak backoff message)
David Lang
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
