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
