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