Le 26 juil. 2011 à 16:56, Wojciech Dec a écrit : ... >> 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.
OK, there may be ambiguity about e2e. Here, I meant _network_ e2e transparency, i.e. from customer site to customer site. 1. With network e2e transparency: - There is no assumption to be made about NAT44 behaviors in CE's. (We all know that there are many different NAT and FW behaviors, so that any assumption may prove to be wrong with a few existing NAT devices.) - Except for the port-set restriction of shared IPv4 addresses, complete backward compatibility of the IPv4 service is ensured. 2. If some CE's are given full IPv4 addresses, they may use protocols for which NAT44 isn't needed. With network e2e transparency, no restriction on IP options they may use is needed. Regards, RD > 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
