When the access medium's capacity is expensive (read radio spectrum), even single digit percentage points translate to significant expense. That is independent of the access speed.
-Woj. On 25 July 2011 12:26, Mark Townsley <[email protected]> wrote: > > Header overhead percentage is fairly useless alone. A real-world comparison > would need take into account the speed of a given connection. > > - Mark > > > On Jul 25, 2011, at 5:59 AM, Rémi Després 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). | | | >> | ------------------ | ------------------ | ------------------ | >> >> 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. >> >> Also, 4V6 devices can be expected to soon have an increasing part of their >> traffic in IPv6. With this, the 4V6 overhead in % will soon decrease >> accordingly. >> >> Conclusion: this line of the table deals with a difference that, although it >> is real, is not significant compared to other considerations (e2e >> transparency is one that deserves a separate discussion). >> >> Regards, >> RD >> _______________________________________________ >> 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
