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? 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
