Subject: Re: [lp-wan] Case for splitting the fragmentation piece from the SCHC IP draft

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 3 Apr 2017 17:05:15 +0000

Dear authors:

I talked to several folks and got pros and cons.  

As it goes, streamlining will only occur in a positive fashion if all the intervening parties are orthogonal, different sets of authors, of reviewers etc... This is not guaranteed (at all).

The bottom line is that if we can make our dates without splitting, then we should not waste time doing that split but rather should proceed swiftly with the current format.

But there should be a clear delineation of the fragmentation piece in a self-contained section, so we are ready for the split if a problem occurs that causes a delay in that piece.

Take care;

Pascal

-----Original Message-----
From: lp-wan [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: jeudi 30 mars 2017 11:49
To: lp-wan <[email-masked]>
Subject: [lp-wan] Case for splitting the fragmentation piece from the SCHC IP draft

Dear all:

<chair hat off>

Yesterday at the LPWAN WG meeting in Chicago, we discussed the possibility to split the fragmentation piece off the SHCH/IP document - we also discussed splitting the framework piece but quickly dismissed that, see the minutes to be published soon.

Here are some arguments in favor of splitting:
- the fragment piece is a sublayer below IP in order to enable IP, but it is not IP
- the mechanisms involved are completely different, the fragmentation has very basic rules. Splitting the docs improves the clarity of what is needed for what.
- the expectations on the network are different e.g. fragmentation requires in-order delivery, IP requires 1280 MTU.
- which relates to the fact that the backend device that handles the fragmentation may be different (e.g. the fragmentation could be done at the NS as opposed to SCHC/IP and CoAP that could be run in some MEC or cloud location)

And then there are reasons related to the standardization process. Putting it all together like we did with RFC 4944 can probably be seen as a mistake with the historical perspective that we have now. With the split:
- going through the review process would be streamlined; we have a very constrained agenda
- maintenance of the docs for future revision / deprecation would be easier, either updating one or the others.

With this in mind, I encourage the split...

<chair hat on>

but would like to hear about reasons not to split before we make a decision.

Take care,

Pascal

_______________________________________________
lp-wan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lp-wan

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Mon, 3 Apr 2017 20:42:38 +0200

Dear Pascal,

Thanks for this feedback.

With regard to the fragmentation piece, its "body" is currently 
self-contained in a specific section. That is, fragmentation-related
content other than this specific section only appears elsewhere in the
document in the introduction and in the security considerations sections.

I believe future revisions of the document will follow this same approach.
Thus, my opinion is that if at some point a split needs to be made, it
will not be a difficult thing to do.

Cheers,

Carles

> As it goes, streamlining will only occur in a positive fashion if all the
> intervening parties are orthogonal, different sets of authors, of
> reviewers etc... This is not guaranteed (at all).
>
> The bottom line is that if we can make our dates without splitting, then
> we should not waste time doing that split but rather should proceed
> swiftly with the current format.
>
> But there should be a clear delineation of the fragmentation piece in a
> self-contained section, so we are ready for the split if a problem occurs
> that causes a delay in that piece.
>
> Take care;
>
> Pascal
>
> Yesterday at the LPWAN WG meeting in Chicago, we discussed the possibility
> to split the fragmentation piece off the SHCH/IP document - we also
> discussed splitting the framework piece but quickly dismissed that, see
> the minutes to be published soon.
>
> - the mechanisms involved are completely different, the fragmentation has
> very basic rules. Splitting the docs improves the clarity of what is
> needed for what.
> - the expectations on the network are different e.g. fragmentation
> requires in-order delivery, IP requires 1280 MTU.
> - which relates to the fact that the backend device that handles the
> fragmentation may be different (e.g. the fragmentation could be done at
> the NS as opposed to SCHC/IP and CoAP that could be run in some MEC or
> cloud location)
>
> And then there are reasons related to the standardization process. Putting
> it all together like we did with RFC 4944 can probably be seen as a
> mistake with the historical perspective that we have now. With the split:
> - maintenance of the docs for future revision / deprecation would be
> easier, either updating one or the others.
>

---

From: Ana Minaburo <[email-masked]>
Date: Tue, 4 Apr 2017 11:09:40 +0200

Dear Pascal and all,

I agree with Carles, the fragmentation part could be easily taken out from
the document if needed. Nevertheless, I think the Header Compression and
Fragmentation solutions must go together for the LPWAN network
characteristics, do one or the other will not be enough, I think we need to
do both to get the best performance.

The only reason to split the document is only about standardization
schedule and deadlines. But in the practice we need both of them.

Ana

On Mon, Apr 3, 2017 at 8:42 PM, Carles Gomez Montenegro <
[email-masked]> wrote:

> > From: lp-wan [mailto:[email-masked]] On Behalf Of Pascal
> Thubert
> > (pthubert)
> > Subject: [lp-wan] Case for splitting the fragmentation piece from the
> SCHC
> > IP draft
> >
> > Dear all:
> >
> > <chair hat off>
> >