draft update

Dear BMWG Members,

I have updated the draft about IPv6 transition technologies benchmarking I presented in IETF91. Thank you very much for your comments and for the warm welcome. The new draft can be found here:

http://tools.ietf.org/html/draft-georgescu-bmwg-ipv6-tran-tech-benchmarking-00

The overview of the changes according to the received feedback is:

# Following Kaname Nishizuka's comment about stateful vs stateless:
 
- the following text was added to Section 1.1:

Another important aspect by which the IPv6 transition technologies 
can be categorized is their use of stateful or stateless mapping algorithms. 
The technologies that use stateful mapping algorithms (e.g. Stateful NAT64 [RFC6146]) 
create dynamic correlations between IP addreesses or 
{IP address,transport protocol, transport port number} tuples, which are stored in 
a state table. The efficiency with which the state table is managed can be an 
important performance indicator. Hence, for the IPv6 transition technologies which 
are employing stateful mapping algorithms, additional benchmarking tests 
are RECOMMENDED.     

- added the following text in Section 4.2:

Considering that the stateful transition technologies need to manage the state 
table for each connection, a connection-oriented transport layer protocol 
needs to be used with the test traffic. Consequently, TCP traffic SHOULD 
be employed for the tests described in Section 7 of this document.

- added Section 7. Additional Benchmarking Tests for Stateful IPv6 Transition Technologies

# Following Scott Bradner's comment related to the 6 -> 4 vs 4 -> 6 translation 
performance of translation based transition technologies:

- the following text was added to Section 1.1:  

In the case of translation based transition technology, the DUT CE and DUT PE 
machines MAY be tested separately as well. These tests can represent a fine grain
 performance analysis of the IPvX to IPvY translation direction versus the 
IPvY to IPvX translation direction. The tests SHOULD follow the test setup 
presented in Figure 1.

# Following Andrew McGregor's comment about the need to test CE devices 
with more than one network flow:

- the following text was added to Section 8.1: 

This test setup can help to quantify the scalability of the PE device. 
However, for testing the scalability of the DUT CEs additional setups 
are needed. For encapsulation based transition technologies a m:n setup can be 
created, where m is the number of flows applied to the same CE device and n 
the number of CE devices connected to the same PE device.
For the translation based transition technologies the CE devices can be separately 
tested with n network flows using the test setup presented in Figure 3.

# Following comments from Al Morton, Scott Brandner and Andrew McGreogor about 
UDP vs TCP measurements:

- the following text was added to Section 4.3: 

Because of the simplicity of UDP, UDP measurements offer a more reliable basis 
for comparison than other transport layer protocols. Consequently, for the 
benchmarking tests described in Section 6 of this document UDP traffic 
SHOULD be employed. 
 

# the comment from Nalini Elkins about DNS lookup based measurements was noted. 
However I don't have a clear solution for now. Suggestions are welcome.

# Following Bhuvan Vengainathan's comment about MTU settings for the interfaces:

- the following text was added to Section 4.1:

In the context of frame size overhead MTU recommendations are needed in order 
to avoid frame loss due to MTU mismatch between the virtual 
encapsulation/translation interfaces and the physical network 
interface controllers (NICs). To avoid this situation, the larger MTU 
between the physical NICs and virtual encapsulation/translation interfaces 
SHOULD be set for all interfaces of the DUT and tester.

# Following Bhuvan Vengainathan's comment about handling the Multicast traffic

- the following text was added to Section 4:

Multicast IP traffic is outside of the scope of this document.

# Following Bhuvan Vengainathan's comment about the routing mode: 

- the following text was added to Section 3:

For the simple test setups described in the next two subsections, static 
routing MAY be employed.  However, for more complex test setups 
(e.g. scalability testing setup) dynamic routing is a more reasonable choice. 
However, the presence of routing and management frames can represent unwanted
 background data that can affect the benchmarking result. To that end, 
the procedures defined in [RFC2544] (Sections 11.2 and 11.3) related to 
routing and management frames SHOULD be used here as well.

# I am still considering a solution for the comments received from Bhuvan Vengainathan and  Al Morton about 
jitter.


# Editorial changes suggested by the RFC Editor Team 

Best regards,
Marius

_______________________________________________
bmwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bmwg