On 01/12/17 01:28, David Lang wrote:
> Stop thinking in terms of single-flow benchmarks and near idle
> 'upstream' paths.
Nobody has said it so I will: on wifi-connected endpoints the upstream
acks also compete for airtime with the downstream flow.
___
B
35K PPS of acks is insane, one ack every ms is FAR more than enough to do 'fast
recovery', and outside the datacenter, one ack per 10ms is probably more than
enough.
Assuming something that's not too assymetric, thinning out the acks may not make
any difference in the transfer rate of a single
Cake already supports treating CS1 as less-than-besteffort by default.
Adding more codepoints to that list is easy.
The trick is getting applications to actually use them. That's a
chicken-egg problem.
- Jonathan Morton
___
Bloat mailing list
Bloat@lis
On Thu, 30 Nov 2017, Jonathan Morton wrote:
I submit that to provide *deployable* QoS schemes, you must either solve
the classification problem elegantly (which is a Hard Problem), or else
show that your scheme works adequately in the absence of classification.
I'm taking the latter approach w
A central assumption in all of your references so far is that the relevant
traffic classes can be distinguished reliably in realtime and sent to
appropriate queues. There is no fallback mechanism given for any cases
where this assumption is false - the queue within each class is a FIFO,
which as e
On Thu, Nov 30, 2017 at 10:55 AM, Eric Dumazet
wrote:
> On Thu, 2017-11-30 at 09:51 -0500, Neal Cardwell wrote:
> > On Thu, Nov 30, 2017 at 5:24 AM, Eric Dumazet > > wrote:
> > > I agree that TCP itself should generate ACK smarter, on receivers
> > > that
> > > are lacking GRO. (TCP sends at mos
On Thu, 2017-11-30 at 09:51 -0500, Neal Cardwell wrote:
> On Thu, Nov 30, 2017 at 5:24 AM, Eric Dumazet > wrote:
> > I agree that TCP itself should generate ACK smarter, on receivers
> > that
> > are lacking GRO. (TCP sends at most one ACK per GRO packets, that
> > is
> > why we did not feel an ur
On Thu, 2017-11-30 at 14:04 +0100, Mikael Abrahamsson wrote:
> On Thu, 30 Nov 2017, Eric Dumazet wrote:
>
> > I agree that TCP itself should generate ACK smarter, on receivers
> > that
> > are lacking GRO. (TCP sends at most one ACK per GRO packets, that
> > is why
> > we did not feel an urgent
On Thu, Nov 30, 2017 at 5:24 AM, Eric Dumazet
wrote:
> I agree that TCP itself should generate ACK smarter, on receivers that
> are lacking GRO. (TCP sends at most one ACK per GRO packets, that is
> why we did not feel an urgent need for better ACK generation)
>
> It is actually difficult task, b
On Thu, 30 Nov 2017, Eric Dumazet wrote:
I agree that TCP itself should generate ACK smarter, on receivers that
are lacking GRO. (TCP sends at most one ACK per GRO packets, that is why
we did not feel an urgent need for better ACK generation)
Could you elaborate a bit more on the practical im
The key design goal was to create assured bounds on loss and delay for
designated classes during extended periods of load saturation.
The mechanisms, to some extent, are not the issue - the ability configure it
and know a-prori (to a given error bound) what would happen to the traffic
flows was
I agree that TCP itself should generate ACK smarter, on receivers that
are lacking GRO. (TCP sends at most one ACK per GRO packets, that is
why we did not feel an urgent need for better ACK generation)
It is actually difficult task, because it might need an additional
timer, and we were reluctant
Agree and think this is a lucid analysis of the problem(s) and solution(s).
But, what can be done to let clients upgrade orders of magnitude faster
than today?
Move transport in user space inside the app? Else?
On Thu, Nov 30, 2017 at 8:48 AM, Jonathan Morton
wrote:
> I do see your arguments
13 matches
Mail list logo