Thanks for your information. I would like to bring back this discussion once again. It is a good idea to have an individual document for the MTU and fragmentation issues. But I noticed there is RFC 4459 discussing MTU and Fragmentation Issues with In-the-Network Tunneling. Is this RFC 4459 a product of softwire wg?
Thanks, -Zhen On Mon, Aug 17, 2009 at 9:52 PM, Lee, Yiu <[email protected]> wrote: > We have many discussions in the IETF-75 meeting about optimizing > fragmentation. In the end, the group agreed that this draft isn’t the best > place to discuss the optimization. For fragmentation problem shares among > all the tunneling protocols, this is not unique to ds-lite technology. The > chairs suggested we should produce another draft which only discusses > fragmentation strategy for tunnel protocols. > > > On 8/17/09 9:48 AM, "Zhen Cao" <[email protected]> wrote: > > Hi Yiu, > > Thanks for your message. In this sense, any methods except > fragmentation and assembly are optimization and up to implementation. > But it is not a bad idea to introduce some suggestion for > implementation in the draft, so keeping the text for TSS option and > others is also reasonable. > > Best regards, > Zhen > > On Mon, Aug 17, 2009 at 10:29 AM, Lee, Yiu<[email protected]> wrote: >> This is *not* recommended because it will require the v4 host to know >> about >> ds-lite. This won’t work for home router model where the hosts behind the >> ds-lite home router won’t know about ds-lite. Besides, the v4 packet isn’t >> over-sized, it is the v6 encapsulation caused the oversized issue. So the >> tunnel points are responsible to handle the fragmentation. >> >> In the hosted model, the host is aware of ds-lite. The host can in fact >> reduce the v4 packet size to avoid fragmentation. This optimization is up >> to >> the implementation rather than mandated in the draft. >> >> >> On 8/16/09 9:42 PM, "Zhen Cao" <[email protected]> wrote: >> >> Hi Yiu, >> >> Thanks for your clarification. >> >> Do you consider another method that let the IPv4 packet inside the >> tunnel do fragmentation at a lower MTU (link-MTU - 40), so that the >> packet won't exceed the MTU after IPv6 header encapsulation. Then >> there is no need of IPv6 encapsulation and assembly. I believe this >> is more cost efficient than IPv6 fragmentation and assembly. >> >> Thanks and regards, >> Zhen >> >> On Mon, Aug 17, 2009 at 12:34 AM, Lee, Yiu<[email protected]> >> wrote: >>> Hi Zhen, >>> >>> In general, the Tunnel-Entry Point and Tunnel-Exist Point should fragment >>> and reassemble the oversize datagram. This mechanism is transport >>> protocol >>> agnostic and work for both UDP and TCP. >>> >>> For TCP, we “could” potentially avoid fragmentation by modify MSS option. >>> However, we were required by the Chairs to remove this optimization from >>> the >>> draft in next update. >>> >>> Thanks, >>> Yiu >>> >>> >>> On 8/16/09 3:56 AM, "Zhen Cao" <[email protected]> wrote: >>> >>> Hi Alain and All, >>> >>> I have a question on MTU issue in ipv4-in-ipv6 softwire. I notice >>> Sec.10.2 of DS-Lite draft has discussed the MTU problem. The draft >>> introduces one possible way of using TCP MSS option to avoid IP layer >>> fragmentation and reassembly. It is a good idea but how about the case >>> for UDP sockets? I suppose there should be a general way to handle the >>> MTU issue? Thanks for any explanation. >>> >>> Thanks and regards, >>> Zhen >>> _______________________________________________ >>> Softwires mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/softwires >>> >>> >> >> >> > > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
