Re: [Int-area] Moving forward with draft-ietf-intarea-frag-fragile

On Sun, Dec 2, 2018 at 11:07 PM Suresh Krishnan
<suresh.krishnan@gmail.com> wrote:
>
> Hi Joe/Fred T. /Tom,
>   You have brought up some good points and I would really like to get this draft to progress in a timely manner. To help with this, I would greatly appreciate your help to move this along by sending specific change proposals pointing to the text in the draft you want changed preferably in the form of OLD: NEW: text so that it is easy for the authors and the WG to identify what the change entails.
>
> Also, with my AD hat off, I think the SHOULD NOT is the right generic recommendation for future applications, but a few (non-exhaustive) exceptions could easily be written into the MAY part. E.g.
>
Hi Suresh,

I'm having trouble grasping the fact that this would be calling
applications exceptions when they are doing nothing more than
implementing against a long established standard. IMO, it is the
non-conformant implementations that are motivating this discussion
that should be considered the exceptions. As I mentioned, it seems
like this "exception model" could easily be applied in several other
instances that intermediate nodes don't properly support the standard
protocols (EH, non-TCP, IPv6, etc.). I think the answer might be
provided by how IPv6 incompatibility is dealt with. If a protocol
feature is known to not work or is suspect in an environment, an
application can fallback at run-time to a mode that doesn't use the
feature. I suggest this text to describe it:

"Application developers should be aware that IP fragmentation may not
be viable across all paths in the Internet. Applications that might
invoke IP fragmentation SHOULD provide a fallback mode that can be
enabled at run-time to avoid the use fragmentation over networks paths
which include intermediate nodes that do not properly handle
fragments. The simplest fallback mechanism is too allow configuration
of the maximum application message size to fit into a lower MTU or
minimally supported MTUs (576 bytes for IPv4 and 1028 bytes for IPv6).
Such configuration could be applied to all communications for the
application, or to specific destinations whose paths are known be
problematic for fragmentation. An application MAY choose to probe a
destination by sending fragmented packets to determine whether the
path to the destination properly supports fragmentation and then can
adjust its message size based on the feedback.

An application developer MAY implement application layer
fragmentation. This might require implementing application protocol
specific implementation for fragmentation and reassembly, as well as
having a sufficiently reliable PMTU discovery mechanism (e.g.,
PLMPTUD). Because of the complexity and effort required to support
application layer fragmentation, this is not a general solution and
may be prohibitive or undesirable to some applications."

> "However, there may be certain classes of applications that can benefit by using IP layer fragmentation in order to reduce complexity or to minimize overhead. (Examples of such applications include <text from Fred, Joe and Tom>). These applications MAY prefer to use IP fragmentation."
>
> Does this sound like a reasonable way forward?
>
One nit: a recommendation that applications SHOULD NOT rely on
fragmentation does not seem like a protocol requirement but more like
a BCP to me.

Tom

> Thanks
> Suresh
>
> On Sat, Dec 1, 2018, 7:16 AM Joe Touch <touch@strayalpha.com> wrote:
>>
>>
>>
>> > On Nov 30, 2018, at 2:57 PM, Tom Herbert <tom@herbertland.com> wrote:
>> >
>> > ...student writing a quick UDP app in their dorm room to have to consider
>> > all the pitfalls of fragmentation and whether they need to increase
>> > their complexity by an order of magnitude to implement fragmentation
>> > in their application. The promise of doing IP fragmentation at the
>> > network layer is that the application developer doesn't need to be
>> > concerned with such things
>>
>> Agreed. That and issues with IP frag are why we’re developing UDP frag.
>>
>> Joe
>> _______________________________________________
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area