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 D1F443B2A4 for ; Thu, 4 Jul 2019 13:54:31 -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=ep33j2UfnMo9WcKbj0UKpEPUylOr3h5i8juFD2Vufjc=; b=2UrOe9GZHgTc7IE//D9/bqd3U Yki6kQ3ozOVdWRSeRqUxii9VPltCBxO8LVmLziFeDJpB/tkx1NyUlMxvWcLggGD3zP+/ZUUp1nugh Hw6WmNPwWy6fNKuKXywxhjZDbJrEm6nytvwha8dM1zHwd/JHuiHNlPRy9fcCih/Pwu7iFFv2bgNVk HEv1Uij3lZQT8rcJa3WSRnvMGGNXZ8A2L1dO4zMUMVUPFGThFRXBxB6a9NpsBCM6djFlIibHZYXtw KpoYRexTL5bIobQKhXH5qcD5iht9PMi44mHXEKw4Csi/0bqBHGmobwxqFYaagRXse6ni5+/T8pIxm RCSQvIWRQ==; Received: from [31.185.128.20] (port=57618 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 1hj5wE-0001jl-B3; Thu, 04 Jul 2019 18:54:30 +0100 To: Jonathan Morton , "De Schepper, Koen (Nokia - BE/Antwerp)" Cc: "ecn-sane@lists.bufferbloat.net" , "tsvwg@ietf.org" References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <4aff6353-eb0d-b0b8-942d-9c92753f074e@bobbriscoe.net> <1238A446-6E05-4A55-8B3B-878C8F39FC75@gmail.com> <17B33B39-D25A-432C-9037-3A4835CCC0E1@gmail.com> From: Bob Briscoe Message-ID: <5c58a2d1-0dfc-e0fa-398a-9e196615f04a@bobbriscoe.net> Date: Thu, 4 Jul 2019 18:54:29 +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: <17B33B39-D25A-432C-9037-3A4835CCC0E1@gmail.com> Content-Type: multipart/alternative; boundary="------------CF0BEB7239C7AE0A339E8777" 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] [tsvwg] 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: Thu, 04 Jul 2019 17:54:32 -0000 This is a multi-part message in MIME format. --------------CF0BEB7239C7AE0A339E8777 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Jonathan, On 04/07/2019 15:03, Jonathan Morton wrote: >> On 4 Jul, 2019, at 4:43 pm, De Schepper, Koen (Nokia - BE/Antwerp) wrote: >> >> So conclusion: a DualQ works exactly the same as any other single Q AQM supporting ECN !! >> Try it, and you'll see... > But that's exactly the problem. Single queue AQM does not isolate L4S traffic from "classic" traffic, so the latter suffers from the former's relative aggression in the face of AQM activity. You are assuming that the one thing we haven't done yet (fall-back to TCP-friendly on detection of classic ECN) won't work, whereas all the problems you have not addressed yet with SCE will work. > This isolation is the very reason why something like DualQ is proposed, so the fact that it can be defeated into this degraded single-queue mode is a genuine problem. > > May I direct you to our LFQ draft, published yesterday, for what we consider to be a much more robust approach, yet with similar hardware requirements to DualQ? I'd be interested in hearing feedback. I will certainly read. I assume you are aware that implementation complexity is only a small part of the objections to FQ. {Note 1} I believe that using this to enable fine-grained congestion control would still rely on the semantics of the SCE style of signalling still. Correct? So, for the third time of asking, can you or someone please respond to the 5 points that will be problematic for SCE (I listed them on 11 Mar 2019 on tsvwg@ietf.org re-pasted from bloat@ to you & DaveT the day after you posted the first draft). You will not get anywhere in the IETF without addressing serious problems that people raise with your proposal. I don't need to tell you that the Internet is a complex place to introduce anything new, especially into IP itself. If you cannot solve /all/ these problems, it will save everyone a lot of time if you just say so. I have repeated bullets summarizing each question below (I've removed the one about re-purposing the receive window, which DaveT wished hadn't been mentioned, and added Q4 which I asked more recently). You may wish to start a new thread to answer some of the more substantive ones. They are roughly ranked in order of seriousness with Q1-3 being show-stoppers. * Q1. Does SCE require per-flow scheduling? o If so, how do you expect it to be supported on L2 links, where not even the IP header is accessible, let alone L4? o If not, how does it work? * Q2. How do you address the lack of ECT(1) feedback in TCP, given no-one is implementing the AccECN TCP option? And even if they did, do you have measurements on how few middleboxes / proxies, etc will allow traversal? * Q3. How do you address all the tunnel decapsulators that will black-hole ECT(1) marking of the outer? Do you have measurements of how much of a blockage to progress this will be? * Q4. How do you address the interaction of the two timescale dynamics in the SCE congestion control? * Q5. Can out-of-order tolerance be relaxed on links supporting SCE? (not a problem as such, but a lack of one of L4S's advantages) {Note 1}: Implementation complexity is only a small part of the objections to FQ. One major reason is in Q1 above. I have promised a write-up of all the other reasons for why per-flow scheduling is not a desirable goal even if it can be achieved with low complexity. I've got it half written (as a tech report, not an Internet Draft), but it's on hold while other stuff takes priority for me (not least an awkwardly timed family vacation starting tomorrow for 10 days). Cheers Bob > > - Jonathan Morton -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------CF0BEB7239C7AE0A339E8777 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Jonathan,

