On Jul 26, 2011, at 4:58 PM, Rajiv Asati (rajiva) wrote: > Mark, > > You raise a good point. Header compression could be useful, however, that > comes at a cost. > > Are you suggesting 'header compression' on the radio interface, or between > the UE and the GGSN/P-GW?
It's a general statement. For example, in the dial-up days virtually every layer had some way to reduce encapsulation size. PPP could compress away HDLC-like framing, protocol ID, etc. We had VJ TCP Header Compression and even payload compression as well. L2TP published an L2TP Header Compression document to show that it could have a header-size smaller than PPTP. And of course ROHC. As link-speeds increased, these progressively fell by the wayside in terms of wide support and usage. There are good reasons for that. - Mark > > Cheers, > Rajiv > > >> -----Original Message----- >> From: Mark Townsley [mailto:[email protected]] >> Sent: Tuesday, July 26, 2011 4:39 PM >> To: Rajiv Asati (rajiva) >> Cc: Rémi Després; Wojciech Dec; Softwires-wg; Wojciech Dec (wdec) >> Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E >> >> >> On Jul 26, 2011, at 4:30 PM, Rajiv Asati (rajiva) wrote: >> >>> Remi, >>> >>>> Note also that, in 3GPP where power consumption is important, the IPv4v6 >>>> bearer option completely avoids the IPv6 header overhead (no need for 4V6). >>> >>> Don't follow this. Could you please expand? >> >> I read that statement as in "cellular mobile" networks, dual-stack will be >> deployed predominately with native dual-stack rather than 4V6 solutions. I do >> think that the jury is likely still out on that. >> >> In any case, anyone who lived through the dial-up years with all the >> different >> header negotiation options we had then and happily left behind will likely >> roll their eyes at this "my header is shorter than yours!" discussion. Header >> size is the tail wagging the dog in a solution, and outside of the low- >> power/sensor world well within the point of diminishing returns as an >> advantage of one approach vs. another. >> >> - Mark >> >>> >>> Cheers, >>> Rajiv >>> >>> >>>> -----Original Message----- >>>> From: [email protected] [mailto:[email protected]] On >> Behalf >>>> Of Rémi Després >>>> Sent: Tuesday, July 26, 2011 10:47 AM >>>> To: Wojciech Dec >>>> Cc: Softwires-wg; Wojciech Dec (wdec) >>>> Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E >>>> >>>> Well, I made my point (with one more comment below, at the end). >>>> Up to WG contributors, and to operators, to appreciate what is really >>>> important to them. >>>> >>>> Note also that, in 3GPP where power consumption is important, the IPv4v6 >>>> bearer option completely avoids the IPv6 header overhead (no need for 4V6). >>>> >>>> In wifi, I am still convinced that the impact on power consumption of +6O >> vs >>>> +40 octets per IPv4 packet will remain negligible in real life, especially >> as >>>> IPv6 will become the majority. >>>> >>>> The impact of translation on e2e transparency will be discussed in another >>>> email. >>>> >>>> RD >>>> >>>> Le 26 juil. 2011 à 15:52, Wojciech Dec a écrit : >>>> >>>>> Remi, >>>>> >>>>> On 25 July 2011 11:59, Rémi Després <[email protected]> wrote: >>>>>> >>>>>> Wojciech, >>>>>> >>>>>> IPv4-header computations of draft-dec-stateless-4v6-02 are AFAIK too much >>>> in favor of translation (4v6T) vs encapsulation (4V6E). >>>>>> >>>>>> The draft has: >>>>>> +------------------------+--------------------+---------------------+ >>>>>> | Item | 4V6 Translation | 4V6 Mapped Tunnel | >>>>>> | | mode | Mode | >>>>>> +------------------------+-------- ... -------+---------------------+ >>>>>> | Overhead in relation | a) 0% b) 0% | a) 4.36% b) 1.71% | >>>>>> | to average payload of | | | >>>>>> | a) ~550 bytes b) 1400 | | | >>>>>> | bytes). | | | >>>>>> | ------------------ | ------------------ | ------------------ | >>>>>> >>>>>> An IPv4 packet having a 550 B payload is 570 B long (ignoring possible >> IPv4 >>>> options): >>>>>> - 4V6T adds 20 B (3.5 %). >>>>>> - 4V6E adds 40 B, (7.0 %). >>>>>> An IPv4 packet having a 1400 B payload is 1420 B long (at least) >>>>>> - Translation adds 20/1420 = 1,4 % >>>>>> - Encapsulation adds 40/1420 = 2,8 % >>>>>> >>>>>> This gives: >>>>>> | ------------------ | ------------------ | ------------------ | >>>>>> | Overhead in relation | a) 3.5% b) 1.4% | a) 7% b) 2.8% | >>>>>> | to average payload of | | | >>>>>> | a) ~550 bytes b) 1400 | | | >>>>>> | bytes). | | | >>>>>> | ------------------ | ------------------ | ------------------ | >>>>> >>>>> Sure. However, 4V6, as per Figure 1 in the draft is based on IPv6 >>>>> transport. It thus seemed fair to measure and compare the overhead as >>>>> relative to IPv6 encapsulation, and not IPv4, since there is no way to >>>>> send an IPv4-only packet, and the useful data is the Layer4+ payload. >>>>> Doing it your way you show mixes the basic IPv6 overhead. In any case, >>>>> subtract the left column from the right and one arrives at the figure >>>>> at pretty much the figures in the original table. >>>>> >>>>>> >>>>>> In addition, a complete comparison should take in consideration the >> length >>>> of layer-2 headers, as well as that of the physical preambles if any. This >>>> leads to even less different overhead ratios. >>>>> >>>>> With the relative consideration, this actually doesn't matter... And >>>>> we can choose to ignore the detail of specific radio link protocols >>>>> that can segment longer packets into many many more. >>>> >>>> Different view here. >>>> The _ratio_ of power-consumption increase, if n bytes are added to each >>>> packet, does depend on the total length of packets (with their headers of >> all >>>> layers, including link and physiscal). >>>> >>>> >>>>> >>>>> -Woj. >>>> >>>> >>>> _______________________________________________ >>>> Softwires mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/softwires >>> _______________________________________________ >>> Softwires mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
