Subject: Re: [lp-wan] Ticket #13: Terminology Sublayers

From: Ana Minaburo <[email-masked]>
Date: Tue, 27 Mar 2018 17:03:56 +0200

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

> One topic that appears to be important (based on feedback from the
> reviewers) is to better clarify the different stages and the order of the
> operations defined by SCHC (for a sender, first, it is compression, then
> fragmentation, if needed). This would be basically introductory material.
>
> Also, there are terminology issues (e.g. how do we call the data unit after
> compression?).
>
> So here are some proposals.
>
> 1.- We may define that SCHC comprises two sublayers (i.e. compression
> sublayer and fragmentation sublayer, as shown in the figure. Would there
> be any (hidden) issues involved by adding this to the document?
>
> +----------------+ \
> | Compression | \
> +----------------+ > SCHC
> | Fragmentation | /
> +----------------+ /
>
> 2.- Two terms are proposed below:
>
>    - “SCHC packet”: a packet (e.g. an IPv6 packet) whose header has been
>    compressed per the header compression mechanism defined in this document.
>    If the header compression process is unable to actually compress the packet
>    header, the packet with the uncompressed header is still called an SCHC
>    packet (in this case, a Rule ID is used to indicate that the packet header
>    has not been compressed).
>
>
>    - “SCHC fragment”: a data unit that carries a subset of the bytes of
>    an SCHC packet. Fragmentation is needed when the size of an SCHC packet
>    exceeds the available payload size of the data unit of the layer underlying
>    SCHC.
>
> 3.- Would the following diagram (for a sender) provide further clarity
> regarding what SCHC defines?
>
>                                    IPv6 packet
>
>                                     |
>
>             /                       V
>
>            |                 +--------------+
>
>            |                 | compression |
>
>            |                 +--------------+
>
>            |                           |
>
> SCHC <                    SCHC packet
>
>             |                          |
>
>             |                          V
>
>             |           +----------------+
>
>             |            | fragmentation | (if needed)
>
>             |            +----------------+
>
>             |                        |
>
>              \                       V
>
>                        SCHC fragment (if needed)
>
> We may include content such as the one above in the next revision of SCHC,
> so please do not hesitate to provide your feedback.
>
>

----------
IETF 101

In order to clarify the terminology of all the draft, a new section called
Overview is added with all the vocabulary and some figures showing the
different components of the SCHC Compression and the SCHC Fragmentation.
There are also some definitions of the lines in the Rules in order to
better understand the definitions all over the document (Field
Description), the ACK now are SCHC ACK, SCHC Packet, SCHC Fragment.

   - #5 #13 : Overview, comments ask precision on how Compression and
   fragmentation are arranged

   - Ana: The SCHC overview (tickets) were addressed by adding text on how
   the fragmentation and compression are working together.

   - first step is compression, if there is no rule a specific rule Id is
   added.

   - Dominique: One of the issue was that there was no name for the
   remaining part of the compression - "the SCHC packet"

   - Ana: SCHC packet is a compressed packet or a packet for which
   compression has not been possible (but it will also have a Rule ID)

   - Dominique: There will be capitalization to indicate a SCHC "P"acket and
   SCHC "F"ragment

   - A next figure is proposed  for -11 to explain the link between
   compression and fragmentation

   - Ana explains a figure.

   - After SCHC Compression, if SCHC packet fits L2 there will be no
   Fragmentation and, thus, it will b e transmitted. Otherwise, there will
   be a SCHC Fragmentation.

   - Thus, the SCHC packet will be splitted to SCHC Fragment(s) and then
   transmitted.

   -

   - JC Zúñiga; Does this assume any rule ID space.

   - Dominique: We will come back to this later.

   -

   - Alex requests the room to raise their hand or come to the mic if they
   do not agree with the following open tickets.

   - Rahul Jadhav (from Jabber - Shoichi): how can you know if a packet has
   not been compressed or is a fragment?

   - Ana: based on the Rule ID. We have a slide later

   -

   - Dominique: clarification in terminology:

   - - compressed header : Something that was not understood was that we
   are only compressing the headers, not the payload itself.

   - - compresison residue: what is not in the rule and has to be sent

   - - fragmentation header

   -

   - JCZ: simplify the figure: just one fragment in the figure

   -

   - Ack was defined as a special case of a fragment, but it is confusing;

   - new term: SCHC Ack

   -

   - No name for line in rule table => Field Description.

   -

   - Georgios: Asks about the figure on slide 8 in connection to Acks.

   - Ana: ACK are only for SCHC Fragments.

   - Dominique: Should we add SCHC ACK in SCHC Overview figure? "Yes" in
   the room.

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------------------------------------

---

From: <[email-masked]>
Date: Tue, 27 Mar 2018 15:23:53 +0000

Hello Ana

Thanks for this proposal.
Since we show the SCHC ACK flowing backward, I suggest we show the SCHC fragment flowing forward, instead of the vague term "transmission".
Same for the transmission of the SCHC Packet.
How about this ? (I changed the font to Courier so that it be fixed-width. Easier to draw asci art!)
Thanks

Dominique

A packet (e.g. an IPv6 packet)
           |                                                                                  ^
           v                                                                                  |
  +—-----------------+                                                              +--------------------+
  | SCHC Compression |                                                              | SCHC Decompression |
  +------------------+                                                              +--------------------+
           |                                                                                  |
           |                                                                                  |
           |                                                                                  |
           |   If no fragmentation (*)                                                        |
           +------------------------------ SCHC Packet -------------------------------------->|
           |                                                                                  |
           |                                                                                  |
 +--------------------+                                                               +-----------------+
 | SCHC Fragmentation |                                                               | SCHC Reassembly |
 +--------------------+                                                               +-----------------+
        ^     |                                                                            ^     |
        |     |                                                                            |     |
        |     |                                                                            |     |
        |     |                                                                            |     |
        |     |                                                                            |     |
        |     |                                                                            |     |
        |     +--------------------------- SCHC Fragments ---------------------------------+     |
        +------------------------------------ SCHC ACK ------------------------------------------+

          SENDER                                                                          RECEIVER

*: see Section xxx for the decision.

De : lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of Ana Minaburo <[email-masked]<mailto:[email-masked]>>
Répondre à : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date : Tuesday 27 March 2018 17:03
À : lp-wan <[email-masked]<mailto:[email-masked]>>
Cc : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : Re: [lp-wan] Ticket #13: Terminology Sublayers

On Mon, Feb 26, 2018 at 9:59 PM, Ana Minaburo <[email-masked]<mailto:[email-masked]>> wrote:

+----------------+ \
| Compression | \

  *   “SCHC packet”: a packet (e.g. an IPv6 packet) whose header has been compressed per the header compression mechanism defined in this document. If the header compression process is unable to actually compress the packet header, the packet with the uncompressed header is still called an SCHC packet (in this case, a Rule ID is used to indicate that the packet header has not been compressed).

  *   “SCHC fragment”: a data unit that carries a subset of the bytes of an SCHC packet. Fragmentation is needed when the size of an SCHC packet exceeds the available payload size of the data unit of the layer underlying SCHC.

                                   IPv6 packet

                                    |

            /                       V

           |                 +--------------+

           |                 | compression |

           |                 +--------------+

           |                           |

SCHC <                    SCHC packet

            |                          |

            |                          V

            |           +----------------+

            |            +----------------+

            |                        |

             \                       V

----------
IETF 101

In order to clarify the terminology of all the draft, a new section called Overview is added with all the vocabulary and some figures showing the different components of the SCHC Compression and the SCHC Fragmentation. There are also some definitions of the lines in the Rules in order to better understand the definitions all over the document (Field Description), the ACK now are SCHC ACK, SCHC Packet, SCHC Fragment.

  *   #5 #13 : Overview, comments ask precision on how Compression and fragmentation are arranged

  *   Ana: The SCHC overview (tickets) were addressed by adding text on how the fragmentation and compression are working together.

  *   first step is compression, if there is no rule a specific rule Id is added.

  *   Dominique: One of the issue was that there was no name for the remaining part of the compression - "the SCHC packet"

  *   Ana: SCHC packet is a compressed packet or a packet for which compression has not been possible (but it will also have a Rule ID)

  *   Dominique: There will be capitalization to indicate a SCHC "P"acket and SCHC "F"ragment

  *   A next figure is proposed  for -11 to explain the link between compression and fragmentation

  *   Ana explains a figure.

  *   After SCHC Compression, if SCHC packet fits L2 there will be no Fragmentation and, thus, it will b e transmitted. Otherwise, there will be a SCHC Fragmentation.

  *   Thus, the SCHC packet will be splitted to SCHC Fragment(s) and then transmitted.

  *

  *   JC Zúñiga; Does this assume any rule ID space.

  *   Dominique: We will come back to this later.

  *

  *   Alex requests the room to raise their hand or come to the mic if they do not agree with the following open tickets.

  *   Rahul Jadhav (from Jabber - Shoichi): how can you know if a packet has not been compressed or is a fragment?

  *   Ana: based on the Rule ID. We have a slide later

  *

  *   Dominique: clarification in terminology:

  *   - compressed header : Something that was not understood was that we are only compressing the headers, not the payload itself.

  *   - compresison residue: what is not in the rule and has to be sent

  *   - fragmentation header

  *

  *   JCZ: simplify the figure: just one fragment in the figure

  *

  *   Ack was defined as a special case of a fragment, but it is confusing;

  *   new term: SCHC Ack

  *

  *   No name for line in rule table => Field Description.

  *

  *   Georgios: Asks about the figure on slide 8 in connection to Acks.

  *   Ana: ACK are only for SCHC Fragments.

  *   Dominique: Should we add SCHC ACK in SCHC Overview figure? "Yes" in the room.

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------------------------------------

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Ana Minaburo <[email-masked]>
Date: Tue, 27 Mar 2018 17:44:55 +0200

Hello! :)

Yes, I think that now it is clear that the ACK is only used for
Fragmentation.

Ana

On Tue, Mar 27, 2018 at 5:23 PM, <[email-masked]> wrote:

> Since we show the SCHC ACK flowing backward, I suggest we show the SCHC
> fragment flowing forward, instead of the vague term "transmission".
>          | SCHC Decompression |
>         ^     |
>                  ^     |
>         +------------------------------------ SCHC ACK
> ------------------------------------------+
>
>
>           SENDER
>                RECEIVER
>
> De : lp-wan <[email-masked]> on behalf of Ana Minaburo <
> [email-masked]>
> Répondre à : "[email-masked]" <[email-masked]>
> À : lp-wan <[email-masked]>
> Cc : "[email-masked]" <[email-masked]>
>    - Ana: The SCHC overview (tickets) were addressed by adding text on
>    how the fragmentation and compression are working together.
>
>
>    Fragmentation and, thus, it will b e transmitted. Otherwise, there
>    will be a SCHC Fragmentation.
>
>
>    - Alex requests the room to raise their hand or come to the mic if
>    they do not agree with the following open tickets.
>
>
>    - Rahul Jadhav (from Jabber - Shoichi): how can you know if a packet
>    has not been compressed or is a fragment?
>
>
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>
>