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

[Bob Briscoe <[e-mail]>]

Ingemar,

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

Cheers


Bob

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
> (https://tools.ietf.org/wg/avtcore/draft-ietf-avtcore-cc-feedback-message/ )
> 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
> Quote "An L4S AQM SHOULD NOT
>     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 <[e-mail]> On Behalf Of [e-mail]
>> Sent: den 16 november 2020 03:07
>> To: [e-mail]
>> Cc: [e-mail]
>> 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:
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-12
>> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-12
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ecn-l4s-id-12
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>

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