Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-12.txt

Bob Briscoe <> Fri, 15 January 2021 12:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D5CD3A0C6C for <>; Fri, 15 Jan 2021 04:43:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.36
X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.262, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WqAJ8p9IOSda for <>; Fri, 15 Jan 2021 04:43:00 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3118F3A0C6A for <>; Fri, 15 Jan 2021 04:42:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To: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=Y0ZmrbwSC1nejQZBNVjh8kVS85rcDH1KXH0KvrpluuU=; b=BO0a7QgPf7Mwg5XXCgMRoaEMOt JhqdJRzBH6MhK+FrP+zebJhoGA7QVPJ29+uezQYfkO45NxBHhTocKGWrwo4B0bUhT1MY+eB/GBx0K oW+Danyp/s8ZeMqmz5FKmGVamaCo4jjM6INL4JSglvZ3R88ksbnoE9Pd8UYyQcsnxAM4B8krFEW0X U41qg3qcb3QwJ97gE4HVwIadEYFkNFa/IhmSZMqN/0Xevwz4BcR3MApvqRtZ9vTCnC51RrrITzB8+ l472dvEYCQJANbRFXFa49gr6MJ8KvCyjKCa8e2Oml5/vFkZz+HFoux7ptiy60y2KsOM177dQtCE34 gs5b9iDg==;
Received: from ([]:40356 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <>) id 1l0ORN-0007By-J4; Fri, 15 Jan 2021 12:42:57 +0000
To: Ingemar Johansson S <>, "" <>
Cc: "" <>
References: <> <>
From: Bob Briscoe <>
Message-ID: <>
Date: Fri, 15 Jan 2021 12:42:56 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-12.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 15 Jan 2021 12:43:03 -0000


Just to thank you for the comments at this stage. I'll deal with these 



