> On 17 Mar, 2019, at 12:25 am, Holland, Jake wrote:
>
> I do think that to capture the value here, the SCE rate probably has to
> get back to sender, but I think there's good options for doing so, and
> anywhere it doesn't work, (I think?) it just falls back to regular CE,
> which is a nice bonu
David Lang wrote:
> if there is no resouce contention, they should be equal.
> In practice, since the network devices are more likely to run into
resource
> contention (think locking overhead between cores if nothing else), it can
> easily be faster to sort them at the destinati
Hi guys,
I was looking through the updates on SCE, and I think this
receiver-driven idea is doomed. I mean, good luck and it's a neat idea
if it works, but it's got some problems with flexibility:
- you don't want to reduce right edge of window, so you can't reduce
rwnd faster than data is arri
> On Mar 16, 2019, at 22:38, Holland, Jake wrote:
>
> On 2019-03-15, 11:37, "Mikael Abrahamsson" wrote:
>L4S has a much better possibility of actually getting deployment into the
>wider Internet packet-moving equipment than anything being talked about
>here. Same with PIE as oppo
Yeah, great question.
I don't want to answer for the L4S guys, I don't have a good feel for
what they might think. But it does concern me that there seems to be at
least one tuning parameter that was picked for Reno, which I think I
mentioned on the tsvwg list:
https://tools.ietf.org/html/draft-i
> On 16 Mar, 2019, at 11:38 pm, Holland, Jake wrote:
>
> SCE needs a lot of details filled in, but it's so much cleaner that it
> seems to me there's reasonably obvious answers to all (or almost all) of
> those detail questions, and because the semantics are so much cleaner,
> it's much easier to
Dear Vint:
BBR, along with all "non ect_1 sending L4S compatable" transports,
gets relegated to the dualpi "Classic" queue.
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-aqm-dualq-coupled/
On Sat, Mar 16, 2019 at 2:57 PM Vint Cerf wrote:
>
> where does BBR fit into all this?
>
> v
>
>
> On
On 2019-03-15, 11:37, "Mikael Abrahamsson" wrote:
L4S has a much better possibility of actually getting deployment into the
wider Internet packet-moving equipment than anything being talked about
here. Same with PIE as opposed to FQ_CODEL. I know it's might not be as
good, but i
The DSCP code points were also supposed to be local to the AS.
They are *supposed* to be recoded at the edges.
What is missing the diffedge protocol... MS actually implemented this in Win2K.
We have no way to signal the ToS we desire with the ISP, and so they are
forced to guess, and they do it w
Thanks Nils, I’d seen that PolicyPlus tool before, and while a nice stand-alone
option for any Windows version, it is still a tool for admins. I think we need
something regular technical users can use to do things like ‘Make DropBox
traffic land in the bulk tin’.
Also, there is a good thread ab
You can use group policies on standalone clients, however the Local Group
Policy Editor is not available on the Windows Home editions (neither is domain
membership AFAIK), and so many people resort to applying the changes they
require directly to the registry.
There are also tools like Policy P
> On Mar 16, 2019, at 10:42, Michael Welzl wrote:
>
> Good question! …. on Windows in particular, I’d really like to know this too.
Well, as far as I can tell it is the group policy editor that is the
tool to assign DSCPs to applications, IMHO that is exactly the right place,
somewh
Good question! …. on Windows in particular, I’d really like to know this too.
The WebRTC Javascript API allows one to influence the DSCP, i.e. browsers
normally can do that. Whether that’s true for all OSes, I don’t know.
Cheers,
Michael
> On Mar 16, 2019, at 12:45 AM, David P. Reed wrote:
Hi Dave,
On March 16, 2019 12:43:58 AM GMT+01:00, "David P. Reed"
wrote:
>
>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
14 matches
Mail list logo
