Re: draft update

Marius,

Thank you for your works.
Added text in Section 1.1, Section 4.2 and Section 7 clarified 
indispensable tests of stateful IPv6 transition technologies such as 
DS-lite(AFTR), NAT64.

kaname

On 2015/03/06 11:32, Marius Georgescu wrote:
> 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

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