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

[Bob Briscoe <[e-mail]>]

Ingemar,

As promised, here's my comments. They are a mix of suggested 
improvements to the draft, suggested improvements to 5G, or requests for 
clarification. I also agree with all Kevin Smith's comments, so I didn't 
repeat any.
[Sorry for delay - I had to find time to re-type after losing my review 
during a power outage]

_*Context questions.*_*
*Q1. Is this exercise treating the 5G specs solely in read-only mode? 
Or, if some useful design suggestions arise, is there any chance that 
the 3GPP might take them on board, given 5G is not fully baked yet?

It's great that you have taken this initiative. Does the 3GPP ever 
formally ask the IETF for comments on its ideas for each new generation 
of radio? Given the layers above can be thought of as the 'customers' of 
the 3GPP, and these 'customer' layers are pretty much all maintained by 
the IETF, it would seem essential (and courteous) for the 3GPP to ask 
for customer comment, not least to co-ordinate with whatever future 
plans the IETF might have for the higher layers.

Q2. What are your plans for this draft? Are you asking for adoption? And 
if so, in which WG or RG? ICCRG looks the most appropriate, given the 
charters of all the IETF cc WGs (TSVWG, TCPM, RMCAT, etc) are scoped on 
just a subset of your doc.

_*Section by Section Review*_*
*
*All sections**
*
The document generally talks about the LTE protocol stack as if data is 
travelling down it. Are you implying that most sources of buffering 
delay are at the sending end, and the feedback end is pretty 
unencumbered by delays? I think it would be useful to explicitly say 
something about this (whether true or not), to explain why only one 
direction of travel is discussed in the doc.

*2.1 PDCP layer**
***
PDCP also ensures that all
packets are delivered in order up to higher layers.
I think this means "in the order sent into the link (PDCP) layer". This 
ought to be clarified, otherwise, when writing in the context of a layer 
4 audience, it might be assumed this means in the order sent by the 
original transport layer source.

    keep the amount of data in flight as small as possible, without 
sacrificing throughput.
Is this just a rather convoluted way of saying "keep the RTT as low as 
possible"? (which in turn implies keeping queuing delay as low as 
possible assuming you cannot influence the physical path.) Or were you 
trying to make a more subtle point? - if so, it was lost on me.

    Reliable delivery at handover may however be turned off or is simply 
not implemented,
It would be useful if you could give a feel for roughly how often (in %) 
these cases hold.

*2.2 RLC layer*

    role ... is to ensure that packets are delivered in order up to the 
higher layers
Eh? The PDCP section just said it did ordering. And the rest of the RLC 
section talks exclusively about buffering delays necessary while filling 
transport blocks. If ordering is the role of both layers, surely one 
will have nothing to do once the other has got everything in order?

    varying size of the available transport
Nit: Given 'transport' means e2e for the audience of this draft, pls use 
bearer or somehow disambiguate this word.


Gap#1: In the draft, it seems like transport blocks arrive by magic, to 
be filled by data buffered in the RLC layer. To understand the delay 
compromises here, I think the draft needs to explain what determines how 
much transport block capacity each flow is given, and how they can 
influence it. In 3G, I believe that the transport layer could ask the 
radio resource controller to change radio resource allocation. Is this 
the same in 4G & 5G? Does the backlog of the buffer into the RLC layer 
have any automatic influence over allocation of available resources? I 
assume traffic class can also be used to influence allocation.

Gap#2: In a 3G stack, the RLC layer multiplexes all the active 
application streams into MAC layer transport block by dicing up buffered 
packets and packing the pieces into each transport block. Then, at the 
other end of the link, each piece has to be held until the rest of the 
packet arrives. This sacrifices delay for bandwidth efficiency. Is this 
still done in 4G and 5G? If so, it would be good to write about mux 
delay in the draft too.

*2.3 MAC layer**
*
    the maximum number of retransmissions is configurable

