Re: [tcpm] TCP MSS clamping to try to deal with MTU issues in Dual-Stack Lite

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, all,

The solution has a bug: if TCP traffic uses TCP MD5 or TCP-AO, then it
needs to be handled like non-TCP traffic, since MSS revision would
destroy the packet's integrity.

IMO, this should be handled the simple way - remove the TCP case, and
handle all traffic the non-TCP way.

Finally, if a NAT ever refuses to reassemble anything, it MUST issue an
ICMP too-big IMO. The whole idea of creating a problem (encapsulating,
decreasing the effective MSS on a path) then not cleaning it up
yourself, or deciding when to clean it up based on *current* assumptions
of network traffic is a bad idea and shouldn't be supported.

Joe

Magnus Westerlund wrote:
> Hi,
> 
> There is a proposal to use TCP MSS clamping to deal with MTU issues that
> comes from Dual-stack lite's tunnel encapsulation.
> 
> I think it would be good if TCPM could provide some feedback on this
> proposal.
> 
> The relevant document and section:
> http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-00
> 
> 7.4. MTU
> 
> 
>    Using an encapsulation (IP in IP or L2TP) to carry IPv4 traffic over
>    IPv6 will reduce the effective MTU of the datagrams.  Unfortunately,
>    path MTU discovery is not a reliable method to deal with this.  As
>    such a combination of solutions is suggested:
> 
>    o  For TCP traffic, let the carrier-grade NAT rewrite the MSS in the
>       first SYN packet to a lower value.
> 
>    o  For non-TCP traffic, perform fragmentation and reassembly over the
>       tunnel between the home gateway and the carrier grade NAT.  In
>       practice, this means put the IPv4 packet into a large IPv6 packet
>       and fragment/reassemble the IPv6 packet at each endpoint of the
>       tunnel.  There is a performance price to pay for this.
>       Fragmentation is not very expensive, but reassembly can be,
>       especially on the carrier-grade NAT that would have to keep track
>       of a lot of flows.  However, such a carrier-grade NAT would only
>       have to perform reassembly for large UDP packets sourced by
>       customers, not for large UDP packets received by customers.  In
>       other words, streaming video to a customer would not have a
>       significant impact on the performance of the carrier-grade NAT,
>       but will require more work on the home gateway side.
> 
> Cheers
> 
> Magnus Westerlund
> 
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknb2a8ACgkQE5f5cImnZrs0ewCg7ScElkpLrz20zSpTMnXuRApa
CPsAoIyhk9N9K2fPpEJTyShMKeZNLxD/
=9ob2
-----END PGP SIGNATURE-----