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

["Black, David" <[e-mail]>]

Hi Ingemar,

> 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 ?.

I would say there definitely is interest, e.g., see the rmcat WG and past work
on PCN.  A high bar/threshold generally applies to standards-track congestion
control work in the IETF, e.g., courtesy of the massive downsides of getting
it wrong.

Would you like some tsvwg time in Yokohama to provide a 4G/5G perspective
on what ought to be worked on and why, based on your draft? 

Thanks,
--David (as the tsvwg chair responsible for the Yokohama tsvwg agenda)


> -----Original Message-----
> From: tsvwg [mailto:[e-mail]] On Behalf Of Ingemar Johansson S
> Sent: Friday, October 23, 2015 10:23 AM
> To: Smith, Kevin, (R&D) Vodafone Group; [e-mail]
> Cc: Ingemar Johansson S
> Subject: Re: [tsvwg] FW: New Version Notification for draft-johansson-cc-for-
> 4g-5g-00.txt
> 
> 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