Subject: Re: [tram] STUN MTU constraints (was Re: Review of draft-ietf-tram-stunbis-04)

From: Simon Perreault <[email-masked]>
Date: Wed, 6 Jul 2016 15:12:02 -0400

Editors of stunbis,

The result of this consensus call is that there is no consensus to
change the current MTU rules, therefore they shall remain unchanged.

Thanks,
Simon

Le 2016-05-27 à 15:46, Simon Perreault a écrit :
> All,
> 
> The WG has not yet expressed a clear consensus for or against Brandon's
> proposal. If you have an opinion either way, please speak up now.
> 
> Brandon, no need to restate your position. :)
> 
> Thanks,
> Simon
> 
> Le 2016-04-05 à 10:19, Brandon Williams a écrit :
>> Hi all,
>>
>> I haven't seen any responses to this question so I'm going to convert it
>> into a proposal.
>>
>> My sense is that the group sees little enough problem with
>> fragmentation, and particularly little enough risk the the PMTU is 576
>> bytes, that the MUST language about MTU limitations can be removed. I
>> propose that we completely remove the following statement from stunbis.
>>
>>    The MTU limitation is a SHOULD, and not a MUST, to account for cases
>>    where STUN itself is being used to probe for MTU characteristics
>>    [RFC5780].  Outside of this or similar applications, the MTU
>>    constraint MUST be followed.
>>
>> I think this reflects the outcome of a previous discussion. Are there
>> any objections to this change?
>>
>> --Brandon
>>
>> On 01/27/2016 01:23 PM, Brandon Williams wrote:
>>> On 01/26/2016 10:41 PM, Marc Petit-Huguenin wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA256
>>>>
>>>>> s 6.1 This section still says "MTU constraint MUST be followed"
>>>>> language. I'm pretty sure that we decided to relax this constraint in
>>>>> Dallas, but I don't see it in the minutes. It seems to be implied by
>>>>> the decision about removing the SCTP requirement.
>>>>
>>>> My recollection was that the relaxation was linked to the introduction
>>>> of the SCTP transport in STUN (which permitted safe fragmentation).
>>>> Now that SCTP is gone, I am not sure that this decision stands alone.
>>>>
>>>
>>> IIRC, in Dallas we discussed MTU constraints in the context of both the
>>> SCTP requirement and the ORIGIN draft. The point was made that both
>>> small MTUs and fragment delivery failure are rare and that the existing
>>> requirements language is unnecessary. This was the foundation for
>>> removing the SCTP language and for removing some size constraint
>>> language from the ORIGIN draft. My understanding of the discussion was
>>> also that the group agreed to relax the existing RFC5389 constraint, at
>>> least for request/response message types.
>>>
>>> This really just applies to the following text:
>>>
>>>     If the path MTU is unknown for UDP, messages SHOULD be the smaller of
>>>     576 bytes and the first-hop MTU for IPv4 [RFC1122] and 1280 bytes for
>>>     IPv6 [RFC2460].
>>>     <snip/>
>>>     The MTU limitation is a SHOULD, and not a MUST, to account for cases
>>>     where STUN itself is being used to probe for MTU characteristics
>>>     [RFC5780].  Outside of this or similar applications, the MTU
>>>     constraint MUST be followed.
>>>
>>> IOW, if you don't know the PMTU, an allocation request MUST be smaller
>>> than 576 bytes for IPv4. My sense of the room in Dallas was that we
>>> agreed this is an unnecessary restriction, at least for the
>>> request/response message types.
>>>
>>> So, what do others think/remember? Should we keep the existing
>>> requirement (in which case I think it will be important to consider this
>>> limitation whenever new attribute types are created)? Am I remembering
>>> correctly that we already decided to loosen the requirement and it just
>>> didn't make it into the notes for the meeting?
>>>
>>> --Brandon
>>>
>>> _______________________________________________
>>> tram mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/tram
>>
>>
>