Subject: Re: [lp-wan] Tickt #5: Decoupled Fragmentation and SCHC compression

From: Ana Minaburo <[email-masked]>
Date: Tue, 27 Mar 2018 15:49:20 +0200

On Mon, Feb 26, 2018 at 10:24 PM, Ana Minaburo <[email-masked]> wrote:

> Maybe it is possible to mention that the fragmentation can be decoupled
> and located near the NGW since for some LPWAN technologies there may be
> timing constraints?
>
> The Fragmentation and Compression are not decoupled because different
> locations imply different SCHC instances in the architecture, do we want to
> define this?
> And Architecture Modification is an implementation issue
>
> Ana: I think we can have different instances of SCHC where some of them
> only done compression and some other only fragmentation, but this is not
> defined in the actual version of the draft, normally you make compression
> and if you need you use fragmentation or not depending on the L2 PDU size.
> ------
>
> Interim 16th
>
> ----
>
>    - fragmentation and compression are described together in the
>    architecture. Suggestion to have them decoupled. Fragmentation may be done
>    at application server, etc. Pascal: Laurent: separate compression for CoAP
>    and for UDP/IPv6. Can be bunched together later. Recommend to keep
>    fragmentation and compression together. Edgar: Some technologies has
>    multiple reception points, which means that the reconstruction of the
>    packet (if fragmented) has to be done in a point after the combining of
>    packets is done. This restricts the places where the fragmentation is
>    placed. In practice, this might be very close or just same place where the
>    decompresion happens. Ana: we can have a SCHC function in various places of
>    the architecture. Each instance can do either one or both of fragmentation
>    and compression. Alex: add a sentence in the doc? Pascal: curious that the
>    doc need a lot of changing if SCHC is divided in compression and
>    fragmentation Ana: It is in the document, but for now you always have SCHC
>    and fragmentation together in the same place. Maybe in the future we can
>    have them split into multiple places. Edgar: on first reading, had
>    difficulty understanding the flow. What is supposed to happen, in what
>    order? the doc goes back and forth between compression and fragmentation.
>    Edgar: especially the compression section seems less clear on the flow, the
>    mechanism. The connection between the two (frag and compr) is not clearly
>    described either. Pascal: inherited from the 6LoWPAN mindset Ana shows a
>    diagram with compressed packet followed by the fragmentation. Dominique: we
>    need to come up with a name for the "SCHC packet". The text currently uses
>    various circonlocutions for it.
>    - Pascal: some sentences could be written in clearer English. Beleives
>    that the intended meaning is what we want, but the way it is expressed
>    might be misleading.
>
> ----
>
>
> Ana: With the terminology sublayers, is this point more clear? Do we need
> to add something else?
>

--------

IETF101

 To better explain the way the SCHC Compression/Decompression and the SCHC
Fragmentation works, a new section is added called SCHC Overview in order
to explain where in the stack both functionalities are used and how their
interact.
The two functionalities are placed together and SCHC fragmentation is used
when it is needed only.

---

From: Ana Minaburo <[email-masked]>
Date: Tue, 27 Mar 2018 16:58:22 +0200

--------

IETF101

To better explain the way the SCHC Compression/Decompression and the SCHC
Fragmentation works, a new section is added called SCHC Overview in order
to explain the decoupled of the the two functionalities an their situation.
A figure is added where it is shown the functionalities and where are they
placed in the architecture.

Discussion:

   - Edgar: we have had that discussion in the interim. Depending on tech,
   we would not have frag at all

   - It might be good to decide whether there is fragmentation in the
   technology specific document.

   - Dominique: yes, we had your case in mind, so we will add the diamond
   shape to indicate the condition ("if" frag is needed or not)

   - Suresh:

   - Edgar: in NB-IoT, segmentation can be done on the lower layer, it
   makes sense not to have fragmentation in certain transmission modes from
   the overhead perspective

   - For NB-Iot you can have link adaptation. You don't have any idea about
   the size until a couple of ms before the transmission

   - Dominique: What will be the correct term here. We are refurring to L2,
   but maybe

   - Alex: This figure  is only for global view, maybe it should not be too
   complicated in order to make it easier to people to grasp.

   - Dominique: We are discussing between the previous figure, the
   currently proposed one, or a diamond like shape.

   - Edgar: What does it mean "if needed". Mayabe it should be explained some
   sort of default and point to the dedicated tecnology documents for a more
   specific treatment .

   - Suresh: I would like have some information that the decision is made
   in the "if" part, and maybe have a reference to a place where it is
   explained in more details.

   - Juan-Carlos: Supports previous points. Add Forward reference to L2
   technology, and add this "decision to fragment or not" to the list
   (appendix) of issues to be resolved in the L2 tech-specific documents.

New: figure will better explain this distinction between Compression and
Fragmentation

A packet (e.g. an IPv6 packet)
                  |
                                             ^
                 v
                                            |
  +---------------------------+
                  +------------------------------+
  | SCHC Compression |
         |SCHC Decompression|
 +----------------------------+
                  +------------------------------+
                 |
                                             |
        SCHC packet
                                   |
                 |
                                             |
                 | IF No Fragmentation (Ref. section for the decision)
               |
                +------------------------------- transmission
-------------------------------- -->|
                 |
                                             |
                 |
                                             |
 +---------------------------+
                   +---------------------------+
 |SCHC Fragmentation|
            | SCHC Reassembly |
+----------------------------+
                   +---------------------------+
                 |
                                             ^
      SCHC Fragment(s)
                              |
                 |
                                             |
                 |
                                             |
                 |
                                             |
                 v
                                            ^
                  ------------------------------
------transmission-------------------------------->
                 <----------------------------------SCHC
ACK------------------------------------

The IF decision will be explained in the text of the section, the
definition of this decision needs to be taken in the technology-documents,
this will be an input for ticket #15
<https://trac.ietf.org/trac/lpwan/ticket/15>.