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

[Ingemar Johansson S <[e-mail]>]

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/
>