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

[Ana Minaburo <[e-mail]>]

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, <[e-mail]> wrote:

> 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 <[e-mail]> on behalf of Ana Minaburo <
> [e-mail]>
> Répondre à : "[e-mail]" <[e-mail]>
> Date : Tuesday 27 March 2018 17:03
> À : lp-wan <[e-mail]>
> Cc : "[e-mail]" <[e-mail]>
> Objet : Re: [lp-wan] Ticket #13: Terminology Sublayers
>
>
> On Mon, Feb 26, 2018 at 9:59 PM, Ana Minaburo <[e-mail]> 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------------------------------------
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>
> _______________________________________________
> lp-wan mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lp-wan
>
>