I agree with you Jim about being careful with QoS. That's why Andrew Odlyzko
proposed the experiment with exactly two classes, and proposed it as an
*experiment*. So many researchers and IETF members seem to think we should just
turn on diffserv and everything will work great... I've seen very
On Fri, May 16, 2014 at 10:52 AM, wrote:
> On Thu, 15 May 2014 16:32:55 -0400, dpr...@reed.com said:
>
> > And in the end of the day, the problem is congestion, which is very
> > non-linear. There is almost no congestion at almost all places in the
> Internet
> > at any particular time. You can
I'll answer this way... The endpoints can use information to slow down as early
as possible. That's the whole point of control loop tuning. The fundamental
resonance of a control loop depends on its speed of draining and filling the
storage element.
So you want to sample and deliver ASAP two th
Hi,
I completely agree that this service differentiation was wrong from the
beginning. The idea of using bits to implement a trade-off that doesn't involve
prioritization between users is old (*), and has always been the right approach
in my opinion.
At least one proposal in this direction is
Well, if the link isn't congested, why do you need to do anything to the traffic
other than forward it? You have no way of knowing what paths the traffic is
going to follow once it hits the next router, so you don't know which streams
are independent of each other.
Now, if you are saying that
Both you and Dave Taft misunderstood my idea about standing queues not being
the right way to encode congestion in switches. I do not say there would be no
buffers for jitter. Nor do I call for admission control. I just suggest that
instead of deriving congestion from backlog measures (requiring
We are talking about different things then.
The "fast lane" I'm talking about is where ISPs want companies to pay them for
bandwidth (in addition to the companies paying their own ISP for bandwidth and
in addition to their users paying them for bandwidth)
As for your contention that an ideal
On Thu, May 15, 2014 at 6:01 PM, wrote:
> I don't think that at all. I suspect you know that. But if I confused you,
> let me assure you that my view of the proper operating point of the Internet
> as a whole is that the expected buffer queue on any switch anywhere in the
> Internet is < 1 datagr
I don't think that at all. I suspect you know that. But if I confused you, let
me assure you that my view of the proper operating point of the Internet as a
whole is that the expected buffer queue on any switch anywhere in the Internet
is < 1 datagram.
fq_codel is a good start, but it still r
If you think "fast lanes" will actually increase performance for any traffic,
you are dreaming.
the people looking for "fast lanes" are't trying to get traffic through any
faster, they are looking to charge more for the traffic they are already
passing.
David Lang
On Thu, 15 May 2014, dpr.
There is, I think, one good way to make Diffserv actually work. It does
require several steps in tandem.
Step one is to accept and admit that differential pricing based on scarcity
economics does not work on the internet. That's going to be tough to
swallow for the big commercial players.
Step tw
diffserv is not evil. However, there has never been a practical mechanism for
defining the meaning of the different "levels of service" across vendors and
Autonomous Systems.
The problem is that diffserv is framed as if there were a global "controller"
of the Internet who could impose a prec
Gosh, that's high praise. And what's really neat is that this was such a
team effort
where we don't even necessarily know each other! What's perhaps bad is that
this was a "volunteer" effort, though that also is a strength. I'm not
sure the
answer is for everyone to work for Google.
On 5/15/14 6:
dpr...@reed.com wrote
> Fixing buffer bloat allows the edge- and enterprise- networks to be more
> efficient,
> whereas not fixing it lets the edge networks move users up to more and more
> expensive "plans" due to frustration and to sell much more gear into
> Enterprises
> because they are eas
Well done. I'm optimistic for deployment everywhere, except CMTS's, the LTE
and HSPA+ access networks, and all corporate firewall and intranet gear.
The solution du jour is to leave bufferbloat in place, while using the real
fads: prioritization (diffserv once we have the "fast lanes" fully l
15 matches
Mail list logo
