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

From: Zhen Cao <[email-masked]>
Date: Tue, 29 Sep 2009 14:17:02 +0800

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-masked]> 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-masked]> 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-masked]> 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-masked]> 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-masked]>
>> 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-masked]> 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-masked]
>>> https://www.ietf.org/mailman/listinfo/softwires
>>>
>>>
>>
>>
>>
>
>

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 29 Sep 2009 08:07:08 -0400

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" <[email-masked]> wrote:

>> > fragmentation. In the end, the group agreed that this draft isn¹t the best
>>> >> 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
>>>> >>> For TCP, we ³could² potentially avoid fragmentation by modify MSS
>>>> option.