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

[Bob Briscoe <[e-mail]>]

Ingemar,

On 04/11/15 13:27, Ingemar Johansson S wrote:
>
> Hi
>
> And thanks for the review, comments/answers/questions inline below
>
> /Ingemar
>
> *From:*Bob Briscoe [mailto:[e-mail]]
> *Sent:* den 29 oktober 2015 18:54
> *To:* Ingemar Johansson S; [e-mail]; [e-mail]; [e-mail]
> *Subject:* Re: [tsvwg] FW: New Version Notification for 
> draft-johansson-cc-for-4g-5g-00.txt
>
> 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?
>
> [IJ] Guess it depends, need to say that I probably the small cog in 
> the wheel. I would say that a lot of the standards work in IETF has 
> been picked up by 3GPP and, I cannot say what will happen in the 5G 
> context.
>
> 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.
>
> [IJ] What you say makes much sense. I guess there is some natural 
> leakage between 3GPP and IETF as many of the IETFers are also active 
> in 3GPP standardization. I don’t have full insight in the formal 
> relation between 3GPP and IETF in these areas, not sure if that need 
> to be better, but if that is the case, then it is probably a question 
> for the area directors. Need to say that even though the formal 
> channels are scarce it does probably not mean that 3GPP ignores IETF 
> or what happens above IP in general. For instance the recent work 
> around TCP RACK raises the question if it is necessary that LTE 
> default radio bearers ensure in order delivery.
>
I suspect that 3GPP radio resource control people do not cross-fertilize 
much with the IETF.
So maybe it is as much a question of how to co-ordinate between these 
radio people and L4, which I would imagine is as much a problem within 
3GPP as between 3GPP and IETF.
>
>
>
> 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.
>
> [IJ] First objective is to get an increased interest in congestion 
> control algorithm work in the IETF. Traditionally this kind of work 
> seem to be more in the terms of conference papers in e.g. Sigcomm, the 
> benefit with having such work in IETF is that input from people with a 
> wider expertise area (including 3GPP experitise) can give algorithm 
> proposals that work well for a wider set of access types. The work 
> around Cubic is a first good step as is the work around DCTCP. What I 
> wonder is if it feasible to take this a bit further ? I would too 
> believe that the current doc fits better in ICCRG.  The algorithm 
> examples are just.. examples. More fruitful work is probably to 
> document different access types and from there derive a set of best 
> current practices for congestion control algorithms
>
I'm sure the iccrg chairs would like this to happen. And initiatives 
like yours to come with proposals to propose specific code to take 
account of L2 I think generate the right level of dialogue.
>
>
>
> *_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.
>
> [IJ] The feedback path is encumbered by delays, it is perhaps not that 
> clear but section 2.3.2 implies that delay (variation) in uplink will 
> affect the ACKs for downlink data traffic. That said, the difference 
> in DL/UL traffic is today something like 10:1 and that is probably one 
> reason why one can get the feeling that the draft is slanted towards 
> downlink data traffic, this may however change with time as more 
> machine type traffic may enter the system.
>
I was thinking more in terms of up the stack vs. down the stack, not 
uplink/downlink. I.e. for both cases:
* downlink direction: are there any buffering concerns coming up the 
stack at the UE, or on the feedback back-channel from the UE?
* uplink direction: are there any buffering concerns coming up the stack 
at the eNodeB, or on the feedback back-channel from the eNodeB?

For instance, in the UE, perhaps one app blocking the read of another 
due to the way {3-5}G multiplexes different streams into the same PDCP 
frames?
>
>
>
> *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.
>
> [IJ] Yes, you are right , reordering can still occur e.g. in the 
> wireless backhaul
>
>
>
> 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.
>
> [IJ] No, it is exactly as you describe below
>
>
>
> 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.
>
> [IJ] I don’t believe that it is possible to give a figure as this is 
> vendor specific.
>
>
>
> *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?
>
> [IJ] RLC handles ordering due to various MAC layer failures. PDCP 
> handles ordering  when handover occurs
>
>
>
> 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.
>
> [IJ] OK
>
>
>
>
> 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.
>
> [IJ] Will updated with more detail
>
>
>
> 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.
>
> [IJ] OK, will add more info
>
>
>
> *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?
> [IJ] Possible, 4G specifies a limit to the number of retransmissions, 
> in practice it can be translated to time as each retransmission is 8ms 
> later.
>
I didn't realise it was independent of link-RTT. Then the more basic 
question is why is it independent of link-RTT? Surely on a short link it 
can assume that it needs to retransmit more quickly than on a long link?

You can see that my question was assuming that retransmission happened 
more often on a short link, then I was saying it should still be allowed 
the same amount of time to keep retrying (so on a short link it would be 
allowed to retransmit more times before giving up, but the max delay 
would be the same).

8ms! I was assuming it would be rather much less than that. Surely a 
link-layer ACK could never take that long if the frame was going to get 
through.
>
>
> s/only checks for the presence on download data only at regular intervals/
>  /only checks for the presence of download data at regular intervals/
> [OK]
>
>
> *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.
> [IJ] It is a design choice. A buffer status report is more bulky, a 
> scheduling request is just one bit.
>
>
> 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.
>
> [IJ] What I can see in simulations is that the ACK compression leads 
> to coalescing which further can increase jitter.
>
I still don't understand. The question was "What is coalescing what?"
>
>
> 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>
> [IJ] Interesting ,will look at it, not sure though that it will work 
> that well with 4G (cant say anything about 5G), in 4G the transmission 
> grants can vary quite a lot over short time spans.
>
>
> *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.
>
> [IJ] Sounds interesting , looking forward to see the paper.
>
>
>
> *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?
>
> [IJ] Yes, could be an option
>
>
>
> (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.)
>
> [IJ] Yes, have tried some more experiments with this algorithm. And I 
> am getting more hesitant. The problem is that when I add more noise 
> (modeling of small objects traffic) into the system simulation, then I 
> also get more delay jitter and the delay detection algorithm in 
> HyStart is notoriously sensitive to delay jitter.
>
>
>
> *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?
>
> [IJ] Yes, actually wondered what happened to Richards draft. I only 
> briefly tried out the inference algorithm with a TCP LEDBAT 
> implementation 
> (https://github.com/silviov/TCP-LEDBAT/blob/master/src/tcp_ledbat.c). 
> I recall that it took a while to converge. Also I am not sure here. Is 
> Hz in e.g a linux stack fixed. ?
>
I believe so. But I don't know about embedded systems etc.

Cheers



Bob
>
>
>
>
> 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]>  [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 Briscoehttp://bobbriscoe.net/

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