Re: [lp-wan] Doub about sending missing tiles

[Rodrigo Muñoz Lara <[e-mail]>]

Hi Dominique

My answer below:

El vie., 31 ene. 2020 a las 5:15, <[e-mail]> escribió:

> Hello Rodrigo,
>
> Thanks for your questions, they are all good!
>
> > How do I tell the recipient which tiles I am sending in the SCHC
> fragment if the lost tiles are not contiguous?
> A SCHC Fragment can only send contiguous tiles.
>
*[Rodrigo] OK, I understand *

>
> > what happens if the lost tiles are not contiguous? Should the sender
> send them in the same way in a single SCHC fragment?
> If the lost tiles are not all contiguous, you can mix and match between
> the two options below
>
>    - Send one SCHC Fragment per missing tile (or better, per set of
>    contiguous missing tiles) *[Rodrigo] This is the option that I have
>    chosen to implement. Thank you*
>    - Send a SCHC Fragment with contiguous tiles that include the missing
>    ones. Indeed, the specification does not forbid to resend tiles that have
>    already been correctly received (we only say that the missing tiles have to
>    be resent).
>
>
> It's your implementor's freedom to choose a strategy:
>
>    - The simplest algorithm is to send a SCHC Fragment for each missing
>    tile.
>    - An easy improvement to this algorithm is to try to group contiguous
>    missing tiles into one SCHC Fragment, as much as the current MTU allows for.*
>    [Rodrigo] This is the option that I have chosen to implement. Thank you *
>    -  A more complex  algorithm is to evaluate the trade-off between
>    sending SCHC Fragments with only missing tiles, and sending SCHC Fragments
>    that combine missing tiles and correctly received tiles, with the goal of
>    minimising the total overhead (I.e. tradeoff between sending SCHC headers
>    versus resending correctly received tiles).
>
> Your choice!
>
> Best regards
>
> Dominique
>
> De : Rodrigo Muñoz Lara <[e-mail]>
> Date : Friday 31 January 2020 02:27
> À : Dominique Barthel <[e-mail]>
> Cc : "[e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>, Sandra Cespedes <[e-mail]>
> Objet : Re: [lp-wan] Doub about sending missing tiles
>
> Hi
>
> Thanks for your answer. Yes, that is the answer to my question.
>
> Related to the same,  I have a new question
>
> The draft indicates that when the sender receives a SCHC ACK with a bitmap
> that indicates lost tiles, the sender must send the lost tiles in a new
> SCHC fragment.
>
> My question is, what happens if the lost tiles are not contiguous? Should
> the sender send them in the same way in a single SCHC fragment? How do I
> tell the recipient which tiles I am sending in the SCHC fragment if the
> lost tiles are not contiguous?
>
> Thanks
>
> El lun., 30 dic. 2019 a las 14:29, <[e-mail]>
> escribió:
>
>> Hello Rodrigo,
>>
>> Thanks for you mail.
>> I'm unsure about what part of the text you actually refer to.
>> Section 8.3.1.2 is about the All-1 Fragment SCHC format
>>
>> https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-24#section-8.3.1.2
>>
>>
>> From the text you quote, I think you are talking about the Sender
>> Behavior of Ack-on-Error mode (section (8.4.3.1).
>> In this section, we are simply saying that the Sender must resend the
>> missing tiles. It may use several Fragments for this.
>> It does not matter that the tiles are re-send packed the same way in SCHC
>> Fragments as they were packed in the initial transmission.
>> Typically, if the MTU has changed to a lower value since the initial
>> transmission, the retransmitted tiles will have to be packed in a different
>> way (less tiles per SCHC Fragment).
>> Does this answer your question?
>> Best regards, and happy end of year
>>
>> Dominique
>>
>> De : lp-wan <[e-mail]> on behalf of Rodrigo Muñoz Lara <
>> [e-mail]>
>> Date : Friday 27 December 2019 14:33
>> À : "[e-mail]" <[e-mail]>
>> Cc : "[e-mail]" <[e-mail]>, Sandra Cespedes <
>> [e-mail]>
>> Objet : [lp-wan] Doub about sending missing tiles
>>
>> Dear Author,
>>
>> I have a question about draft
>> "draft-ietf-lpwan-ipv6-static-context-hc-24". In section 8.3.1.2 say:
>>
>> "*On receiving a SCHC ACK, if the W field in the SCHC ACK not
>> corresponds to the last window of the SCHC Packet:*
>>
>>    -
>>
>>    *MUST send SCHC Fragment messages containing the tiles that reported missing in the SCHC ACK*"
>>
>>
>>
>> What happened if the missing tiles do not fit in a SCHC fragment?
>>
>> Regards
>>
>> _________________________________________________________________________________________________________________________
>>
>> 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.
>>
>> _________________________________________________________________________________________________________________________
>
> 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.
>
>