Re: [v6ops] PMTUD issue discussion

Hi Fred,

On 8/26/14, Templin, Fred L <Fred.L.Templin@boeing.com> wrote:
> Hi Andrew,
>
>> -----Original Message-----
>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Andrew ??
>> Yourtchenko
>> Sent: Tuesday, August 26, 2014 2:50 AM
>> To: joel jaeggli
>> Cc: IPv6 Ops WG
>> Subject: Re: [v6ops] PMTUD issue discussion
>>
>> Joel,
>>
>> On 8/25/14, joel jaeggli <joelja@bogus.com> wrote:
>> > On 8/25/14 1:49 PM, Joe Touch wrote:
>> >> Hi, all,
>> >>
>> >> Speaking from TCPM-land, I would observe the following:
>> >>
>> >> - PMTUD already has many known problems, which is why PLMTUD is
>> >> recommended instead
>> >
>> > I agree, operationally however I'm trying not to break existing devices
>> > attempting to connect to me, is the motivation for the note.
>> >
>>
>> During the presentation in the v6ops session I made a comment about
>> sysctl net.ipv4.tcp_mtu_probing. Since then I had a chance to test it
>> - and indeed, it affects the behavior of TCP over IPv6 as well.
>
> PTB message loss is also a concern for IPv6, and not just for IPv4.

Absolutely agree.

Just that at a first look one would see a bunch of sysctls that are
labeled with ".ipv4." and a bunch of sysctls that are labeled with
".ipv6." and possibly make a conclusion they affect just that
protocol.

>
>> However, the value of 1 causes a large value of MSS to be used,
>> resulting in about 1.5 second hiccup. So, yeah it "works" but for
>> barely acceptable values of "works"
>>
>> Setting the value to 2 causes the initial MSS to be 512, which
>> "mitigates" the problem and avoided the hiccups on a 100kb file I was
>> testing with - at the expense of almost 3x more packets of course.
>
> I think that implementation was added to the linux kernel a long
> time ago, and I am not sure if anyone is still maintaining it. Is
> this a problem that should be reported to netdev?

I think it works the same way it would work in IPv4 - if the ICMP PTB
is lost, and the too large MSS was used, then there is a delay which
is less tolerable today for the interactive traffic (IMHO) than when
this code was introduced, hence my remark that "works" value is
relatively small by today's high standards.

But the 512-byte MSS, while preventing the delay, effectively triples
the PPS, so might cause problems in some of the setups if their gear
is "only" capable of 2x of the pre-change PPS value.

That was the reason to suggest that if this setting can be used to
solve the problem, there probably should be a discussion of the
tradeoffs in the draft.

I did not notice any wrong behavior - but, my testing was rather cursory.

--a

>
> Thanks - Fred
> fred.l.templin@boeing.com
>
>> I think it would be useful to see the discussion of this measure and
>> its applicability/tradeoffs in the draft.
>>
>> --a
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>