idnits 2.17.1 draft-degermark-crtp-cellular-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC-2508]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 10, 1999) is 8896 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC-768' is defined on line 668, but no explicit reference was found in the text == Unused Reference: 'RFC-1144' is defined on line 675, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 1889 (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 2509 (Obsoleted by RFC 3544) -- Possible downref: Non-RFC (?) normative reference: ref. 'WCDMA' Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Mikael Degermark, Lulea University 2 INTERNET-DRAFT Hans Hannu, Ericsson 3 Expires: June 2000 Lars-Erik Jonsson, Ericsson 4 Krister Svanbro, Ericsson 5 Sweden 6 December 10, 1999 8 CRTP over cellular radio links 9 11 Status of this memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/lid-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This document is an individual submission to the IETF. Comments 32 should be directed to the authors. 34 Abstract 36 This document evaluates the performance of a header compression 37 protocol for RTP, CRTP [RFC-2508], over links built on cellular radio 38 access technology. The key characteristics affecting CRTP performance 39 over such links are the high error rates and the relatively long 40 roundtrip time over the link. 42 Bandwidth is typically expensive in cellular radio access networks, 43 saving a single octet per voice packet can be equivalent to saving 44 many billion dollars in deployment since fewer base-stations are 45 needed. This is beneficial for operators as well as end-users who can 46 get cheaper wireless IP telephony service. 48 CRTP performance is evaluated for two kinds of link layers operating 49 over a realistic radio channel with high bit-error rates. Two main 50 conclusions are drawn. The first is that CRTP does not perform well 51 for this type of link. The second is that in high-error environments 52 it is very beneficial to have a checksum covering the compressed 53 header only, not the payload, so that the decompressor sees all non- 54 damaged headers. When a strong checksum covers the entire link layer 55 frame, header compression performs badly since too many headers are 56 discarded due to damaged payloads. 58 TABLE OF CONTENTS 60 1. Introduction..................................................3 62 2. Header compression............................................3 64 3. Link layers...................................................5 65 3.1. PPP in HDLC-like framing..............................5 66 3.2. Link layer with partial checksum......................6 68 4. Description of simulations....................................6 69 4.1. Simulated scenario....................................6 70 4.2. The cellular link and the back channel................7 72 5. Frame error rates (FER).......................................8 74 6. Evaluation of CRTP for cellular radio links...................8 75 6.1. An ideal header compression scheme....................9 76 6.2. CRTP without Twice...................................10 77 6.3. CRTP with Twice......................................12 78 6.4. Loss patterns........................................13 79 6.5. Using only COMPRESSED_NON_TCP packets................16 80 6.6. Using periodic refreshes instead of requests.........17 82 7. Conclusions..................................................19 83 7.1. How to improve CRTP performance......................20 85 8. Authors addresses............................................21 87 9. References...................................................21 89 1. Introduction 91 With IP telephony gaining momentum and cellular telephony having 92 hundreds of millions of users, it seems inevitable that some future 93 wireless telephony systems will be based on IP technology. What we 94 today know as cellular phones may in addition to telephony and video 95 have IP stacks, web browsers, email clients, networked games, etc. If 96 based on IP, the telephony service will be much more flexible than 97 today. This document concentrates on the problem of providing a good 98 IP solution for speech, but it is clear that applications for video, 99 games, etc, will also have to be supported. 101 It is vital for cellular phone systems to use the radio resources 102 efficiently in order to support a sufficient number of users per 103 cell. Only then can deployment costs be kept low enough. It will also 104 be important to provide sufficiently high quality voice and video. In 105 particular the voice service should be as good as what users expect 106 from the cellular phone systems of today. A lower quality may only be 107 accepted if costs are significantly lower than today. 109 The radio channels used in cellular systems have very high bit-error 110 rates (BER) due to shadow fading, multipath fading, and continuous 111 mobility. The radio signals of one user will interfere with the radio 112 signals of other users, so with the desired number of users per cell, 113 BERs will be high. Even after error correcting channel coding, the 114 remaining BER can be as high as 1e-3 (one in 1000) or even 1e-2 (one 115 in 100) in bad environments. 117 The only cost efficient way to achieve sufficient voice quality over 118 such channels is to use clever speech encoders and decoders that can 119 tolerate some damage to the encoded sound data. It is not feasible to 120 use a link layer that delivers all data reliably through an ARQ 121 scheme with link-local retransmission. High delays would be the 122 result. If the long maximum delays caused by an ARQ scheme were 123 acceptable, it would be better to spread the signal over time in 124 order to reduce the BER, rather than using an ARQ protocol. Neither 125 is it feasible to have the link layer discard all damaged frames. The 126 large fraction of discarded frames would result in insufficient 127 speech quality. 129 Unless explicitly stated otherwise, the numbers and figures presented 130 in this document are for IPv4 [RFC-791], not IPv6 [RFC-1883]. 132 2. Header compression 134 Speech data for IP telephony will most likely be carried by RTP [RFC- 135 1889]. A packet will then, in addition to link-layer framing, have 136 an IP header (20 octets), a UDP header (8 octets), and an RTP header 137 (12 octets) for a total of 40 octets. With IPv6, the IP header is 40 138 octets for a total of 60 octets. The size of the payload depends on 139 the speech encoding used and the packet rate; it can be as low as 15- 140 20 octets. 142 From these numbers it is obvious that the header size must be reduced 143 for efficiency reasons. A proposed standard for compressing 144 RTP/UDP/IP headers over low-speed serial links, CRTP, has recently 145 been approved by the IESG [RFC-2508, RFC-2507], together with a way 146 to negotiate parameters for header compression over PPP [RFC-2509]. 147 With CRTP, compressed headers are as small as 2 octets if the UDP 148 checksum is disabled. 150 CRTP uses delta encoding where compressed headers carry differences 151 from the previous header. The decompressor maintains state, known as 152 the context, that represents what the header looks like, how it is 153 expected to change, etc. The differences carried in each compressed 154 packet updates the context, and thus loss of a packet will bring the 155 context of the decompressor out of sync with the compressor as it is 156 not updated correctly. 158 CRTPs mechanism for bringing the decompressor context in sync with 159 the compressor relies on messages from the decompressor reporting its 160 state to the compressor. Such CONTEXT_STATE messages cause the 161 compressor to send packets with more information in their headers to 162 update the context of the decompressor: either FULL_HEADER packets 163 with 40 octet headers (60 for IPv6), or COMPRESSED_NON_TCP packets 164 with compressed UDP/IP headers but a complete RTP header. Headers in 165 COMPRESSED_NON_TCP packets are 17 octets if the UDP checksum is 166 disabled, and 19 octets otherwise (15 and 17 octets for IPv6, 167 respectively). 169 CRTP uses a link sequence number, incremented by one for each packet 170 with a compressed header, to detect lost packets. The link sequence 171 number ranges between 0 and 15. Gaps in the sequence number space 172 triggers the context repair mechanism outlined in the previous 173 paragraph. 175 High BERs will cause the repair mechanism to be triggered often, 176 causing many FULL_HEADER packets or COMPRESSED_NON_TCP packets to be 177 sent, which consume extra bandwidth. With a long roundtrip time over 178 the link, each damaged packet can cause several subsequent packets to 179 be discarded due to mismatching contexts. 181 The "Twice" mechanism proposed for compressed TCP [RFC-793] headers 182 in [RFC-2507] and also for CRTP in [RFC-2508] can often repair the 183 context and avoid some of the loss caused by mismatching contexts. 184 The assumption behind the "Twice" mechanism is that the delta of a 185 lost CRTP packet is often the same as the delta of the subsequent 186 packet. An attempt to repair the context by applying the delta twice 187 will therefore often succeed. Successful repairs are detected by a 188 matching transport-layer checksum. 190 3. Link layers 192 When evaluating CRTP, the link layer must be considered. We will use 193 two different link layers. One is PPP in HDLC-like framing [RFC- 194 1662], which has a 16/32-bit CRC covering the entire frame. This 195 implies that all damaged frames will be discarded at the link layer 196 since the checksum will fail. It is possible to change the networking 197 code to have such frames delivered, but then it is pointless to have 198 the checksum in the first place and a framing scheme without a 199 checksum would be a better solution. 201 For header compression purposes it is important that headers are not 202 damaged over the link. As outlined in the introduction, however, 203 damage to the payload is often acceptable to the (speech) decoder of 204 the application. It would therefore make sense to have a checksum 205 which only covers the header part of a packet. That should increase 206 the number of headers seen by the decompressor and improve header 207 compression performance. The second link layer we use for evaluation 208 purposes is an imaginary such link layer, henceforth called the Link- 209 Layer with Partial Checksum (LLPC). 211 3.1. PPP in HDLC-like framing (HDLC) 213 PPP typically uses HDLC-like framing [RFC-1662]. With a 16-bit 214 checksum and compressed Address and Control fields, frames carrying 215 CRTP, COMPRESSED_NON_TCP, or FULL_HEADER packets have the following 216 format. 218 1 1 2 219 +----------+----------+-------------+----------+----------+ 220 | Flag | Protocol | Information | FCS | Flag | 221 | 01111110 | 8 bits | * | 16 bits | 01111110 | 222 +----------+----------+-------------+----------+----------+ 224 The Flag only occurs once between frames if they are sent back-to- 225 back, so the amortized framing overhead is 4 octets per frame. The 226 checksum (FCS) is calculated over the Protocol field and the 227 Information field (payload), but not the Flags or the checksum 228 itself. 230 Any errors anywhere in the frame will cause the FCS to fail. The 231 frame will then be discarded. 233 3.2. Link-layer with partial checksum (LLPC) 235 This is an imaginary framing scheme derived from the HDLC-format in 236 3.1 by adding a one-octet Length field. 238 1 1 1 2 239 +----------+----------+----------+-------------+---------+----------+ 240 | Flag | Length | Protocol | Information | FCS | Flag | 241 | 01111110 | 8 bits | 8 bits | * | 16 bits | 01111110 | 242 +----------+----------+----------+-------------+---------+----------+ 244 The Length field indicates how many octets of the payload that are 245 covered by the FCS. It can have values from 0 to 255. The FCS covers 246 the Length and Protocol field plus as many octets in the beginning of 247 the Information field as indicated by the Length field. The value of 248 the Length field must not make the FCS extend over the FCS field. 249 When sending a FULL_HEADER packet, the Length field would have the 250 value 40, since it should protect the IP, UDP, and RTP headers. When 251 sending a minimal COMPRESSED_RTP packet, the Length field would have 252 the value 2. The amortized framing overhead for LPC is 5 octets per 253 frame. 255 Any errors in the Flag, Length, Protocol, FCS, or the initial Length 256 octets of the Information field will cause the FCS to fail. The frame 257 will then be discarded. Errors in the Information field after the 258 first Length octets will not affect the FCS and will not cause the 259 frame to be discarded. 261 4. Description of simulations 263 Section 4.1 describes the simulated scenario and 4.2 elaborates on 264 the properties of the cellular link and the back channel. 266 4.1. Simulated scenario 268 A source generates RTP packets containing speech data and sends them 269 across the Internet to an end-system. The end-system is connected to 270 the Internet over a cellular link over which the RTP stream is 271 compressed using CRTP. 273 Compression 274 Source point End-system 275 _____ ________ +-------+ 276 / back channel\ | | 277 +----+ +----+/ \+----+ | 278 | |--------->---------| HC |-------->--------| HD | | 279 +----+ Internet path +----+ Cellular link +----+ | 280 (loss) | | 281 +-------+ 283 Figure 0: Simulated scenario 285 Over the Internet path there are uniformly distributed losses which 286 influence the efficiency of CRTP mechanisms, and especially the 287 "Twice" mechanism. 289 Over the Cellular link one of the framing protocols of section 3 290 carry the packets. The radio channel of the cellular link is 291 simulated accurately for various BERs and represents fairly bad, but 292 realistic, conditions. The roundtrip time can be varied. 294 The compressor (HC) at the compression point compresses RTP/UDP/IP 295 headers according to CRTP, and sends them over the cellular link to 296 the decompressor (HD). When HD detects that the context is out of 297 sync, it will send CONTEXT_STATE messages back to HC over the back 298 channel. 300 The speech source generates packets with payloads of a fixed size, 16 301 octets (representing the smallest reasonable payload size), at a rate 302 of 50 packets per second (20 ms worth of sound data per packet). 303 Silence suppression is used. The lengths of talk spurts and the 304 silent intervals between them are both exponentially distributed with 305 an expected length of 1 second. Loss over the Internet path due to 306 congestion is uniformly distributed. This loss pattern is reasonably 307 accurate since packet intervals are relatively long compared to 308 congestion related loss events. 310 4.2. The cellular link and the back channel 312 The cellular link is simulated accurately using a realistic radio 313 channel model [WCDMA] and adding channel coding. The reported bit 314 error rates, BER, are always the BERs after channel coding, i.e., the 315 BER seen by the link layer. 317 The interesting BERs for cellular systems are in the range between 318 1e-3 (1/1000) and 1e-6 (1/1000000). Circuit-switched cellular voice 319 transmission can deliver acceptable speech quality down to around 320 1e-2, while the systems become expensive at BERs much less than 1e-6. 322 The compressor repairs the decompressor context after feedback in the 323 form of a CONTEXT_STATE message from the decompressor. This means 324 that the roundtrip time over the link determines the speed of the 325 repair mechanism. The back channel used in our simulations never 326 damages CONTEXT_STATE messages. 328 5. Frame error rates (FER) 330 Frames can have errors due to damage over the link. This kind of 331 damage can be further classified into 333 a) header damage: damage to parts of the frame that are 334 important for header compression purposes. This is the 335 framing plus the compressed or full header. 337 b) payload damage: damage to other parts of the frame. Such 338 damage may or may not cause the frame to be unusable by the 339 speech decoder, depending on the coding and the location of 340 the damage. Also, it may or may not cause the entire frame 341 to be discarded depending on the framing format. 343 Frames can also be damaged because the decompressor fails to 344 reconstruct a correct header. That can of course be caused by a), but 345 also by 347 c) context damage: the context of the decompressor being out of 348 sync with the context of the compressor. This is caused by 349 delta information being lost due to a) or b). 351 For HDLC, both header damage and payload damage will cause the frame 352 to be discarded, which will increase the rate of frames discarded due 353 to context damage. 355 For LLPC, payload damage will not cause the frame to be dropped 356 before reaching the decompressor, which will reduce the number of 357 frames discarded due to context damage. Whether or not payload 358 damage causes the frames to be unusable for generating speech is not 359 related to header compression performance. We expect, however, that 360 most speech decoders will be able to utilize information in frames 361 with payload damage. 363 6. Evaluation of CRTP for cellular radio links 365 6.1. An ideal header compression scheme 367 In order to have a reference point, we first simulated an ideal 368 header compression scheme. The ideal header compression scheme can 369 always compress the header down to a total of 2 bytes and will never 370 fail at decompression, i.e., no frames will ever be discarded due to 371 context damage. Such a scheme is probably not achievable, but it 372 gives us something to compare the real CRTP against. 374 Figure 1: FER for Ideal scheme for HDLC and LLPC 376 As can be seen in figure 1, for a BER of 1e-3 the FER is 1-2 % for 377 both link layers. LLPC is marginally better. At 5e-3 there is a 378 significant difference between HDLC (7.5% FER) and LLPC (4% FER). 379 Loss over the Internet path does not affect the ideal header 380 compression scheme at all, and is not included in the reported FER. 382 There is no context damage for the ideal scheme. The difference 383 between the HDLC and LLPC curves show how many packets with payload 384 damage only there are: around 0.3% for a BER of 1e-3. 386 With some handwaving and contemplation of packet sizes and checksum 387 coverage, one can argue that LLPC should give a FER which is roughly 388 7/23 (30%) of the FER for HDLC if errors were uniformly distributed. 389 They are not, however, and it seems that LLPC in fact gives FERs that 390 are 55-60% of the FERs for HDLC. 392 6.2. CRTP without Twice 394 With a roundtrip time over the link corresponding to around 120 ms (a 395 realistic value), the slowness of the context repair mechanism will 396 multiply link layer related loss by a large factor. Figure 2 shows 397 CRTP performance for HDLC, while Figure 3 shows CRTP performance for 398 LLPC. The ideal curves have been included for reference. The percent 399 numbers indicate how much loss there were over the Internet path. The 400 plots for CRTP with Twice are discussed in the next subsection. 402 In figures 2 and 3 one can see that for a BER of 1e-3, CRTP gives a 403 FER of 8% with HDLC while with LLPC the FER is 5%. Given the 404 performance of the ideal scheme, it is clear that most of this loss 405 is due to context damage. 407 The average header size will increase with increasing loss over the 408 Internet path, since the delta between consecutive packets will then 409 often be different and more data need to be sent to represent the new 410 delta. A single loss over the Internet path will typically cause the 411 following two compressed headers to have three and two extra octets, 412 respectively. When one out of 10 packets are lost over the Internet 413 path, that would add 5 octets to the remaining 9 headers. The average 414 header size then increases with 5/9 octets (0.56 octets). 416 Figure 4 shows the average header size plotted against BERs, for 417 varying loss over the Internet path. At low BERs, HDLC and LLPC both 418 give an average header size of just over 2 octets when there is no 419 loss over the Internet path. When there is 10% loss over the Internet 420 path, both give an average header size just over 2.5 octets. This is 421 consistent with the expected increases in header sizes due to 422 different deltas after losses over the Internet path. 424 Figure 2: FER for CRTP, CRTP with Twice, and Ideal for HDLC 426 Figure 3: FER for CRTP, CRTP with Twice, and Ideal for LLPC 427 Figure 4: Average header size for CRTP 429 At higher BERs the average header size is determined by the rate of 430 COMPRESSED_NON_TCP headers (17 octets) sent over the cellular link. 431 CRTP compressors update the context state by sending such headers 432 whenever frames have been discarded over the cellular link. The 433 differences between the HDLC and LLPC curves at high BERs is due to 434 their different FERs. For a BER of 1e-3 and no Internet loss, CRTP 435 with HDLC gives an average header size of 2.7 octets, while CRTP with 436 LLPC gives 2.5 octets. For 10% Internet loss, HDLC gives 3.2 octets 437 and LLPC 3.0 octets. 439 6.3. CRTP with Twice 441 The Twice algorithm is a way to repair the context quickly without 442 having to wait for a roundtrip over the link. Twice makes assumptions 443 of what the lost delta was and tries to repair the context according 444 to those assumptions. When using Twice there must be a way to check 445 whether the repair succeeded, typically the UDP checksum is used for 446 that purpose. 448 The plots in figure 2 show FERs for CRTP, CRTP with Twice, and the 449 Ideal scheme, when HDLC framing is used. The CRTP with Twice curves 450 really show how successful Twice would be in repairing the context, 451 we have not actually enabled the UDP checksum in our simulations, but 452 instead we determined whether Twice would have succeeded. We wanted 453 to try out LLPC too (figure 3), and as the UDP checksum covers the 454 entire payload and is fairly weak, that scenario wouldn't make much 455 sense using the UDP checksum. Instead we chose to investigate how 456 successful Twice would be if there were some other means to detect a 457 successful repair. 459 It is evident from figure 2 that Twice improves the FER 460 significantly, although CRTP with Twice is still much worse than the 461 Ideal scheme. At a BER of 1e-3, the FERs are less than 2% for Ideal, 462 about 4% for CRTP with Twice, and 8% for CRTP. More sophisticated 463 implementations of Twice might get closer to the Ideal curve. 465 Figure 3 shows FERs for CRTP, CRTP with Twice, and the Ideal scheme, 466 when LLPC framing is used. The FERs are lower than for HDLC because 467 fewer frames are discarded at the link layer, but the plots are 468 otherwise similar. 470 6.4. Loss patterns 472 For applications such as interactive voice it is not only the loss 473 *rate* that is interesting. Typical voice decoders will reuse earlier 474 frames when a frame is lost, but might decrease the intensity with 475 which that frame is played out. For each successive loss the 476 intensity is decreased such that after a few consecutive lost frames 477 the sound will fade out completely. When only single frames are lost, 478 the tolerable FER might be high. A single burst of lost frames, on 479 the other hand, can cause a very noticeable pause. Figure 5 shows a 480 histogram over the number of consecutive loss bursts of certain 481 lengths for CRTP, with and without Twice, for three different BERs. 483 It is evident from figures 5a and 5b that the majority of loss events 484 without Twice are such that around 7 consecutive frames are lost. The 485 link roundtrip time in these simulations was 120 ms and the packet 486 rate 50 packets per second, which means that a single discarded frame 487 would cause 6 additional frames to be lost due to context damage. 488 When there is little loss over the Internet path, Twice (or variants) 489 are very efficient since deltas rarely change. 491 At higher BERs, COMPRESSED_NON_TCP packets are sent often and thus 492 lengths of frame loss bursts are less regular. Updates may be 493 damaged, and an earlier repair may cause an update which repairs new 494 damage. 496 Figure 5a: Lengths of frame loss bursts, HDLC, no IP loss 498 Figure 5b: Lengths of frame loss bursts, HDLC, 10% IP loss 500 Loss bursts involving 7-8 frames are clearly noticeable for most 501 voice decoders. This is a major disadvantage of using CRTP over high- 502 loss links with nontrivial link roundtrip times. Even if the frame 503 rate was one per 30 ms and the link roundtrip time was only 60 ms the 504 typical loss burst would be 3-4 frames (one discarded at link level, 505 next discovers damage, update requested, update sent), which would 506 decrease the voice quality significantly. 508 6.5. Using only COMPRESSED_NON_TCP packets 510 The high FERs for CRTP makes it interesting to compare its 511 performance against sending COMPRESSED_NON_TCP packets only. Their 512 headers are 17 octets. No frames are discarded due to context damage, 513 but on the other hand it is more likely that a packet will be damaged 514 because it is larger. 516 Figure 6: FER for COMPRESSED_NON_TCP only, HDLC and LLPC 518 Figure 6 shows the FER when sending COMPRESSED_NON_TCP packets only, 519 for HDLC and LLPC. For HDLC, the FER when the BER is 1e-3 is 3%, 520 which is more than for the Ideal scheme (<2%) but less than CRTP with 521 Twice (5%). The FER for LLPC is just over 2% and similarly to HDLC, 522 it is more than the Ideal scheme but less than CRTP with Twice. 524 6.6. Using periodic refreshes instead of requests 526 One alternative to the use of context updates on request could be to 527 periodically refresh the context as suggested in CRTP [RFC-2508] for 528 simplex links or links with high delay. However, to decrease the 529 packet loss rate due to context invalidation, the periodic refresh 530 method must update the context faster than the request based scheme, 531 which means that the compression slow-start mechanism described in IP 532 Header Compression [RFC-2507] would not be suitable. Instead, the 533 periodic refreshes must be sent with a shorter period than the link 534 round-trip time. Periodic refreshes could therefore be seen as a 535 solution somewhere between the ordinary request-based CRTP and the 536 completely difference-free solution used in 6.5, with only 537 COMPRESSED_NON_TCP packets. 539 The periodic refresh model evaluated here makes use of the 540 COMPRESSED_RTP and the COMPRESSED_NON_TCP packet types. 541 COMPRESSED_NON_TCP is used for every third and every fourth packet 542 respectively in two different simulations, the rest are 543 COMPRESSED_RTP. Figures 7 and 8 respectively show the packet loss 544 rates and header sizes for this scheme (both with refresh period 545 three and four) together with results for the ordinary CRTP and the 546 Ideal scheme. As shown in figure 7, the packet loss rate is 547 significantly decreased to about half as much as for the ordinary 548 solution, but it is still much higher than for the Ideal scheme. The 549 average header size on the other hand is increased about three times 550 to between six and seven octets. 552 A conclusion that could be drawn from this experiment is that a 553 periodic refreshing scheme would be costly in terms of header size if 554 it is supposed to improve the packet loss rate over links with a 555 round-trip time of 100-150 ms. With even longer RTT's, periodic 556 refreshes could be suitable, while for shorter RTT's the solution 557 would have no advantages over the request based scheme. 559 Figure 7: FER for CRTP with periodic refreshes, LLPC 561 Figure 8: Header sizes for CRTP with periodic refreshes, LLPC 563 7. Conclusions 565 The packet loss rate of CRTP, CRTP with Twice, and the Ideal header 566 compression scheme is summarized in table 1 for various error rates. 567 The numbers are for HDLC-like framing, i.e., errors in any part of a 568 packet means that it is discarded. The payload is 16 octets. The 569 Ideal scheme discards packets only when the packet itself is damaged. 571 Bit-error rate 1e-5 1e-4 1e-3 1e-2 572 ------------------------------------------- 573 Ideal 0 0.4% 1.8% 11% 574 CRTP+Twice 0 1.0% 5.0% 24% 575 CRTP 0 1.5% 8.0% 40% 576 ------------------------------------------- 578 Table 1: Frame loss rates of header compression schemes (HDLC). 580 It is evident from table 1 that CRTP performs well for BERs less than 581 1e-5, but not so well for BERs higher than 1e-4. If one considers a 582 scenario where the path of an IP telephony conversation has a 583 cellular link at both ends, the packet loss rates of CRTP and 584 CRTP+Twice become intolerable at high BERs. 586 The major cause of CRTPs bad performance is that many packets are 587 discarded due to context damage while waiting a link roundtrip time 588 for the repair mechanism. 590 Twice is a way to repair the context locally. It requires two extra 591 octets of header (the UDP checksum) to verify its repair attempts. 592 These two extra octets make it a less attractive solution. Moreover, 593 the straightforward Twice used in this evaluation does not have a 594 sufficiently high success rate. Combinations of link-loss at a first 595 cellular link and congestion-related loss in the rest of the path 596 will ensure that the compressor at the last cellular link will see 597 many holes in the packet stream. Twice will then fail often. 598 Moreover, the UDP checksum is too weak to reliably determine the 599 success or failure of attempted repairs. 601 The losses induced by CRTP and its variations are problematic not 602 only because they are high. The loss patterns are such that losses 603 occur in groups longer than a link roundtrip time. This is 604 problematic for low-bandwidth voice codecs, who cannot mask such long 605 loss events well. Hence, the speech quality will suffer. It is a 606 major disadvantage of CRTP that it causes such long loss events. 608 It is worth noticing that link layers which protect the header with 609 strong checksums, but not the payload, will decrease the packet-loss 610 rate significantly. Such link-layers will deliver more headers to the 611 decompressor and context damage will be less frequent. Table 2 612 summarizes the results for such a link-layer. 614 Bit-error rate 1e-5 1e-4 1e-3 1e-2 615 ------------------------------------------- 616 Ideal 0 0.3% 1.4% 7% 617 CRTP+Twice 0 0.8% 4.2% 18% 618 CRTP 0 1.1% 5.0% 25% 619 ------------------------------------------- 621 Table 2: Frame loss rates of header compression schemes (LLPC). 623 Overall, the improvement in FER were around 40% with a payload of 16 624 octets. When the payload is larger, the improvement will be higher. 625 In addition to the benefits for header compression, speech codecs for 626 lossy links can utilize information in damaged payloads and will 627 deliver higher quality speech when they have access to damaged 628 frames. 630 To summarize, CRTP does not perform well over lossy links with long 631 roundtrip times. Twice can improve the situation somewhat but the 632 loss is still too high. A disadvantage of using Twice is that it 633 requires that the UDP checksum is enabled, which will double the size 634 of the compressed header. CRTP with Twice performs much worse than 635 the Ideal scheme in terms of packet loss. Because the UDP checksum is 636 fairly weak, Twice should not be extended to attempt a large number 637 of repairs. Because of this, CRTP with Twice cannot approach the 638 performance of the Ideal scheme. 640 7.1. How to improve CRTP performance. 642 The link roundtrip time should be kept low. When it is high, local 643 repairs of the contex (without going over the link) is essential. 644 Sophisticated versions of Twice should be considered, which implies 645 that the UDP checksum must be enabled. Unfortunately, that adds 2 646 octets to the compressed header. 648 8. Author's Addresses 650 Mikael Degermark Tel: +46 920 911 88 651 Dept of CS & EE, Lulea Mobile: +46 70 833 89 33 652 University of Technology EMail: micke@sm.luth.se 654 Hans Hannu Tel: +46 920 20 21 84 655 Ericsson Erisoft AB Mobile: +46 70 378 04 73 656 Lulea, Sweden EMail: hans.hannu@ericsson.com 658 Lars-Erik Jonsson Tel: +46 920 20 21 07 659 Ericsson Erisoft AB Mobile: +46 70 365 20 58 660 Lulea, Sweden EMail: lars-erik.jonsson@ericsson.com 662 Krister Svanbro Tel: +46 920 20 20 77 663 Ericsson Erisoft AB Mobile: +46 70 531 25 08 664 Lulea, Sweden EMail: krister.svanbro@lu.erisoft.se 666 9. References 668 [RFC-768] J. Postel, User Datagram Protocol, RFC 768, August 1980. 670 [RFC-791] J. Postel, Internet Protocol, RFC 791, September 1981. 672 [RFC-793] J. Postel, Transmission Control Protocol, RFC 793, 673 September 1981. 675 [RFC-1144] V. Jacobson, Compressing TCP/IP Headers for Low-Speed 676 Serial Links, RFC 1144, February 1990. 678 [RFC-1662] W. Simpson, PPP in HDLC-like framing, RFC 1662, 1994. 680 [RFC-1883] S. Deering, R. Hinden, Internet Protocol, Version 6 681 (IPv6) Specification, RFC 1883, December 1995. 683 [RFC-1889] Henning Schulzrinne, Stephen Casner, Ron Frederick, Van 684 Jacobson, RTP: A Transport Protocol for Real-Time 685 Applications, RFC 1889, January 1996. 687 [RFC-2507] M. Degermark, B. Nordgren, S. Pink, IP header 688 compression, RFC 2507, February 1999. 690 [RFC-2508] S. Casner, V. Jacobson, Compressing IP/UDP/RTP Headers 691 for Low-Speed Serial Links, RFC 2508, February 1999. 693 [RFC-2509] M. Engan, S. Casner, C. Bormann, IP Header Compression 694 for PPP, RFC 2509, February 1999. 696 [WCDMA] Procedures for Evaluation of Transmission Technologies 697 for FPLMTS, ITU-R TG8-1, 8-1/TEMP/233-E, September 1995. 699 This Internet-Draft expires in June 2000.