Update on the QCI 6 vs. 7: we have had our system set for QCI 7 on the default bearer for the past few days, and I can tell you that it has made no difference. Under similar load conditions, we can still experience delays of 200-300ms (and on rare occasions, even more) on packet delivery.
Not sure why. I would also, as you said, have guessed that it would try harder to deliver packets sooner (at the expense of something else), and if a packet was simply unable to be delivered within the delay budget that it would just be dropped. Near as I can tell, the system is behaving exactly the same before vs. after the change, so I guess I don't understand how the "packet delay budget" works on LTE. -- Nathan From: [email protected] [mailto:[email protected]] On Behalf Of Adam Moffett Sent: Wednesday, February 01, 2017 8:07 AM To: [email protected] Subject: Re: [Telrad] QCI levels and latency Ok thanks. Great info. How large did you make your dedicated management bearer? I did 256k, but now I'm thinking it's not big enough. I still can't say anything authoritative about what would happen with QCI 6 vs QCI 7, but presumably if the system couldn't fit a packet into the delay budget it would have to drop it. We could make some guesses about the ramifications of that, but I think you'll have to test to know for sure. If I'm guessing, then I'd guess the only time you can't hit the PDB is when there's congestion, so most of the time you wouldn't see a difference. When there is congestion I think you'd see less throughput on individual TCP connections....though maybe you would see lower RTT as well, and total system throughput might not be affected. I am literally making that up, so take it for what it's worth LOL. ------ Original Message ------ From: "Nathan Anderson" <[email protected]<mailto:[email protected]>> To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>; "Adam Moffett" <[email protected]<mailto:[email protected]>> Sent: 1/31/2017 6:19:43 PM Subject: RE: [Telrad] QCI levels and latency Yes, that should be enough for specifically prioritizing management traffic itself on the uplink (like accessing the UE web interface, ping responses from the CPE, presumably also things like SNMP and TR-069 responses, etc.). If you need to prioritize certain customer upload traffic then you will also need to either 1) check the DATA box (which is, I believe, the default) on the DSCP page (7000) and then put the dedicated bearer's DSCP value in there as well (which will prioritize ALL traffic, and which likely isn't what you want unless this is a special customer and the UL MBR and UL GBR specified on the default bearer is sufficient for the use of that connection), or 2) UNcheck the DATA checkbox (because if it is checked, it will override the DSCP in the IP header of ALL user traffic, even if the value is set to 0), which will allow IP packets originating from the user to proceed through the UE with the DSCP mark untouched. At this time, unfortunately the CPE8000 cannot have its management uplink traffic prioritized without also unilaterally steamrolling the DSCP mark on user-generated traffic (MGMT and DATA DSCP override cannot be enabled and disabled independently!). I have brought this to Telrad's attention, so hopefully that will be addressed in a future firmware version. -- Nathan ________________________________________ From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> on behalf of Adam Moffett <[email protected]<mailto:[email protected]>> Sent: Tuesday, January 31, 2017 1:13 PM To: [email protected]<mailto:[email protected]> Subject: Re: [Telrad] QCI levels and latency I don't have an answer to the question on QCI 7 vs QCI 6. I was curious how you configure the UE to classify upload traffic. I noticed the default config on both 7000 and 8000 is set to use DSCP 6 for management, so I made my dedicated bearer use DSCP 6. Is that enough, or is there more to it? I could probably read the manual and figure this out, but I was just stabbing at it in my spare time :) ------ Original Message ------ From: "Nathan Anderson" <[email protected]<mailto:[email protected]>> To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Sent: 1/31/2017 3:20:34 PM Subject: [Telrad] QCI levels and latency All, We recently implemented iPCRF on our EPC to great effect. We added a QCI 1 profile that we apply to our dedicated bearer, and are prioritizing our VoIP service using that. So that we can easily see and verify the effectiveness of this, we also started sending ICMP over the same dedicated bearer. Average latency and jitter to CPEs dropped like a rock right after we did that, so it is clearly working. When our ENBs start to become moderately busy, we still notice that RTT for traffic on the default bearer can become both exceptionally latent and jittery. This is easy to see if we run a constant ping to a CPE and then stop prioritizing ICMP to that CPE in the middle of the ping test. Ping jitter goes up significantly almost immediately. When we prioritize ICMP, all we end up doing is masking that problem. Unfortunately, release 6.6 only allows for one dedicated bearer, so we can't classify different types of traffic across multiple QCI levels in order to try to help deal with this better. But after looking at the various QCI levels that are defined in the LTE spec (https://en.wikipedia.org/wiki/QoS_Class_Identifier), I am wondering if there isn't a short-term answer to this problem while we wait for multiple dedicated bearer support. Specifically, I see that each level also has a defined "packet delay budget". QCI 6, the default pick for the default bearer, has a PDB of 300ms. What would happen if we were to, say, switch to using QCI 7, which has a PDB of 100ms, for our default bearer? Would we actually see an overall improvement in RTT? And if so, would it be at the expense of anything/what would be the downside(s)? (For example, would overall throughput end up taking a hit because it is trying to service UEs less efficiently so that it can make good on the latency budget?) I'm curious to know if anyone has tried this. Thanks, -- Nathan Anderson First Step Internet, LLC [email protected]<mailto:[email protected]> _______________________________________________ Telrad mailing list [email protected]<mailto:[email protected]> http://lists.wispa.org/mailman/listinfo/telrad _______________________________________________ Telrad mailing list [email protected]<mailto:[email protected]> http://lists.wispa.org/mailman/listinfo/telrad
_______________________________________________ Telrad mailing list [email protected] http://lists.wispa.org/mailman/listinfo/telrad
