Re: [tsvwg] Comments on draft-ietf-tsvwg-ecn-l4s-id-05

Bob Briscoe <ietf@bobbriscoe.net> Thu, 15 November 2018 15:04 UTC

Return-Path: <ietf@bobbriscoe.net>
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 2DF7C130DCB for <tsvwg@ietfa.amsl.com>; Thu, 15 Nov 2018 07:04:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level:
X-Spam-Status: No, score=-1.99 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_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
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 80vcQF8-QGZK for <tsvwg@ietfa.amsl.com>; Thu, 15 Nov 2018 07:04:15 -0800 (PST)
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 ietfa.amsl.com (Postfix) with ESMTPS id 54980130DC5 for <tsvwg@ietf.org>; Thu, 15 Nov 2018 07:04:15 -0800 (PST)
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=3TTzlz/nAXSZUlouR37h1hiZUQ0BL0O81ozsctjTc4I=; b=xUyXS2ZiPlhAuBCpNJIBB1j1y CZv/Ywg1PHW12QoujcvbsFOSDFiO3a0/q/TcO9Aa3vd8AGDQPawnfep0fouqCIb5KC1zbnxdoaTLE YHr6s27sLL2Ok8SSgNqhpoeoJt82XDvkDhhOw/lnE7HQ2GwdhzF6WoYf3+F4pfJupO2jBtuulfTEA NUwxzoZ9xOqPl9Wvo1moQDdRmXMCPvNOJ7OZmtqwr+rgVCl0vcLgA7grJhF93SNaMn6o4x+UwfNoI lto7LTc6eBSUsrRxZxdr1U9wGsj8Wr1NLio9HHb1reZqF0GadRWMOGjO8S+lm4a84Gir0pETL4bpg LZ4tiMCqw==;
Received: from 106.0.208.46.dyn.plus.net ([46.208.0.106]:45904 helo=[192.168.0.4]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <ietf@bobbriscoe.net>) id 1gNJBj-0006XF-6P; Thu, 15 Nov 2018 15:04:11 +0000
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>, Magnus Westerlund <magnus.westerlund@ericsson.com>, "'csp@csperkins.org'" <csp@csperkins.org>
References: <DB6PR07MB34008C7D9A241B6AD6AD2AC3C2C60@DB6PR07MB3400.eurprd07.prod.outlook.com> <8d64668e-0284-9d7e-3e3a-3786415d1e2c@bobbriscoe.net> <AM4PR07MB33961955A36D444FD48404D6C2C70@AM4PR07MB3396.eurprd07.prod.outlook.com> <f88e7102-e81e-d270-8c69-eadb9a3b27c3@bobbriscoe.net> <AM4PR07MB3396817A3BD2EDDDC5B04999C2C00@AM4PR07MB3396.eurprd07.prod.outlook.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <64bbceff-852a-eaf2-bfdd-19f6f5a165a5@bobbriscoe.net>
Date: Thu, 15 Nov 2018 15:04:10 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <AM4PR07MB3396817A3BD2EDDDC5B04999C2C00@AM4PR07MB3396.eurprd07.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------03B85931F4F5E822E0FC059F"
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 - ietf.org
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
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/JEYoyVahlvHdjjObiHRUTYiONbo>
Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-ecn-l4s-id-05
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: Thu, 15 Nov 2018 15:04:18 -0000

Ingemar,

On 11/11/2018 20:28, Ingemar Johansson S wrote:
>
> Q3. When you say the following:
>
>     RFC8298 (SCReAM) currently only specifies classic ECN handling,
>     but running code of SCReAM found at
>     https://github.com/EricssonResearch/scream has a working L4S
>     implementation.
>
> are you saying RFC8298 only specifies classic ECN feedback? Or are you 
> now talking about the L4S sender setting ECT(1) and using scalable 
> (L4S) congestion control? Or both?
>
> [IJ] RFC8298 does only specify the behavior assuming classic ECN 
> feedback (ECT(0) set). The running code has an additional L4S mode 
> that implements a scalable reaction to congestion. It is possible that 
> this can added to an updated RFC8298 when/if it is updated from 
> experimental to standards track.
>
>
> If you are solely talking about the sender behaviour here, I would 
> rather move this to where we talk about setting the codepoint or the 
> congestion control.
>

[BB] Your answer still seems to mix feedback (receiver and sender) with 
congestion response (sender).

Here's my question written more clearly:

If both ends already support avtcore-cc-feedback-message, can one end 
unilaterally implement the L4S congestion response (and therefore set 
ECT(1) on outgoing packets)?
Or did you have to enhance the avtcore-cc-feedback-message code (for 
writing feedback at one end and reading it at the other), before one end 
(or both) could add the L4S congestion response?

The stated goal of avtcore-cc-feedback-message is:

    To enable algorithm evolution as well as
    interoperability across designs (e.g., different rate adaptation
    algorithms), it is highly desirable to have generic congestion
    control feedback format.

If you had to enhance the feedback format for L4S, that would imply the 
feedback message is still not generic enough.


Bob

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