On Fri, Mar 15, 2019 at 9:04 PM Jonathan Morton wrote:
>
> > On 15 Mar, 2019, at 7:01 pm, David P. Reed wrote:
> >
> > > Next up for sce was going to be to find if dctcp could be modified to
> > > use it. Also, bittorrent.
> >
> > YES! I endorse this message.
>
> Actually, today I was still
> On 15 Mar, 2019, at 7:01 pm, David P. Reed wrote:
>
> > Next up for sce was going to be to find if dctcp could be modified to
> > use it. Also, bittorrent.
>
> YES! I endorse this message.
Actually, today I was still figuring out how to fit it to CUBIC. I *think*
I've succeeded…
> On 16 Mar, 2019, at 1:43 am, David P. Reed wrote:
>
> Now the other thing that is crucial is that the optimal state almost all of
> the time of every link in the network is that a utilization far from max
> capacity. The reason for this is the fact that the Internet (like almost all
>
How many applications used by normal users have "admin" privileges? The
Browser? Email? FTP?
-Original Message-
From: "Dave Taht"
Sent: Friday, March 15, 2019 4:31pm
To: "Jonathan Foulkes"
Cc: ecn-s...@lists.bufferbloat.net, "bloat"
Subject: Re: [Ecn-sane] [Bloat] [iccrg] Fwd:
My point is that the argument for doing such balancing is that somehow ISPs at
the entry points (representing somehow the goals of source and destination of
each flow) will classify their flows correctly based on some criterion, and not
select the option that allows them to "beat" all the
Hi, Dave, strangely it looks like nobody has been copying TSVWG on this
thread, even though that is where the L4S work is happening in the IETF! :)
I just wanted to respond to one part of your message since I am
currently acting as document shepherd for the L4S drafts in TSVWG, and
it seems
On Fri, Mar 15, 2019 at 1:28 PM Jonathan Foulkes
wrote:
>
> All this discussion of DSCP marking brings to mind what happened on the
> Windows platform, where the OS had to suppress ALL DSCP marks, as app authors
> were trying to game the system.
> And even if not trying to ‘game’ it, they have
All this discussion of DSCP marking brings to mind what happened on the Windows
platform, where the OS had to suppress ALL DSCP marks, as app authors were
trying to game the system.
And even if not trying to ‘game’ it, they have non-obvious reasons why they
don’t mark traffic how one would
> On 15 Mar, 2019, at 9:44 pm, David P. Reed wrote:
>
> pricing (even dynamic pricing) of different qualities of service is unstable
An interesting result, but I should note that the four-way optimisation system
I described doesn't rely on pricing, only a sufficiently correct implementation
Just to throw in one more thing not well understood by engineers.
Economists I have discussed this with (real ones, not fringe right-wing true
believers that the market "just works"), have observed that pricing (even
dynamic pricing) of different qualities of service is unstable and extremely
> On 15 Mar, 2019, at 8:36 pm, Mikael Abrahamsson wrote:
>
> Having a "lower-than-best-effort" diffserve codepoint might work, because it
> means worse treatment, not preferential treatment.
>
> The problem with having DSCP CPs that indicate preferential treatment is
> typically a ddos
Hi Mikael,
> On Mar 15, 2019, at 19:36, Mikael Abrahamsson wrote:
>
> On Fri, 15 Mar 2019, David P. Reed wrote:
>
>> So if the responsible network engineers in the carriers cannot agree on
>> anything, IETF is wasting its time.
>
> The IETF has already said that anything diffserv is
On Fri, 15 Mar 2019, David P. Reed wrote:
So if the responsible network engineers in the carriers cannot agree on
anything, IETF is wasting its time.
The IETF has already said that anything diffserv is domain-internal only.
I have joined the effort of the LE PHB and see if we can get some
On Fri, 15 Mar 2019, Dave Taht wrote:
It appears, also, ironically, (I have confirmation from several sources
now) that cake, fq_codel and dualpi are now illegal for an ISP to use in
their provided equipment under california law. The idea of one day
having to appear in court to defend our key
On March 15, 2019 6:01:23 PM GMT+01:00, "David P. Reed"
wrote:
>
>The absolute fundamental issue with diffserv, IMO, is that the carriers
>cannot agree on an actual specification of what routers and gateways
>are supposed to do, while being compatible with the core principle of
>the IP layer:
The absolute fundamental issue with diffserv, IMO, is that the carriers cannot
agree on an actual specification of what routers and gateways are supposed to
do, while being compatible with the core principle of the IP layer: do not hold
packets if they cause increasing queueing delay. (this is
Hi Dave,
> On Mar 15, 2019, at 15:06, Dave Taht wrote:
>
> I would really prefer to move this discussion to the ecn-sane mailing
> list, as IMHO, ecn is generally such a tiny thing needed for good
> congestion control compared to better transports like pacing + bbr,
> and things like bql, fq,
> On 15 Mar, 2019, at 4:44 pm, Sebastian Moeller wrote:
>
> In essence, they do not want to deal with the diffserv mess under the
> end-to-end perspective and making it reliable.
Yeah, that's pretty much what I thought. Diffserv really does need to be fixed
sometime.
>> But Codel-type AQMs
Hi Jonathan,
> On Mar 15, 2019, at 15:27, Jonathan Morton wrote:
>
>> On 15 Mar, 2019, at 3:01 pm, Sebastian Moeller wrote:
>>
>> That said, having read through the L4S architecture description and the
>> related appendices of draft-ietf-tsvwg-ecn-l4s-id-05 I came to the
>> conclusion,
> On 15 Mar, 2019, at 3:01 pm, Sebastian Moeller wrote:
>
> That said, having read through the L4S architecture description and the
> related appendices of draft-ietf-tsvwg-ecn-l4s-id-05 I came to the
> conclusion, that this is a mess.
>
> The L4S project proposes a really wide-ranging change
I would really prefer to move this discussion to the ecn-sane mailing
list, as IMHO, ecn is generally such a tiny thing needed for good
congestion control compared to better transports like pacing + bbr,
and things like bql, fq, and aqm using drop.
I'm going to keep cc-ing that list in the hope
Hi Dave,
I pruned the CC list as I am out of my league here and want to restrict the
radius of my embarrassment to those that already know my level of incompetence
before hand.
That said, having read through the L4S architecture description and the related
appendices of
Bufferbloat.net's ecn-sane working group members have a co-ordinated
response to your efforts brewing but it's not ready yet. We have a
worldwide team of linux and freebsd developers co-ordinating on landing
code for our competing proposal "Some Congestion Experienced", which we
submitted to tsvwg
23 matches
Mail list logo