On 04/07/2019 15:03, Jonathan Morton wrote:
On 4 Jul, 2019, at 4:43 pm, De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com> wrote:

So conclusion:   a DualQ works exactly the same as any other single Q AQM supporting ECN !!
Try it, and you'll see...

But that's exactly the problem.  Single queue AQM does not isolate L4S traffic from "classic" traffic, so the latter suffers from the former's relative aggression in the face of AQM activity.
You are assuming that the one thing we haven't done yet (fall-back to TCP-friendly on detection of classic ECN) won't work, whereas all the problems you have not addressed yet with SCE will work.

 This isolation is the very reason why something like DualQ is proposed, so the fact that it can be defeated into this degraded single-queue mode is a genuine problem.

May I direct you to our LFQ draft, published yesterday, for what we consider to be a much more robust approach, yet with similar hardware requirements to DualQ?  I'd be interested in hearing feedback.
I will certainly read. I assume you are aware that implementation complexity is only a small part of the objections to FQ. {Note 1}

I believe that using this to enable fine-grained congestion control would still rely on the semantics of the SCE style of signalling still. Correct?

So, for the third time of asking, can you or someone please respond to the 5 points that will be problematic for SCE (I listed them on 11 Mar 2019 on tsvwg@ietf.org re-pasted from bloat@ to you & DaveT the day after you posted the first draft). You will not get anywhere in the IETF without addressing serious problems that people raise with your proposal.

I don't need to tell you that the Internet is a complex place to introduce anything new, especially into IP itself. If you cannot solve /all/ these problems, it will save everyone a lot of time if you just say so.

I have repeated bullets summarizing each question below (I've removed the one about re-purposing the receive window, which DaveT wished hadn't been mentioned, and added Q4 which I asked more recently). You may wish to start a new thread to answer some of the more substantive ones. They are roughly ranked in order of seriousness with Q1-3 being show-stoppers.
  • Q1. Does SCE require per-flow scheduling?
    • If so, how do you expect it to be supported on L2 links, where not even the IP header is accessible, let alone L4?
    • If not, how does it work?
  • Q2. How do you address the lack of ECT(1) feedback in TCP, given no-one is implementing the AccECN TCP option? And even if they did, do you have measurements on how few middleboxes / proxies, etc will allow traversal?
  • Q3. How do you address all the tunnel decapsulators that will black-hole ECT(1) marking of the outer? Do you have measurements of how much of a blockage to progress this will be?
  • Q4. How do you address the interaction of the two timescale dynamics in the SCE congestion control?
  • Q5. Can out-of-order tolerance be relaxed on links supporting SCE? (not a problem as such, but a lack of one of L4S's advantages)

{Note 1}: Implementation complexity is only a small part of the objections to FQ. One major reason is in Q1 above. I have promised a write-up of all the other reasons for why per-flow scheduling is not a desirable goal even if it can be achieved with low complexity. I've got it half written (as a tech report, not an Internet Draft), but it's on hold while other stuff takes priority for me (not least an awkwardly timed family vacation starting tomorrow for 10 days).


Cheers



Bob





 - Jonathan Morton

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