From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5A35B3CB38 for ; Fri, 14 Jun 2019 16:10:15 -0400 (EDT) Received: by mail-wm1-x32d.google.com with SMTP id g135so3530288wme.4 for ; Fri, 14 Jun 2019 13:10:15 -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=QsaEzHZtEhRkNIGn33AFudXfn8lGvxgHyxqTWGuz6uc=; b=fd0MBzWMioIzyoy3VMEg3uJ6tmrnRkPkxBwRsUfJ1UXWsyCfzImepJs/N6llvDIPvY AM5lJ0Gpg+v2kMX7pTfa12pHw6z+tJrTS2/PeEjE/z0Wyds/8z0ZvZm732UR9/Okzd4S P7wAQIFwoIWYUmE1+NFM37Z0Ky9DoJ02fnN34= 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=QsaEzHZtEhRkNIGn33AFudXfn8lGvxgHyxqTWGuz6uc=; b=BgZnYltR7ahvABAFam37TE1pnnCFGv7KeS8cx/nUimiVEQrEAkTKTOozZvigKWMc9G xdYGo2qPhQA+oH7haHEaC/AxQDdPOmrfxa/slsbES1uetFYOASU4PkOTBcjyRVblsyfM yjmmhOWzOJa5a861YKL0xGk+x4NZW02FAAJQCTCwZVw6cASf2V/iiEDjLR9GU8i4l5ns a1Xgm9kIB0QUp+C06VqzTeDNppme7zNsSd5GJh2yWDi/VQp0ArIajJxT8y6J4d4gCZKO rqkA3hlJV8797oj8b8q+hOBORnAp02Hdf8xbo4xFIm0lzJ+BSlZQxUT1YtBle+fsAJMB +BTA== X-Gm-Message-State: APjAAAXEaNVKPJIaMJ8t0DLJqoSwtvSGEubStsMHErxtUVlfEkXJDlEQ g3U2v6hZcNlBT2UmLtDonTpBGyFkzuaarQa9dN62OQ== X-Google-Smtp-Source: APXvYqzaWWkVHH3UEoCXdQkLX2nAYqbsnENkYAs8C7CB4CWEj7PNAIsk9cNslHHUx+1rjA0Vgx+6Kv7EmnTFgFt15s0= X-Received: by 2002:a1c:7408:: with SMTP id p8mr543646wmc.161.1560543014411; Fri, 14 Jun 2019 13:10:14 -0700 (PDT) MIME-Version: 1.0 References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> In-Reply-To: From: Luca Muscariello Date: Fri, 14 Jun 2019 22:10:03 +0200 Message-ID: To: Bob Briscoe Cc: "Holland, Jake" , "tsvwg@ietf.org" , "ecn-sane@lists.bufferbloat.net" Content-Type: multipart/alternative; boundary="000000000000080879058b4e3c6c" X-Mailman-Approved-At: Fri, 14 Jun 2019 17:46:05 -0400 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: Fri, 14 Jun 2019 20:10:15 -0000 --000000000000080879058b4e3c6c Content-Type: text/plain; charset="UTF-8" On Fri, Jun 7, 2019 at 8:10 PM Bob Briscoe wrote: > > I'm afraid there are not the same pressures to cause rapid roll-out at > all, cos it's flakey now, jam tomorrow. (Actually ECN-DualQ-SCE has a much > greater problem - complete starvation of SCE flows - but we'll come on to > that in Q4.) > > I want to say at this point, that I really appreciate all the effort > you've been putting in, trying to find common ground. > > 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. > > But regardless, the queue-building from classic ECN-capable endpoints that > only get 1 congestion signal per RTT is what I understand as the main > downside of the tradeoff if we try to use ECN-capability as the dualq > classifier. Does that match your understanding? > > This is indeed a major concern of mine (not as major as the starvation of > SCE explained under Q4, but we'll come to that). > > Fine-grained (DCTCP-like) and coarse-grained (Cubic-like) congestion > controls need to be isolated, but I don't see how, unless their packets are > tagged for separate queues. Without a specific fine/coarse identifier, > we're left with having to re-use other identifiers: > > - You've tried to use ECN vs Not-ECN. But that still lumps two large > incompatible groups (fine ECN and coarse ECN) together. > - The only alternative that would serve this purpose is the flow > identifier at layer-4, because it isolates everything from everything else. > FQ is where SCE started, and that seems to be as far as it can go. > > Should we burn the last unicorn for a capability needed on "carrier-scale" > boxes, but which requires FQ to work? Perhaps yes if there was no > alternative. But there is: L4S. > > I have a problem to understand why all traffic ends up to be classified as either Cubic-like or DCTCP-like. If we know that this is not true today I fail to understand why this should be the case in the future. It is also difficult to predict now how applications will change in the future in terms of the traffic mix they'll generate. I feel like we'd be moving towards more customized transport services with less predictable patterns. I do not see for instance much discussion about the presence of RTC traffic and how the dualQ system behaves when the input traffic does not respond as expected by the 2-types of sources assumed by dualQ. If my application is using simulcast or multi-stream techniques I can have several video streams in the same link, that, as far as I understand, will get significant latency in the classic queue. Unless my app starts cheating by marking packets to get into the priority queue. In both cases, i.e. my RTC app is cheating or not, I do not understand how the parametrization of the dualQ scheduler can cope with traffic that behaves in a different way to what is assumed while tuning parameters. For instance, in one instantiation of dualQ based on WRR the weights are set to 1:16. This has to necessarily change when RTC traffic is present. How? Is the assumption that a trusted marker is used as in typical diffserv deployments or that a policer identifies and punishes cheating applications? BTW I'd love to understand how dualQ is supposed to work under more general traffic assumptions. Luca --000000000000080879058b4e3c6c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Jun 7, 2019 at 8:10 PM Bob Brisco= e <ietf@bobbriscoe.net> wr= ote:
=20 =20 =20

=C2=A0I'm afraid there are not the same pressures to cause rapid ro= ll-out at all, cos it's flakey now, jam tomorrow. (Actually ECN-DualQ-SCE has a much greater problem - complete starvation of SCE flows - but we'll come on to that in Q4.)

I want to say at this point, that I really appreciate all the effort you've been putting in, trying to find common ground.

In trying to find a compromise, you've taken the fire that is reall= y 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. 

But regardle=
ss, the queue-building from classic ECN-capable endpoints that
only get 1 congestion signal per RTT is what I understand as the main
downside of the tradeoff if we try to use ECN-capability as the dualq
classifier.  Does that match your understanding?
This is indeed a major concern of mine (not as major as the starvation of SCE explained under Q4, but we'll come to that).

Fine-grained (DCTCP-like) and coarse-grained (Cubic-like) congestion controls need to be isolated, but I don't see how, unless their packets are tagged for separate queues. Without a specific fine/coarse identifier, we're left with having to re-use other identifiers:
  • You've tried to use ECN vs Not-ECN. But that still lumps two large incompatible groups (fine ECN and coarse ECN) together.
  • The only alternative that would serve this purpose is the flow identifier at layer-4, because it isolates everything from everything else. FQ is where SCE started, and that seems to be as far as it can go.
Should we burn the last unicorn for a capability needed on "carrier-scale" boxes, but which requires FQ to work? Perhaps= yes if there was no alternative. But there is: L4S.


I have a problem to understa= nd why all traffic ends up to be classified as either Cubic-like or DCTCP-l= ike.=C2=A0
If we know that this is not true today I fail to under= stand why this should be the case in the future.=C2=A0
It is also= difficult to predict now how applications will change in the future in ter= ms of the traffic mix they'll generate.
I feel like we'd = be moving towards more customized transport services with less predictable = patterns.

I do not see for instance much discussio= n about the presence of RTC traffic and how the dualQ system behaves when t= he=C2=A0
input traffic does not respond as expected by the 2-type= s of sources assumed by dualQ.

If my application i= s using simulcast or multi-stream techniques I can have several video strea= ms in the same link,=C2=A0 that, as far as I understand,
will get= significant latency in the classic queue. Unless my app starts cheating by= marking packets to get into the priority queue.

I= n both cases, i.e. my RTC app is cheating or not, I do not understand how t= he parametrization of the dualQ scheduler=C2=A0
can cope with tra= ffic that behaves in a different way to what is assumed while tuning parame= ters.=C2=A0
For instance, in one instantiation of dualQ based on = WRR the weights are set to 1:16.=C2=A0 This has to necessarily=C2=A0
<= div>change when RTC traffic is present. How?

= Is the assumption that a trusted marker is used as in typical diffserv depl= oyments
or that a policer identifies and punishes cheating applic= ations?

BTW I'd love to understand how d= ualQ is supposed to work under more general traffic assumptions.
=
Luca

=C2=A0
--000000000000080879058b4e3c6c--