On 26 July 2011 16:46, Rémi Després <[email protected]> wrote: > 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).
That is totally orthogonal... > > 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. I trust that it will explain how to build an e2e transparent system with a stateful port restricted NAT44 in the path. If not, the IPv4 e2e transparency of encapped or translated transports is very much the same. -Woj. > > 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
