Re: [Softwires] MTU problem in DS-lite

["Lee, Yiu" <Yiu_Lee at Cable.Comcast.com>]

Title: Re: [Softwires] MTU problem in DS-lite

Hi Cao,

Thanks for pointing out this draft. I don’t think this is a draft produced by Softwire WG. 

I read it and it recommended that the tunnel endpoint not to fragment the oversized datagrams after encapsulation . The author’s concerns are valid. We discussed their same concerns in the Software meeting and possible ways to handle fragment. In the conclusion section of 4459, the author recommend to fragment the IPv4 datagram before entering the tunnel. I believe that this is less desire due to the fact that the oversizing happens only after the encapsulation. If the tunnel endpoint fragmented the IPv4 datagram into two datagrams and encapsulate them into two individual IPv6 datagams, the fragmentation information would be lost at the IPv6 layer. The receiver would not know the two IPv6 datagrams in fact carry the same IPv4 datagam until after de-capsulation. This would require the receiver to look one layer deeper to discover the fragmentation.

Thanks,
Yiu


On 9/29/09 2:17 AM, "Zhen Cao" <caozhenpku at gmail.com> wrote:

> 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 <Yiu_Lee at cable.comcast.com> 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" <caozhenpku at gmail.com> 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<Yiu_Lee at cable.comcast.com> 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" <caozhenpku at gmail.com> 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<Yiu_Lee at cable.comcast.com>
> >> 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" <caozhenpku at gmail.com> 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
> >>> Softwires at ietf.org
> >>> https://www.ietf.org/mailman/listinfo/softwires
> >>>
> >>>
> >>
> >>
> >>
> >
> >

Attachment: smime.p7s
Description: S/MIME cryptographic signature