Subject: [lp-wan] Ticket #12 Padding Place

From: ana minaburo <[email-masked]>
Date: Tue, 17 Apr 2018 10:35:54 +0200

Hello,

Here is the link to the description:

https://trac.ietf.org/trac/lpwan/ticket/12

This ticket is a little bit related to Ticket #11, but here the question
was where to put padding? If padding could be added between the
fragmentation header and the fragmentation payload?

- The overall Padding description has been done, section 8 was rewritten,
- In SCHC Compression and in SCHC Fragmentation parts a padding explanation
is added
- Padding is optional and the L2 technology documents need to define the
padding solution they want to use.

- To answer the question: Non, padding is not added between SCHC
fragmentation header and SCHC Fragmentation payload.
 * Padding may be added :
      - after SCHC Compression
      - Last Fragment (All-1) of fragmentation
      - SCHC ACK format

Does the question has been answered clearly? May I close this ticket?

Ana

---

From: <[email-masked]>
Date: Tue, 24 Apr 2018 15:53:33 +0000

Hello all,

In general, and especially in this case, I find it difficult to follow the progress related to the ticket.
There is one explanatory text in the mail below, dated Apr 17th 10:35.
There is another explanatory text in the ticket tracker. https://trac.ietf.org/trac/lpwan/ticket/12
There is some text in the draft (-10 and now –11).

I think we said at IETF101 in London that shifting bytes in the CPU consumes a negligible amount of resources compared to reception, etc.
Therefore we don’t mind having a random-sized SCHC Packet header followed by bytes of payload followed by some padding bits, even though it means that the whole payload will have to be reconstructed by shifting data from the reception buffer.
Therefore we allow ourselves the luxury to specify that, if padding is needed after compression, the padding bits must be added after the payload, as opposed to between compressed header and payload.
This reduces the variability of technology-dependant implementations.

However, I see in –11:
"In compression, the rule and the compression residues are not aligned
   on a byte, but payload following the residue is always a multiple of
   8 bits.  In that case, padding bits can be added after the payload to
   reach the first byte boundary."
This says "can", not MUST.
Nit : what does "In that case" mean?

"The padding is not mandatory and is optional to the technology-
   specific document to give a different solution.  In this docuement
   there are some inputs on how to manage the padding."

Therefore, I believe we are now saying that we don't mandate anything regarding the placement of the padding buts after compression.
This seems to contradict the answer in the mail below: "To answer the question: Non, padding is not added between SCHC fragmentation header and SCHC Fragmentation payload".

Am I the only one confused here?

Two more points

  *   the text in the draft currently says that padding may be added "after compression". It does not say that padding may also be added after no-compression (no rule found). This whole text about padding (notably Section 8) should use the new terminology (SCHC Packet, etc.) to avoid this ambiguity.
  *   Thinking of all of this again, we could add padding bits into the SCHC Packet only when the SCHC Packet is transmitted unfragmented. We could revert the statement "SCHC Fragmentation works on a byte aligned SCHC Packet" and have fragmentation only once: either when transmitting a SCHC Packet unfragmented or when transmitted the last fragment of a fragmented SCHC Packet. Now that we have a clear separation of the two functions, this seems a no-brainer to me. Does anybody recall why we decided to go two-padding way ?

Dominique
De : lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of ana minaburo <[email-masked]<mailto:[email-masked]>>
Date : Tuesday 17 April 2018 10:35
À : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : [lp-wan] Ticket #12 Padding Place

Hello,

This ticket is a little bit related to Ticket #11, but here the question was where to put padding? If padding could be added between the fragmentation header and the fragmentation payload?

- The overall Padding description has been done, section 8 was rewritten,
- In SCHC Compression and in SCHC Fragmentation parts a padding explanation is added
- Padding is optional and the L2 technology documents need to define the padding solution they want to use.

- To answer the question: Non, padding is not added between SCHC fragmentation header and SCHC Fragmentation payload.
 * Padding may be added :
      - after SCHC Compression
      - Last Fragment (All-1) of fragmentation
      - SCHC ACK format

Ana

_________________________________________________________________________________________________________________________

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: Juan Carlos Zuniga <[email-masked]>
Date: Tue, 24 Apr 2018 16:17:14 +0000

Hi Dominique,

I agree that the text in section 8 does not quite follow the progression of the discussions.

I see that the last paragraph stating that padding is more tech-specific relates to the discussions we had at IETF 101 in London. However, as you mention, the previous paragraphs would need to be updated to remove ambiguities.

Please see more comments in-line:

From: lp-wan [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: April 24, 2018 11:54 AM
To: ana minaburo <[email-masked]>; [email-masked]
Subject: Re: [lp-wan] Ticket #12 Padding Place

Hello all,

[JCZ] I agree with this statement.

However, I see in –11:

Two more points

[JCZ] Indeed

[JCZ] I don’t recall that and in fact I would not like to see the two-padding need in the text. I much prefer what you say that either padding is done when the SCHC Packet is to be transmitted unfragmented, or it will be done by the fragmentation function, normally when transmitting the last fragment.
Best,
Juan Carlos

Hello,

Ana

Thank you.