Subject: Re: [lp-wan] Decoupled Fragmentation/Compression

From: <[email-masked]>
Date: Tue, 21 Aug 2018 06:57:30 +0000

Hello Bart,

Better late than never, let me try to complement Carles' response. See
inline. I hope this helps.
By the way, is there anything we could do to make the text clearer wrt
your question?
Best regards,

Dominique

Le 23/07/18 07:38, « lp-wan on behalf of Carles Gomez Montenegro »
<[email-masked] on behalf of [email-masked]> a écrit :

>Dear Bart,
>
>Thanks for your message.
>
>Please find below my inline responses.
>
>> Dear,
>>
>> Figure 3 (in v16 of the draft) shows that the Compression and
>> Fragmentation mechanism are decoupled.
>> The decision to use Fragmentation or not is left to each LPWAN
>>technology
>> over which SCHC is applied.
[DB] indeed, some LPWAN technologies can decide to not use the
fragmentation mechanism provided in this draft at all, e.g. because they
have their own.

>
>Rather, fragmentation needs to be used if a SCHC Packet exceeds the
>maximum payload size of the underlying LPWAN technology.
>
>> Does this mean that a sender and receiver must agree upon Fragmentation
>> beforehand? Or should this be applied dynamically?
[DB] in the case I described, both ends of the link statically know that
SCHC Fragmentation is not used, therefore no Rule needs to be allocated
for that purpose.
In the complementary case, all comments by Carles apply.

>>
>> If not done dynamically, unfragmented packets (which are very likely to
>> happen), will add a serious overhead (DTAG, W, FCN and MIC (because each
>> unfragmented packet will be the last one)).
>
>The point here is that the Rule ID is set by the sender to indicate
>whether the PDU being sent is a SCHC Fragment or not. If a SCHC Packet
>does not need to be fragmented, it will not use the fragmentation header.
>
>The receiver needs to know beforehand the Rule IDs that may be used by the
>sender.
>
>> If done dynamically, one could add a bit in front of the Rule ID to
>>inform
>> the receiving side about a fragmented packet.
>
>In fact it is not necessary to dedicate a whole bit for that. As explained
>in my previous comment, the Rule ID bits are used to indicate whether the
>PDU being sent is a SCHC Fragment or not.
>
>I hope this helps.
>
>Cheers,
>
>Carles
>
>
>> This would limit the number of rules that can be applied, but without
>>any
>> overhead.
>>
>> Kind regards,
>> Bart
>>
>> Bart Moons
>> Ghent University - imec
>> IDLab
>> iGent Tower - Department of Information Technology
>> Technologiepark-Zwijnaarde 15, B-9052 Ghent, Belgium
>> T: +32 472 42 23 91
>> E: [email-masked]
>> W: http://IDLab.UGent.be
>> W: http://idlab.technology
>>
>> _______________________________________________
>> lp-wan mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/lp-wan
>>
>
>
>_______________________________________________
>lp-wan mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/lp-wan

_________________________________________________________________________________________________________________________

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.