On 14/01/2021 15:26, Ingemar Johansson S wrote:
> Hi
> I have now re-read this draft with some more careful eyes. It is not for
> certain that the comments lead to any major changes in the draft, but
> nonetheless...
> I tried to look at this from a real time media congestion control perspective
> (RTP/UDP) and based on the experience I've had with SCReAM and L4S thus far.
> This can also serve as an indication how well the requirements in section 4.3
> is fulfilled at the time of writing this email.
> /Ingemar
> =================
> Section 4.3 : Prerequisite Congestion Response
> Quote "As well as responding to ECN markings, a scalable congestion
>        control MUST react to packet loss in a way that will coexist
>        safely with a TCP Reno congestion control "
> SCReAM backs off, on packet loss, but not with a factor 0.5. Rather it scales
> down the congestion window with a factor 0.8. The rationale is that the
> encoded video has a variable frame size and that gives some additional
> headroom to avoid that the larger frames build up a large queue. The outcome
> is still that SCReAM can coexist safely with Reno
> Quote "A scalable congestion control MUST implement monitoring in order
>        to detect a likely non-L4S but ECN-capable AQM at the bottleneck."
> SCReAM use delay based congestion control. The estimated queue delay will be
> near zero when L4S bottlenecks are encountered. For cases with classic ECN
> queues in the network, the queue delay would be higher which means that it
> should be possible to detect non-L4S but ECN capable AQMs
> Quote "A scalable congestion control MUST eliminate RTT bias as much as
>        possible in the range between the minimum likely RTT and typical
>        RTTs expected in the intended deployment scenario "
> This has drawn less focus and needs to be evaluated and possibly addressed. It
> is here likely that the algorithms devised for Prague can be used
> Quote "A scalable congestion control SHOULD remain responsive to
>        congestion when typical RTTs over the public Internet are
>        significantly smaller because they are no longer inflated by
>        queuing delay"
> The minimum congestion window is 3 MSS (configurable). SCReAM however
> implements packet pacing but SCReAMs performance in very low RTT deployments
> is not yet evaluated.
> Quote "A scalable congestion control SHOULD detect loss by counting in
>        time-based units". SCReAM implements loss detection in time based units
> only.
> Quote "A scalable congestion control is expected to limit the queue
>        caused by bursts of packets." SCReAM by default implements packet
> pacing. Lately however it has been experimented with microburst pacing wherein
> packets are transmitted in bursts with e.g. 2 or 5ms. The reason to this is
> that it can help to reduce power consumption in 5G phones.
> =================
> Section 4.3 Filtering or Smoothing of ECN Feedback
> Quote "the specification
>     of a particular L4S congestion control SHOULD describe how it smooths
>     the L4S ECN signals fed back to it from the receiver"
> The RTCP feedback
> ( )
> indicates CE mark for each packet, this means that no smoothing is applied on
> the CE marks. The L4S congestion response in the sender is similar to DCTCP
> and Prague.
> =================
> Section 5.2 The Meaning of L4S CE Relative to Drop
>     smooth or filter out variations in the queue before signalling
>     congestion."
> I believe the SHOULD NOT is reasonable. In some cases it may however be
> necessary to apply some limited smoothing. One example is where congestion is
> detected on the RLC layer in a 5G system. It I not always realistic to signal
> a marking decision up to the PDCP layer, where the IP packets are marked, for
> each packet that is scheduled for transmission. This because it can cause a
> too high internal signaling overhead in the radio base stations. A more
> realistic solution is to signal a marking probability up to the PDCP layer.
> Smoothing is applied to avoid the issues that the subsampling of the RLC queue
> delay can cause.
> =================
> Section 5.5 Limiting Packet Bursts from Links Supporting L4S AQMs
> Quote "Some take the  attitude that there is no point reducing burst delay",
> perhaps can be reworded as "One may argue that ......"
> In general, 4G and 5G systems can generate packet bursts due to how they are
> designed. On the other hand, the use of larger sub carrier spacing (shorter
> time slots)  will also reduce the burst delays.
> =================
> Section 6.1 Open questions
> In addition to all the metrics, I believe that it can be good to also be able
> to record the ratio of marked packets (average, 95%, max?) . My sense is that
> endpoints that behave reasonably well will have marking ratios up to say 20%
> (guessing a bit)? If problems occur, then recording  of L4S marking ratios can
> give an indication of e.g. issues with bloated access links are because of
> endpoints that implement poor or non-functional congestion control.
> =================
> Section 6.3 Future Potential
> Although SCReAM appears to work reasonably well (more testing needed), I do
> believe that there is a lot of room for improvement as regards to how one
> stream low latency real time video from mostly "black box" encoders (with
> wildly varying frame sizes) over L4S capable access.
>> -----Original Message-----
>> From: tsvwg <> On Behalf Of
>> Sent: den 16 november 2020 03:07
>> To:
>> Cc:
>> Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-12.txt
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Transport Area Working Group WG of the
>> IETF.
>>          Title           : Identifying Modified Explicit Congestion
>> Notification (ECN)
>> Semantics for Ultra-Low Queuing Delay (L4S)
>>          Authors         : Koen De Schepper
>>                            Bob Briscoe
>> 	Filename        : draft-ietf-tsvwg-ecn-l4s-id-12.txt
>> 	Pages           : 58
>> 	Date            : 2020-11-15
>> Abstract:
>>     This specification defines the identifier to be used on IP packets
>>     for a new network service called low latency, low loss and scalable
>>     throughput (L4S).  L4S uses an Explicit Congestion Notification (ECN)
>>     scheme that is similar to the original (or 'Classic') ECN approach.
>>     'Classic' ECN marking was required to be equivalent to a drop, both
>>     when applied in the network and when responded to by a transport.
>>     Unlike 'Classic' ECN marking, for packets carrying the L4S
>>     identifier, the network applies marking more immediately and more
>>     aggressively than drop, and the transport response to each mark is
>>     reduced and smoothed relative to that for drop.  The two changes
>>     counterbalance each other so that the throughput of an L4S flow will
>>     be roughly the same as a non-L4S flow under the same conditions.
>>     Nonetheless, the much more frequent control signals and the finer
>>     responses to them result in much more fine-grained adjustments, so
>>     that ultra-low and consistently low queuing delay (typically sub-
>>     millisecond on average) becomes possible for L4S traffic without
>>     compromising link utilization.  Thus even capacity-seeking (TCP-like)
>>     traffic can have high bandwidth and very low delay at the same time,
>>     even during periods of high traffic load.
>>     The L4S identifier defined in this document distinguishes L4S from
>>     'Classic' (e.g. TCP-Reno-friendly) traffic.  It gives an incremental
>>     migration path so that suitably modified network bottlenecks can
>>     distinguish and isolate existing traffic that still follows the
>>     Classic behaviour, to prevent it degrading the low queuing delay and
>>     low loss of L4S traffic.  This specification defines the rules that
>>     L4S transports and network elements need to follow to ensure they
>>     neither harm each other's performance nor that of Classic traffic.
>>     Examples of new active queue management (AQM) marking algorithms and
>>     examples of new transports (whether TCP-like or real-time) are
>>     specified separately.
>> The IETF datatracker status page for this draft is:
>> There are also htmlized versions available at:
>> A diff from the previous version is available at:
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at
>> Internet-Drafts are also available by anonymous FTP at:

Bob Briscoe