Re: [tsvwg] FW: New Version Notification for draft-johansson-cc-for-4g-5g-00.txt

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

Hi

And thanks for the review, comments inline below where applicable.

As a side note. Is there any interest to formalize some work around congestion control in IETF, it need not be limited to a 4G/5G perspective ? Today it seems to be more around documentation of established algorithm but is there a need to look a bit further ?. 

/Ingemar

> -----Original Message-----
> From: Smith, Kevin, (R&D) Vodafone Group
> [mailto:[e-mail]]
> Sent: den 19 oktober 2015 12:07
> To: Ingemar Johansson S; [e-mail]
> Subject: RE: [tsvwg] FW: New Version Notification for draft-johansson-cc-
> for-4g-5g-00.txt
> 
> HI Ingemar,
> 
> Thanks for drafting this, I found it useful. Here follows some feedback which I
> hope is of help.
> 
> All best,
> Kevin
> 
> Kevin Smith, Vodafone R&D
> 
> ===========
> 
> 2.1. PDCP
> 
> s/cell to terminal/cell-to-terminal
> 
> s/packets will be ensured to be delivered/packets are guaranteed to be
> delivered
> 
> Bufferbloat [REF]
> > missing REF..?
[IJ] Missed to ref to RFC7567

> 
> Clarifications:
> Depending on the available link throughput after the handover, an increased
> RTT may be experienced at a handover event.
> > the RTT may also decrease - is that equally likely?
[IJ] If you are and a standing queue due to a sending rate that is slighly too high and the throughput after handover is increase (quite likely) then the standing queue will vanish. What I was referring to is the short the break in data transfer at handover  that will cause a temporal delay spike.

> 
> In addition, a small temporal delay increase can occur as packet transmission
> is inhibited at the handover event.
> > that (should) not be the case for soft handover, in the LTE intra-RAT
> > scenario
[IJ] Need to look up that case actually

> 
> Because of the above it is a good practice to keep the amount of data in flight
> as small as possible, without sacrificing throughput.
> > amount of data means number of packets (per text in following paragraph)
> - maybe worth changing to 'number of packets in flight'
[IJ] Yes, probably needs some rephrasing
> 
> 2.2 RLC
> 
> s/in order/in-order
> 
> s/resources is allocated/resources are allocated
> 
> Clarification:
> higher terminal mobility means faster changing channel fading
> > should be 'faster changing channel conditions', because the channel can get
> weaker or stronger during mobility.
[IJ] Yes
> 
> 2.3 MAC
> 
> s/that decreased only/that decreases only
> 
> Clarification:
> soft decoding is utilized and the softbits of the first transmission and the
> retransmission are combined, hopefully with a successful result
> > Please can you explain 'soft decoding' and 'softbits' here?
[IJ] Yes, will try to added a reasonably short explanation

> 
> 2.3.1 Downlink scheduling
> 
> Addition:
> Suggest to note that each UE provides Channel Quality Input to downlink
> scheduling
> 
> 2.3.2 Uplink scheduling
> 
> Addition:
> CQIs are sent here too, so worth noting.
[IJ] OK
> 
> Clarification:
> HARQ RTT
> > worth adding a reference to HARQ
[IJ] OK
> 
> s/ACK traffic in uplink can also be delayed due to for instance lack of
>    signaling channel resources for instance if many terminals generate
>    ACK traffic that is so sparse that scheduling requests need to be
>    generated with high frequency./ACK traffic in uplink can also be delayed,
> due to for instance lack of
>    signaling channel resources. This could arise if many terminals generate
>    ACK traffic that is so sparse that scheduling requests need to be
>    generated with high frequency.
[IJ] OK

> 
> 3 4G and 5G evoluton
> 
> Clarification:
> Carrier aggregation means that additional carriers (possibly in very high
> frequency bands) are added.  Dual connectivity can combine two similar or
> different radio access technologies on lower layers (below IP).
> > these could be read as being identical ('aggregation' and 'combine'), please
> can you detail the difference?
[IJ] Yes, need to be explained better
> 
> The shorter TTI feature is part of the 5G standardization, it should
>    however be stated that the
> > sentence cut short
[IJ] Ok, realized that after submission :-), work in progress .....
> 
> 
> 4. Requirements for improved performance
> 
> Clarifications:
> The above considerations lead to a few things to consider when
>    congestion control is designed for optimal performance in 4G and 5G
>    networks:
> > is this section intended as advice for the origin server and the network
> operator? Because the network operator wants to ensure fair throughput for
> all connections in the cell, especially under congestion. So both actors are
> valid; If network operator 'holistic' congestion control is out of scope then
> that should be explicit.
[IJ] I would see it more as advice to developers of congestion control algorithms

> 
> Also a general point: it may be obvious, but worth mentioning/referring to a
> means to detect that the client is on a 4G/5G network as opposed to WiFi.
> 
> 
> ===========
> 
> -----Original Message-----
> From: tsvwg [mailto:[e-mail]] On Behalf Of Ingemar
> Johansson S
> Sent: 15 October 2015 06:08
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: [tsvwg] FW: New Version Notification for draft-johansson-cc-for-4g-
> 5g-00.txt
> 
> Hi
> 
> A new IETF draft is submitted in response to general discussion that for
> instance TCP Cubic is not an appropriate congestion control algorithm for LTE.
> The draft briefly outlines typical 4G access behavior on the PDCP, RLC and
> MAC  layers that can have an impact on transport protocol performance. The
> draft also outlines two relatively simple modifications to the Cubic congestion
> control.
> 
> /Ingemar
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: den 14 oktober 2015 20:17
> To: Ingemar Johansson S
> Subject: New Version Notification for draft-johansson-cc-for-4g-5g-00.txt
> 
> 
> A new version of I-D, draft-johansson-cc-for-4g-5g-00.txt
> has been successfully submitted by Ingemar Johansson and posted to the
> IETF repository.
> 
> Name:		draft-johansson-cc-for-4g-5g
> Revision:	00
> Title:		Congestion control for 4G and 5G access
> Document date:	2015-10-14
> Group:		Individual Submission
> Pages:		14
> URL:            https://www.ietf.org/internet-drafts/draft-johansson-cc-for-4g-
> 5g-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-johansson-cc-for-4g-5g/
> Htmlized:       https://tools.ietf.org/html/draft-johansson-cc-for-4g-5g-00
> 
> 
> Abstract:
>    This memo outlines the challenge that 4G and 5G access brings for
>    transport protocol congestion control and also outlines a few simple
>    examples that can improve transport protocol congestion control
>    performance in 4G and 5G access.
> 
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat