On 26 July 2011 23:02, Wojciech Dec <[email protected]> wrote:
> Typo... > > On 26 July 2011 22:39, Mark Townsley <[email protected]> wrote: > >> >> 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 >> >> There is another perspective here: Overhead (of any kind) that consumes a > resource which could be used by other users, or by the user, is a waste, and > thereby cost. This is more applicable to certain environments rather than > others, but it is not something that can not be dismissed as not applying. > The overhead can be "optimized" (eg compressed), but that involves making > more system changes and other trade-offs (eg IPinIP compression, which is > anything but common) > > -Woj. > > > >> > 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
