From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 2C70C3B2A4 for ; Wed, 19 Jun 2019 10:11:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=g1Pl9r4tmiP7nwsifsf205pPqpX4QHaQwJdmuFqx/1w=; b=k7Go+cR8XxtCXTx4gTyY0N6s1 A8EuNTOLFfkVH6DJZP+BvyYXYclcmOKrh4iWdT5kASQRxqTyahcg6SkhKUOYjwkELHCfXb7wOTTkX 6d+ZA5I1M8A4vpFxoJ6SwNDiz6S/7EdIfyrgydEBPqSF4vqr2wkgV06Ple3lNDxR7wuxFnqH9Y92+ ZqJ0DS24VQOmMKS+wMkKnF5FPzk6FdayZm1BWEI/eterswXJiOp6XBcFrFmAktH7kGnqcwJeyjHp7 0xqEZKh8Y/va980jNIpLywHrH4GgeoBcBgd1JWua7FlVBsSKPffeKqYu/YnEDXGYRqAv+T6CunvwE 6h7/xQ4UQ==; Received: from [31.185.128.20] (port=33006 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1hdbIy-0006x9-M3; Wed, 19 Jun 2019 15:11:17 +0100 To: "Holland, Jake" Cc: "tsvwg@ietf.org" , "ecn-sane@lists.bufferbloat.net" References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> From: Bob Briscoe Message-ID: <9d10caa9-2649-486e-525b-bfad4705b395@bobbriscoe.net> Date: Wed, 19 Jun 2019 15:11:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D7EB6D403A2629854DF943A0" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - lists.bufferbloat.net X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Subject: Re: [Ecn-sane] Comments on L4S drafts X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 14:11:19 -0000 This is a multi-part message in MIME format. --------------D7EB6D403A2629854DF943A0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Jake, On 14/06/2019 18:39, Holland, Jake wrote: > > Hi Bob, > > Thanks for your response, I think it helped clarify some important things > > for me. > > The point about starvation especially was a good one I hadn't fully > > considered, and I agree if SCE-based implementations can’t demonstrate a > > solution, that would be a major problem with the SCE approach for > signaling. > > And sorry for my slow response, I ended up restarting a few times to > try to > > dodge ratholes.  (Plus some day-job duties, apologies...) > > I found it a bit challenging to avoid the ratholes effectively, so I'm > > thinking maybe the right move is to set up a testbed.  Maybe playing with > > that (very cool-looking!) L4SDemo tool can either ease my concerns, or > > provide some more specific and detailed scenarios to address. > > I see that the source code is published now at > > https://github.com/L4STeam/l4sdemo (thanks Olivier!).  So I’ll try to > > bring that up at some point, time permitting, in hopes it makes the > > comments and questions more productive. > [BB] Cool. > One meta-point I wanted to make: > >   "In trying to find a compromise, you've taken the fire that is really > >   aimed at the inadequacy of underlying SCE protocol - for anything > >   other than FQ.  If the primary SCE proponents had attempted to > >   articulate a way to use SCE in a single queue or a dual queue, as you > >   have, that would have taken my fire." > > I think "fire" here is a potentially harmful metaphor--I don't take your > > comments as an attack or this discussion as a battle, but rather a > > collaborative attempt to reach a common goal of a better internet. > > I hope my comments on this are received the same way, even where we don't > > see eye to eye yet.  While both ideas can't be the best use of ECT(1) at > > the same time, I take this discussion as an effort to reach a common and > > complete understanding of the issues at hand, so that we can hopefully > > agree on the best approach in the end (or if we can't get there, maybe we > > can at least agree on the underlying reasons we don't agree). > [BB] Understood. I was concerned that I was demolishing your idea in public, and I was trying to thank you for being willing to put up a strawman. My quest is also solely to improve the Internet. I spend my half-sleeping hours thinking through all the possible side-effects and combinations of problems with different solutions. I hope I give due weight to problems with my own ideas vs. problems with those of others. However, recently I have had to counter some rather nasty slurs on our work and our motivations, that did require some over-compensation. > With that said, a few brief points I think really should be raised: > > 1. "non-problem" is an unreasonably strong conclusion to reach from a > > snapshot failure to detect any single-queue marking AQMs. > > We know that tc-pie exists in widely deployed systems, supports ECN, and > > could be turned on at any moment by anybody, and we also know there's an > > increased interest in ECN since Apple and Linux got it turned on on > > endpoints.  Even if we measure everything today, it’s hard to be sure this > > wouldn’t impact an in-progress rollout that someone has been working > toward > > for their network with proper due diligence, and following IETF advice > > faithfully. > > I think if the intent is really to deploy this experiment under the claim > > that's a non-problem, it should be called out in the docs as a risk > factor, > > and consensus should probably be explicitly checked on that point.  It > also > > probably would be polite to update RFC 7567's advice in section 4, > since it > > seems like this position would invalidate (or at least add nuance) to > > several of the SHOULDs given there, recommending the use of ECN. > [BB] I understand this, and indeed I've been on the other side of it (where someone else's inconsiderate deployment screwed up something I had been working on for years - and screwed up other things others had been working on). Nonetheless, to a certain extent, it is the Wild West out there, and we cannot interminably walk on egg-shells to the extent that nothing gets done. Indeed, FQ itself screwed up the work on background transport protocols, and many other plans for novel applications of unequal throughput (I'll start a separate thread on that). Don't worry. Classic ECN fall-back is on the ToDo list. I just didn't want to do it unless we have to, cos I prefer simplicity. > 2. “does not starve a classic flow, but can be highly unequal” is also > > perhaps too low a bar to consider a non-problem, and also seems like maybe > > it deserves to be called out as a risk factor. > [BB] To be clear, I wasn't trying to say that a lesser problem was a non-problem. I was pointing out that the word starvation has a specific meaning, that doesn't apply to Scalable vs Classic, but does apply to SCE vs Cubic (both in a single queue). > 3. One more meta-point: the sales-y language makes the drafts hard to > > read for me, so please forgive some of my confusion.  I'm having a hard > > time distinguishing the claims that are well-supported by test results > in a > > realistic experimental design from some of the claims that are more > forward- > > looking or speculative. > [BB] if there are any you want changed, pls call them out. Cheers Bob > > Best regards, > > Jake > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------D7EB6D403A2629854DF943A0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Jake,

On 14/06/2019 18:39, Holland, Jake wrote:

Hi Bob,

 

Thanks for your response, I think it helped clarify some important things

for me.

 

The point about starvation especially was a good one I hadn't fully

considered, and I agree if SCE-based implementations can’t demonstrate a

solution, that would be a major problem with the SCE approach for signaling.

 

And sorry for my slow response, I ended up restarting a few times to try to

dodge ratholes.  (Plus some day-job duties, apologies...)

 

I found it a bit challenging to avoid the ratholes effectively, so I'm

thinking maybe the right move is to set up a testbed.  Maybe playing with

that (very cool-looking!) L4SDemo tool can either ease my concerns, or

provide some more specific and detailed scenarios to address.

 

I see that the source code is published now at

https://github.com/L4STeam/l4sdemo (thanks Olivier!).  So I’ll try to

bring that up at some point, time permitting, in hopes it makes the

comments and questions more productive.

[BB] Cool.

 

One meta-point I wanted to make:

  "In trying to find a compromise, you've taken the fire that is really

  aimed at the inadequacy of underlying SCE protocol - for anything

  other than FQ.  If the primary SCE proponents had attempted to

  articulate a way to use SCE in a single queue or a dual queue, as you

  have, that would have taken my fire."

 

I think "fire" here is a potentially harmful metaphor--I don't take your

comments as an attack or this discussion as a battle, but rather a

collaborative attempt to reach a common goal of a better internet.

 

I hope my comments on this are received the same way, even where we don't

see eye to eye yet.  While both ideas can't be the best use of ECT(1) at

the same time, I take this discussion as an effort to reach a common and

complete understanding of the issues at hand, so that we can hopefully

agree on the best approach in the end (or if we can't get there, maybe we

can at least agree on the underlying reasons we don't agree).

[BB] Understood. I was concerned that I was demolishing your idea in public, and I was trying to thank you for being willing to put up a strawman.

My quest is also solely to improve the Internet. I spend my half-sleeping hours thinking through all the possible side-effects and combinations of problems with different solutions. I hope I give due weight to problems with my own ideas vs. problems with those of others. However, recently I have had to counter some rather nasty slurs on our work and our motivations, that did require some over-compensation.


 

With that said, a few brief points I think really should be raised:

 

1. "non-problem" is an unreasonably strong conclusion to reach from a

snapshot failure to detect any single-queue marking AQMs.

 

We know that tc-pie exists in widely deployed systems, supports ECN, and

could be turned on at any moment by anybody, and we also know there's an

increased interest in ECN since Apple and Linux got it turned on on

endpoints.  Even if we measure everything today, it’s hard to be sure this

wouldn’t impact an in-progress rollout that someone has been working toward

for their network with proper due diligence, and following IETF advice

faithfully.

 

I think if the intent is really to deploy this experiment under the claim

that's a non-problem, it should be called out in the docs as a risk factor,

and consensus should probably be explicitly checked on that point.  It also

probably would be polite to update RFC 7567's advice in section 4, since it

seems like this position would invalidate (or at least add nuance) to

several of the SHOULDs given there, recommending the use of ECN.

[BB] I understand this, and indeed I've been on the other side of it (where someone else's inconsiderate deployment screwed up something I had been working on for years - and screwed up other things others had been working on). Nonetheless, to a certain extent, it is the Wild West out there, and we cannot interminably walk on egg-shells to the extent that nothing gets done.

Indeed, FQ itself screwed up the work on background transport protocols, and many other plans for novel applications of unequal throughput (I'll start a separate thread on that).

Don't worry. Classic ECN fall-back is on the ToDo list. I just didn't want to do it unless we have to, cos I prefer simplicity.



 

2. “does not starve a classic flow, but can be highly unequal” is also

perhaps too low a bar to consider a non-problem, and also seems like maybe

it deserves to be called out as a risk factor.

[BB] To be clear, I wasn't trying to say that a lesser problem was a non-problem.

I was pointing out that the word starvation has a specific meaning, that doesn't apply to Scalable vs Classic, but does apply to SCE vs Cubic (both in a single queue).

 

3. One more meta-point: the sales-y language makes the drafts hard to

read for me, so please forgive some of my confusion.  I'm having a hard

time distinguishing the claims that are well-supported by test results in a

realistic experimental design from some of the claims that are more forward-

looking or speculative.

[BB] if there are any you want changed, pls call them out.

Cheers



Bob

 

Best regards,

Jake

 

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------D7EB6D403A2629854DF943A0--