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

Rodrigo Muñoz Lara <rmunozlara@ing.uchile.cl> Fri, 31 January 2020 01:27 UTC

Return-Path: <rmunozlara@ing.uchile.cl>
X-Original-To: lp-wan@ietfa.amsl.com
Delivered-To: lp-wan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C909A12003F for <lp-wan@ietfa.amsl.com>; Thu, 30 Jan 2020 17:27:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.298
X-Spam-Level:
X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ing.uchile.cl header.b=oNCPxbsu; dkim=pass (1024-bit key) header.d=ing.uchile.cl header.b=oNCPxbsu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxQS69YnfRtt for <lp-wan@ietfa.amsl.com>; Thu, 30 Jan 2020 17:27:45 -0800 (PST)
Received: from mail.cec.uchile.cl (mail2.cec.uchile.cl [200.9.100.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB6A0120024 for <lp-wan@ietf.org>; Thu, 30 Jan 2020 17:27:44 -0800 (PST)
Received: from mail.cec.uchile.cl (localhost [127.0.0.1]) by mail.cec.uchile.cl (Postfix) with ESMTP id 9808AA0A81 for <lp-wan@ietf.org>; Thu, 30 Jan 2020 22:27:40 -0300 (-03)
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.cec.uchile.cl 9808AA0A81
Authentication-Results: mail2.cec.uchile.cl; dmarc=pass (p=none dis=none) header.from=ing.uchile.cl
Authentication-Results: mail2.cec.uchile.cl; spf=pass smtp.mailfrom=rmunozlara@ing.uchile.cl
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.cec.uchile.cl 9808AA0A81
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ing.uchile.cl; s=default; t=1580434060; bh=eB5a+vHSJLy181snYYr9wACVS2hWuC4oLtmbbfOBWxw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=oNCPxbsu78PvmisjB69VCG0YUYRySBZsFySzfj47jpPjsVvVT0nUkh0A4rF9tuQI4 ssLgpxG3hPyqxjAJEvjqKbJs6wiVfRBByLmF8dJfsl0I5a/652bJ+21hiz7JY6B9To tTUVvveJBvUN7YGRK8jrP0+j+X5v8zO1yOevgUI8=
Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com [209.85.217.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (not verified)) by mail.cec.uchile.cl (Postfix) with ESMTPSA id 02BCFA0A9B for <lp-wan@ietf.org>; Thu, 30 Jan 2020 22:27:39 -0300 (-03)
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.cec.uchile.cl 02BCFA0A9B
Authentication-Results: mail2.cec.uchile.cl; dmarc=pass (p=none dis=none) header.from=ing.uchile.cl
Authentication-Results: mail2.cec.uchile.cl; spf=pass smtp.mailfrom=rmunozlara@ing.uchile.cl
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.cec.uchile.cl 02BCFA0A9B
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ing.uchile.cl; s=default; t=1580434060; bh=eB5a+vHSJLy181snYYr9wACVS2hWuC4oLtmbbfOBWxw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=oNCPxbsu78PvmisjB69VCG0YUYRySBZsFySzfj47jpPjsVvVT0nUkh0A4rF9tuQI4 ssLgpxG3hPyqxjAJEvjqKbJs6wiVfRBByLmF8dJfsl0I5a/652bJ+21hiz7JY6B9To tTUVvveJBvUN7YGRK8jrP0+j+X5v8zO1yOevgUI8=
Received: by mail-vs1-f46.google.com with SMTP id t12so3366164vso.13 for <lp-wan@ietf.org>; Thu, 30 Jan 2020 17:27:39 -0800 (PST)
X-Gm-Message-State: APjAAAVktFSoHyrMdi4NT8qxuqwHR7X/H2zZ2KVHWjuFK07fxuT07rv2 MitV5o9EuUovUifAQtmgIIaIlrmrOXdnAA8ferg=
X-Google-Smtp-Source: APXvYqzPU9xQcj3r+GJHEfgfVhF7/KpX+1D8MoEZd8rg80/40Ib47zaUUXByvodwdQw4Mq9DOVn2GsbG9HB54m4MngU=
X-Received: by 2002:a67:1081:: with SMTP id 123mr5226324vsq.199.1580434058139; Thu, 30 Jan 2020 17:27:38 -0800 (PST)
MIME-Version: 1.0
References: <CALJ+G3UODKCPD=JDC0x-0rE663FcJj0P5N3eHCz9m--=jZby-g@mail.gmail.com> <30188_1577726994_5E0A3412_30188_419_1_DA2FF070.6E08D%dominique.barthel@orange.com>
In-Reply-To: <30188_1577726994_5E0A3412_30188_419_1_DA2FF070.6E08D%dominique.barthel@orange.com>
From: Rodrigo Muñoz Lara <rmunozlara@ing.uchile.cl>
Date: Thu, 30 Jan 2020 22:27:27 -0300
X-Gmail-Original-Message-ID: <CALJ+G3Xpu+bUVWpLrGu1834Enqy5O2ZKrmNAjzmdEt_W0TRXmg@mail.gmail.com>
Message-ID: <CALJ+G3Xpu+bUVWpLrGu1834Enqy5O2ZKrmNAjzmdEt_W0TRXmg@mail.gmail.com>
To: dominique.barthel@orange.com
Cc: "lp-wan@ietf.org" <lp-wan@ietf.org>, "ogimenez@semtech.com" <ogimenez@semtech.com>, Sandra Cespedes <scespedes@ing.uchile.cl>
Content-Type: multipart/alternative; boundary="000000000000a089c1059d657afc"
X-Virus-Scanned: ClamAV using ClamSMTP
Archived-At: <https://mailarchive.ietf.org/arch/msg/lp-wan/xq_Kpo1wsde5tRpCNHP-BYZfM1E>
Subject: Re: [lp-wan] Doub about sending missing tiles
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" <lp-wan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lp-wan>, <mailto:lp-wan-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lp-wan/>
List-Post: <mailto:lp-wan@ietf.org>
List-Help: <mailto:lp-wan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lp-wan>, <mailto:lp-wan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jan 2020 01:27:48 -0000

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, <dominique.barthel@orange.com> 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 <lp-wan-bounces@ietf.org> on behalf of Rodrigo Muñoz Lara <
> rmunozlara@ing.uchile.cl>
> Date : Friday 27 December 2019 14:33
> À : "lp-wan@ietf.org" <lp-wan@ietf.org>
> Cc : "ogimenez@semtech.com" <ogimenez@semtech.com>, Sandra Cespedes <
> scespedes@ing.uchile.cl>
> 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.
>
>