Re: [tsvwg] Comments on L4S drafts
Luca Muscariello <muscariello@ieee.org> Wed, 19 June 2019 13:02 UTC
Return-Path: <muscariello@ieee.org>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBB112032D for <tsvwg@ietfa.amsl.com>; Wed, 19 Jun 2019 06:02:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.008
X-Spam-Level:
X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ieee.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFh0RSrEsNyO for <tsvwg@ietfa.amsl.com>; Wed, 19 Jun 2019 06:02:26 -0700 (PDT)
Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 902E2120227 for <tsvwg@ietf.org>; Wed, 19 Jun 2019 06:02:26 -0700 (PDT)
Received: by mail-wm1-x341.google.com with SMTP id g135so1703001wme.4 for <tsvwg@ietf.org>; Wed, 19 Jun 2019 06:02:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b7rT4dObkzGfltnqgYrNZisLK5o22yz7RMv91/t9qgc=; b=gHU4G9dKrXL1RB1gflp4vRYQ6oZdyv78os+esQY/NCysUj7SU5k7P0Gr7odn1pYd+r 013amlVwatekhO984VmlIob7bvmKNKX8xJIc6rtvnZv2soM8DT+83m9eYNS7YR8Pa4in LjWUVZ1DBn/xTuS5zqsqFsfjfAvRLqquQxmlo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b7rT4dObkzGfltnqgYrNZisLK5o22yz7RMv91/t9qgc=; b=qJbAg0/MNRE6u9flIrSS57UneWiuWUBEKe4rPsFrdMUOgv1o+y3oA64pDWnswH83Mm pC4DWw0Avi2E0ERNGomMabvmR3BXnMWUqawjR9pJQlgIG5h00oV1xsXyR/SqQalSs0sB dSu4u/gQzrw/DtNbf2qhJLDZVu34IGNWgI+zyt1/OHO1ruAHT2uvHWxskcOM+bWB/AIx lrAzyRJqpGaUpUXSbVmFKt5QiJ+5j/rP/o92SfbxT1krFTGMeSGldHqoC599Hyafqm24 ex857ppbEU9NuAn1YIqsahO1UDKQw+TwBew1eYMHztre2ugV5sqC2BWpotaD5cM1fFSA 4CWw==
X-Gm-Message-State: APjAAAXtq10dvYceCouAE1XKV304vaTpOYmzuKF01kvklK7HsJZ5BgtW 0qRYWGj8fFtD38EsxU2vJ9hMGyueWVR6uaeosKxB8w==
X-Google-Smtp-Source: APXvYqz5LR4qHAyeqPmsJ6jLR+agc2OzG9yzTnAx7lsXzp9aHzScHQYAIx8mIMMh4ZcrCptF+gCx4lIzgj6u09+TfFw=
X-Received: by 2002:a05:600c:389:: with SMTP id w9mr8032314wmd.139.1560949345021; Wed, 19 Jun 2019 06:02:25 -0700 (PDT)
MIME-Version: 1.0
References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <cc446538-cf23-4fd0-12df-7839ec6c04a2@bobbriscoe.net> <CAH8sseSPz3FoLWZNPEJcwb4xQNYk_FXb8VS5ec9oYwocHAHCBg@mail.gmail.com> <4aff6353-eb0d-b0b8-942d-9c92753f074e@bobbriscoe.net> <D13294C4-105C-4F58-A762-6911A21A18C6@akamai.com>
In-Reply-To: <D13294C4-105C-4F58-A762-6911A21A18C6@akamai.com>
From: Luca Muscariello <muscariello@ieee.org>
Date: Wed, 19 Jun 2019 06:02:13 -0700
Message-ID: <CAH8sseSQaCbknok--hf=DgwzCs3OnnkKjPy5bdLgnzjq7-+c_w@mail.gmail.com>
To: "Holland, Jake" <jholland@akamai.com>
Cc: Bob Briscoe <ietf@bobbriscoe.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "ecn-sane@lists.bufferbloat.net" <ecn-sane@lists.bufferbloat.net>
Content-Type: multipart/alternative; boundary="0000000000003923a8058bacd768"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/gKFIrBVcNCEZm9wQOIDvyBEi0yM>
Subject: Re: [tsvwg] Comments on L4S drafts
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jun 2019 13:02:30 -0000
Jake, Yes, that is one scenario that I had in mind. Your response comforts me that I my message was not totally unreadable. My understanding was - There are incentives to mark packets if they get privileged treatment because of that marking. This is similar to the diffserv model with all the consequences in terms of trust. - Unresponsive traffic in particular (gaming, voice, video etc.) has incentives to mark. Assuming there is x% of unresponsive traffic in the priority queue, it is non trivial to guess how the system works. - in particular it is easy to see the extreme cases, (a) x is very small, assuming the system is stable, the overall equilibrium will not change. (b) x is very large so the dctcp like sources fall back to cubic like and the systems behave almost like a single FIFO. (c) in all other cases x varies according to the unresponsive sources' rates. Several different equilibria may exist, some of which may include oscillations. Including oscillations of all fallback mechanisms. The reason I'm asking is that these cases are not discussed in the I-D documents or in the references, despite these are very common use cases. If we add the queue protection mechanism, all unresponsive flows that are caught cheating are registered in a blacklist and always scheduled in the non-priority queue. It that happens unresponsive flows will get a service quality that is worse than if using a single FIFO for all flows. Using a flow blacklist brings back the complexity that dualq is supposed to remove compared to flow-isolation by flow-queueing. It seems to me that the blacklist is actually necessary to make dualq work under the assumption that x is small, because in the other cases the behavior of the dualq system is unspecified and likely subject to instabilities, i.e. potentially different kind of oscillations. Luca On Tue, Jun 18, 2019 at 9:25 PM Holland, Jake <jholland@akamai.com> wrote: > Hi Bob and Luca, > > Thank you both for this discussion, I think it helped crystallize a > comment I hadn't figured out how to make yet, but was bothering me. > > I’m reading Luca’s question as asking about fixed-rate traffic that does > something like a cutoff or downshift if loss gets bad enough for long > enough, but is otherwise unresponsive. > > The dualq draft does discuss unresponsive traffic in 3 of the sub- > sections in section 4, but there's a point that seems sort of swept > aside without comment in the analysis to me. > > The referenced paper[1] from that section does examine the question > of sharing a link with unresponsive traffic in some detail, but the > analysis seems to bake in an assumption that there's a fixed amount > of unresponsive traffic, when in fact for a lot of the real-life > scenarios for unresponsive traffic (games, voice, and some of the > video conferencing) there's some app-level backpressure, in that > when the quality of experience goes low enough, the user (or a qoe > trigger in the app) will often change the traffic demand at a higher > layer than a congestion controller (by shutting off video, for > instance). > > The reason I mention it is because it seems like unresponsive > traffic has an incentive to mark L4S and get low latency. It doesn't > hurt, since it's a fixed rate and not bandwidth-seeking, so it's > perfectly happy to massively underutilize the link. And until the > link gets overloaded it will no longer suffer delay when using the > low latency queue, whereas in the classic queue queuing delay provides > a noticeable degradation in the presence of competing traffic. > > I didn't see anywhere in the paper that tried to check the quality > of experience for the UDP traffic as non-responsive traffic approached > saturation, except by inference that loss in the classic queue will > cause loss in the LL queue as well. > > But letting unresponsive flows get away with pushing out more classic > traffic and removing the penalty that classic flows would give it seems > like a risk that would result in more use of this kind of unresponsive > traffic marking itself for the LL queue, since it just would get lower > latency almost up until overload. > > Many of the apps that send unresponsive traffic would benefit from low > latency and isolation from the classic traffic, so it seems a mistake > to claim there's no benefit, and it furthermore seems like there's > systematic pressures that would often push unresponsive apps into this > domain. > > If that line of reasoning holds up, the "rather specific" phrase in > section 4.1.1 of the dualq draft might not turn out to be so specific > after all, and could be seen as downplaying the risks. > > Best regards, > Jake > > [1] https://riteproject.files.wordpress.com/2018/07/thesis-henrste.pdf > > PS: This seems like a consequence of the lack of access control on > setting ECT(1), and maybe the queue protection function would address > it, so that's interesting to hear about. > > But I thought the whole point of dualq over fq was that fq state couldn't > scale properly in aggregating devices with enough expected flows sharing > a queue? If this protection feature turns out to be necessary, would that > advantage be gone? (Also: why would one want to turn this protection off > if it's available?) > > >
- [tsvwg] Comments on L4S drafts Holland, Jake
- Re: [tsvwg] Comments on L4S drafts Bob Briscoe
- Re: [tsvwg] Comments on L4S drafts Ingemar Johansson S
- Re: [tsvwg] Comments on L4S drafts Holland, Jake
- Re: [tsvwg] Comments on L4S drafts Holland, Jake
- Re: [tsvwg] Comments on L4S drafts Luca Muscariello
- Re: [tsvwg] Comments on L4S drafts Dave Taht
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Dave Taht
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Dave Taht
- Re: [tsvwg] Comments on L4S drafts Ingemar Johansson S
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Ingemar Johansson S
- Re: [tsvwg] Comments on L4S drafts Bob Briscoe
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Dave Taht
- Re: [tsvwg] Comments on L4S drafts Holland, Jake
- Re: [tsvwg] Comments on L4S drafts Bob Briscoe
- Re: [tsvwg] Comments on L4S drafts Luca Muscariello
- Re: [tsvwg] Comments on L4S drafts Bob Briscoe
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Bob Briscoe
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Jonathan Morton
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Bob Briscoe
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Jonathan Morton
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Bob Briscoe
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Jonathan Morton
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Jonathan Morton
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Luca Muscariello
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Holland, Jake
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Dave Taht
- Re: [tsvwg] Comments on L4S drafts Holland, Jake
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Holland, Jake
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Sebastian Moeller
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Gorry Fairhurst
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Dave Taht
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Sebastian Moeller
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Wesley Eddy
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Dave Taht
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Black, David
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Jonathan Morton
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Sebastian Moeller
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Sebastian Moeller
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Wesley Eddy
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Dave Taht
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Dave Taht
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Bob Briscoe
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Bob Briscoe
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Scharf, Michael
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Gorry Fairhurst
- [tsvwg] Hackathon tests Dave Taht
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Sebastian Moeller
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Jonathan Morton
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Sebastian Moeller
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Sebastian Moeller
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Black, David
- Re: [tsvwg] New Version Notification for draft-gr… alex.burr@ealdwulf.org.uk
- Re: [tsvwg] New Version Notification for draft-gr… Jonathan Morton
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Bob Briscoe
- Re: [tsvwg] New Version Notification for draft-gr… alex.burr@ealdwulf.org.uk
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Sebastian Moeller
- Re: [tsvwg] [tcpm] New Version Notification for d… Scharf, Michael
- Re: [tsvwg] [tcpm] New Version Notification for d… Jonathan Morton
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Bless, Roland (TM)
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Dave Taht
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Pete Heist
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Sebastian Moeller
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Dave Taht
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] [tcpm] New Version Notification for d… Bob Briscoe
- Re: [tsvwg] [tcpm] New Version Notification for d… Scharf, Michael
- Re: [tsvwg] [tcpm] New Version Notification for d… Black, David
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Bob Briscoe
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Bob Briscoe
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Sebastian Moeller
- [tsvwg] [Ecn-sane] Compatibility with singlw queu… Sebastian Moeller
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Pete Heist
- Re: [tsvwg] [Ecn-sane] Compatibility with singlw … Black, David
- [tsvwg] The state of l4s, bbrv2, sce? Dave Taht
- Re: [tsvwg] The state of l4s, bbrv2, sce? Dave Taht
- Re: [tsvwg] The state of l4s, bbrv2, sce? Neal Cardwell
- Re: [tsvwg] The state of l4s, bbrv2, sce? Dave Taht
- Re: [tsvwg] [Ecn-sane] Compatibility with singlw … Sebastian Moeller
- Re: [tsvwg] [Ecn-sane] Compatibility with singlw … Holland, Jake
- Re: [tsvwg] [Ecn-sane] Compatibility with singlw … Black, David
- Re: [tsvwg] [Ecn-sane] Compatibility with singlw … Black, David
- Re: [tsvwg] [Ecn-sane] Compatibility with singlw … Sebastian Moeller
- Re: [tsvwg] [Ecn-sane] Compatibility with singlw … Jonathan Morton
- Re: [tsvwg] [Ecn-sane] Compatibility with singlw … Mikael Abrahamsson
- Re: [tsvwg] [Ecn-sane] Compatibility with singlw … Mikael Abrahamsson
- Re: [tsvwg] [Ecn-sane] Compatibility with singlw … John Leslie
- Re: [tsvwg] New Version Notification for draft-gr… Rodney W. Grimes
- Re: [tsvwg] New Version Notification for draft-gr… Gorry Fairhurst
- Re: [tsvwg] New Version Notification for draft-gr… Jonathan Morton
- Re: [tsvwg] New Version Notification for draft-gr… Gorry Fairhurst
- Re: [tsvwg] New Version Notification for draft-gr… Sebastian Moeller
- Re: [tsvwg] New Version Notification for draft-gr… Gorry Fairhurst
- Re: [tsvwg] [tcpm] New Version Notification for d… Scharf, Michael
- Re: [tsvwg] New Version Notification for draft-gr… Rodney W. Grimes
- Re: [tsvwg] [tcpm] New Version Notification for d… Loganaden Velvindron
- Re: [tsvwg] [tcpm] New Version Notification for d… Black, David