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.
___
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
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
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
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
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
>
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
> >
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
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
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
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:
>
13 matches
Mail list logo