Subject: [lp-wan] Window mode as default fragmentation in SCHC + Minutes from Interim on 24/05

From: Alexander Pelov <[email-masked]>
Date: Mon, 29 May 2017 18:33:35 +0200

Dear all,

The minutes from the last interim meeting have been uploaded and can be found at the following address: https://www.ietf.org/proceedings/interim-2017-lpwan-03/minutes/minutes-interim-2017-lpwan-03-201705241600-00

One of the main topics that were discussed was the advancement of the fragmentation part of the IP/UDP SCHC document ( https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-03 ). 

During the call we have reached a rough consensus that the Window mode covers all use-cases, is simple (from implementation and protocol point of view), is well understood, and can be included as a default mode for fragmentation in the RFC. 

We have also indicated that there are other ways of doing the fragmentation (most notably the Packet mode), but some corner cases still need to be covered (e.g. bitmap sizes bigger than available payload limiting the MTU to less than 1280), and some advanced ways of actually solving this (Bloom filters were mentioned I think). These are all interesting ideas and they merit a longer discussion to find the right balance. These are to be kept in a separate document, which can continue its life independently, and if the WG decides can be included as a future WG item. If a future devices implement these other fragmentation mechanisms, they will be perfectly compatible with the default Window mode (the Rule ID can indicate which fragmentation mode is used).

We would like to confirm that you approve the Window mode as the default mode for fragmentation to be included in the SCHC IP/UDP document. 

Best,
The chairs

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Mon, 29 May 2017 18:00:53 +0000

Hi Alex,

I agree that the window mode provides enough support and flexibility for the basic use cases. The more advanced fragmentation mechanisms to be defined later on can be easily supported and communicated with Rule IDs, as you mention.

+1       for Window as default fragmentation mode.

Best,

Juan Carlos 

> -----Original Message-----
> From: lp-wan [mailto:[email-masked]] On Behalf Of Alexander Pelov
> Sent: May 29, 2017 12:34 PM
> To: lp-wan <[email-masked]>
> Subject: [lp-wan] Window mode as default fragmentation in SCHC + Minutes
> from Interim on 24/05
> 
> Dear all,
> 
> The minutes from the last interim meeting have been uploaded and can be
> found at the following address: https://www.ietf.org/proceedings/interim-
> 2017-lpwan-03/minutes/minutes-interim-2017-lpwan-03-201705241600-00
> 
> One of the main topics that were discussed was the advancement of the
> fragmentation part of the IP/UDP SCHC document (
> https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-03 ).
> 
> During the call we have reached a rough consensus that the Window mode
> covers all use-cases, is simple (from implementation and protocol point of
> view), is well understood, and can be included as a default mode for
> fragmentation in the RFC.
> 
> We have also indicated that there are other ways of doing the fragmentation
> (most notably the Packet mode), but some corner cases still need to be covered
> (e.g. bitmap sizes bigger than available payload limiting the MTU to less than
> 1280), and some advanced ways of actually solving this (Bloom filters were
> mentioned I think). These are all interesting ideas and they merit a longer
> discussion to find the right balance. These are to be kept in a separate
> document, which can continue its life independently, and if the WG decides can
> be included as a future WG item. If a future devices implement these other
> fragmentation mechanisms, they will be perfectly compatible with the default
> Window mode (the Rule ID can indicate which fragmentation mode is used).
> 
> We would like to confirm that you approve the Window mode as the default
> mode for fragmentation to be included in the SCHC IP/UDP document.
> 
> Best,
> The chairs
> 
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Mon, 29 May 2017 23:36:14 +0200

Hi,

I also agree.

After looking carefully at evaluation results [1], an overall conclusion
is that it is possible to configure the window size to have low ACK
overhead at a reasonably low cost in terms of fragmentation header size
(and number of fragments for a given IPv6 packet size).

Supporting more than one window size (e.g. advertised by means of a
corresponding Rule ID), when possible, is a further interesting feature
for performance improvement.

On the other hand, I think we need more time to better analyze the
different proposals for Packet mode, so working on it in a different
document will allow for a longer term effort.

Cheers,

Carles

[1] I will soon share some slides on this...

> Hi Alex,
>
> I agree that the window mode provides enough support and flexibility for
> the basic use cases. The more advanced fragmentation mechanisms to be
> defined later on can be easily supported and communicated with Rule IDs,
> as you mention.
>
>> found at the following address:
>> https://www.ietf.org/proceedings/interim-

---

From: Laurent Toutain <[email-masked]>
Date: Tue, 30 May 2017 09:50:27 +0200

Hi,

+1,

I'm in favor of a universal solution in the main document. Optimizations
can occur after, but we need a better feed back from the field to see if
they are realistic. My only concern is the unidirectional mode where there
is not ACK, but a MIC at the end. It should remains since it is a expected
behavior, we have to derive it from window mode and we have also to define
a default MIC which detect efficiently fragment losses.

Laurent