Wouldn't it be better to set a limit on the /time/ spent retransmitting, 
so it would automatically give up with less retransmissions for longer 
transmission distances?

s/only checks for the presence on download data only at regular intervals/
  /only checks for the presence of download data at regular intervals/

*2.3.2 Uplink scheduling**
*
    The scheduling request does not indicate how many bytes there are in 
the uplink queue.
Seems like a bad omission. Is there a reason? If there are less bytes 
queued than the base station's grant, surely it would be useful for the 
base station to know, so that it can grant more to something else while 
the previous short transmission is completing.

You say that when HARQ breaks up a sequence of ACKs, it can also trigger 
"coalescing issues". I can understand that it could cause ACK 
compression, but are you implying something coalesces the ACKs or the 
subsequent data? What does the coalescing? Similarly, in the last para 
of 2.3.2 you say "Reduced ACKs can unfortunately cause coalescing." and 
again I'm not sure what is coalescing what here.

There could be a positive side to the interaction between ACK clocking 
and link aggregation, at least for long-running flows. This has been 
observed in 802.11n WiFi where the buffering and aggregation of multiple 
ACKs into one transmission grant tend to lead the sender to bunch 
multiple data segments so that they all nicely fill one transmission 
grant in the other direction [Showail14]. As long as the transmission 
grant does not wait for more data (which unfortunately I don't think is 
the case in 3G/4G/5G), this could be good for bandwidth utilisation of 
elephants and latency of mice, including when they are mixed.


[Showail14] Showail, A., Jamshaid, K. & Shihada, B., "WQM: An 
Aggregation-aware Queue Management Scheme for IEEE 802.11N Based 
Networks," In: Proceedings of the 2014 ACM SIGCOMM Workshop on Capacity 
Sharing Workshop CSWS '14 pp.15-20 ACM (2014)
<http://dl.acm.org/citation.cfm?id=2630097>

*3.  4G and 5G evolution**
*
s/a explicit/an explicit/

*4.  Requirements for improved performance**
*
s/bufferbloat/buffer/

*5.  Congestion control examples
*
Regarding Hybrid Cubic using OWD measurements, I have seen a paper 
(under submission) about getting delay-based congestion controls (e.g. 
LEDBAT or CAIA Delay Gradient) to interwork with AQMs with various low 
delay targets. It's not in the context of cellular networks, but I'll 
try to remember to point it out once it gets published.

*5.1 HyStartRestart**
*
s/algorithm used/algorithm is used/

In the new code, it would be useful to explain why the second test 
before doubling ssthresh, ie, the test for how long it has been since 
the last hyrestart. Also, in the header definitions, if you intend there 
to be constraints on the relation between N_RTT_HYRESTART and N_RTT_LOW 
(e.g.  N_RTT_HYRESTART > N_RTT_LOW) you ought to say, because people 
will try other values.

Rather than the rather arbitrary wait before an arbitrary doubling of 
ssthresh, wouldn't it be better to continually increase ssthresh (not 
necessarily linearly) the longer the RTT has remained only just higher 
than the min RTT?

(BTW, surely the main problem with this modification to HyStartRestart 
is that is requires a number of round trips to reduce delay - a sort-of 
oxymoron.)

*5.2.  Hybrid Cubic*

    Furthermore it is assumed than the timestamp clock frequency in
    sender and receiver are identical or that the sender can infer the
    timestamp clock frequency of the receiver and recompute timestamp
    values based on this information.

Recently on tcpm I sent you a pointer to the chirping paper Mirja & I 
did, which also made this assumption. Partly prompted by that, Richard 
Scheffenegger tried to get people interested in standardising use of the 
timestamp option on a SYN to negotiate stuff like timer resolution. I 
don't think it went anywhere. Do you think we ought to revitalise that? 
You mention inference - have you tried that - are there cases where it 
doesn't work?


That's it. Thanks again for the draft. V useful.



Bob



On 15/10/15 06:08, Ingemar Johansson S wrote:
> 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
>


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