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

Reply via email to