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. > >
- [lp-wan] Doub about sending missing tiles Rodrigo Muñoz Lara
- Re: [lp-wan] Doub about sending missing tiles dominique.barthel
- Re: [lp-wan] Doub about sending missing tiles Rodrigo Muñoz Lara
- Re: [lp-wan] Doub about sending missing tiles dominique.barthel
- Re: [lp-wan] Doub about sending missing tiles Rodrigo Muñoz Lara