Re: [core] #410 (block): Initial MID on restart after blockwise transfer

"Kraus Achim (INST/ESY1)" <Achim.Kraus@bosch-si.com> Mon, 09 May 2016 12:46 UTC

From: "Kraus Achim (INST/ESY1)" <Achim.Kraus@bosch-si.com>
To: Carsten Bormann <cabo@tzi.org>, "trac+core@zinfandel.tools.ietf.org" <trac+core@zinfandel.tools.ietf.org>
Thread-Topic: [core] #410 (block): Initial MID on restart after blockwise transfer
Thread-Index: AQHRp5dvDrse8dD2TUSqr2zTL8r+H5+rvqiAgAAvSICABJi9sA==
Date: Mon, 09 May 2016 12:45:55 +0000
Message-ID: <BC36447FF5C62E46BEF3F124D3C1E8925E19BC2E@imbpw2exd01.bosch-si.com>
References: <064.4cbf8d09348a03ec25afdd8a19df82d0@trac.tools.ietf.org> <079.91253355a6c5469f216ec0c7fd810306@trac.tools.ietf.org> <572CBDCB.9090000@tzi.org>
In-Reply-To: <572CBDCB.9090000@tzi.org>
Accept-Language: de-DE, en-US
Content-Language: de-DE
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/7itUL7D_jDBghZWjPYZ152rQvoE>
Cc: "draft-ietf-core-block@tools.ietf.org" <draft-ietf-core-block@tools.ietf.org>, "core@ietf.org" <core@ietf.org>
Subject: Re: [core] #410 (block): Initial MID on restart after blockwise transfer
Precedence: list

Hi Carsten,

> Can you be a bit more specific about the scenario?

> So maybe your scenario is one where the node fetches the new firmware from a hub per block-wise GET, then restarts, and then tries to talk to the same hub (using the same port number) right after restart?

Yes, your right, that's the case. I tried to test a "LWM2M Firmware Update" using a "package URI" pointing back to the same LWM2M server, so that the note uses a block-wise (CON GET requests) to transfer the firmware. Short later the note tries to register after a restart (CON PUT request).   

> I don't think it is really entirely specific to block-wise transfers (the firmware fetch process might just be using another way to do the bulk transfer).

My intent to mention the block-wise transfer was, that it "consumes naturally more MIDs" then “usually traffic”, and therefore it’s one the ingredients of the situation.

Mit freundlichen Grüßen / Best regards

Achim Kraus

Bosch Software Innovations GmbH
Communications (INST/ESY1)
Stuttgarter Straße 130
71332 Waiblingen
GERMANY
www.bosch-si.de
www.blog.bosch-si.com 

achim.kraus@bosch-si.com

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn



-----Ursprüngliche Nachricht-----
Von: Carsten Bormann [mailto:cabo@tzi.org] 
Gesendet: Freitag, 6. Mai 2016 17:53
An: trac+core@zinfandel.tools.ietf.org
Cc: draft-ietf-core-block@tools.ietf.org; Kraus Achim (INST/ESY1); core@ietf.org
Betreff: Re: [core] #410 (block): Initial MID on restart after blockwise transfer

Hi Achim,

thank you for this observation!

Can you be a bit more specific about the scenario?

If I imagine a hub/server doing a firmware upgrade on a node via PUT (as in LWM2M), the selection of the MIDs is on the hub side, which is not the one that gets restarted by the firmware upgrade.

So maybe your scenario is one where the node fetches the new firmware from a hub per block-wise GET, then restarts, and then tries to talk to the same hub (using the same port number) right after restart?

I think this scenario would make great content for section 2.3 or 3.5 of lwig-coap.  I don't think it is really entirely specific to block-wise transfers (the firmware fetch process might just be using another way to do the bulk transfer).

(While we are talking about firmware upgrades, here's a pertinent pointer:
https://down.dsg.cs.tcd.ie/iotsu/
Just two weeks left before the submission deadline...)

Grüße, Carsten

[core] #410 (block): Initial MID on restart after… core issue tracker
Re: [core] #410 (block): Initial MID on restart a… core issue tracker
Re: [core] #410 (block): Initial MID on restart a… Carsten Bormann
Re: [core] #410 (block): Initial MID on restart a… Kraus Achim (INST/ESY1)