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

From: "core issue tracker" <[email-masked]>
Date: Fri, 06 May 2016 13:01:30 -0000

#410: Initial MID on restart after blockwise transfer

 Doing tests on firmware updates using
 - a blockwise transfer (draft-ietf-core-block-20),
 - a random initial value of the MID (as recommended in RFC7252, 4.4. last
 part of implementation note),
 - I found on restarts short after such a transfer, a rather high
 probability of MID collision.
 (This is obvious caused by having rather more MIDs in use, than in normal
 communication situations).

 Therefore I would propose to add an implementation note in "draft-ietf-
 core-block" or/and "draft-ietf-lwig-coap" for proper handling of that
 situation.

 On my experience there are two possibilities:
 a: on graceful shutdown (after blockwise) store the last MID and load it
 on restart.
 b:  if on restart (after blockwise) communication errors occur, wait for
 at least EXCHANGE_LIFETIME to escape the “probable” MID collision. This
 may also be the strategy, when a fails to load the MID for any reason.

-- 
-------------------------------------+-------------------------------------
 Reporter:  achim.kraus@bosch-       |      Owner:  draft-ietf-core-
  si.com                             |  [email-masked]
     Type:  editorial                |     Status:  new
 Priority:  minor                    |  Milestone:
Component:  block                    |    Version:
 Severity:  -                        |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/core/trac/ticket/410>
core <https://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Fri, 06 May 2016 13:03:29 -0000

Comment (by [email-masked]):

 I hope "new editorial" is the right one :-).
 Otherwise feel free to change that.

 Severity:  -                        |  Resolution:
 Keywords:                           |

Ticket URL: <https://trac.tools.ietf.org/wg/core/trac/ticket/410#comment:1>
core <https://tools.ietf.org/core/>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 06 May 2016 17:52:43 +0200

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

---

From: "Kraus Achim (INST/ESY1)" <[email-masked]>
Date: Mon, 9 May 2016 12:45:55 +0000

Hi Carsten,

> 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 

[email-masked]

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

-----Ursprüngliche Nachricht-----
Von: Carsten Bormann [mailto:[email-masked]] 
Gesendet: Freitag, 6. Mai 2016 17:53
An: [email-masked]
Cc: [email-masked]; Kraus Achim (INST/ESY1); [email-masked]
Betreff: Re: [core] #410 (block): Initial MID on restart after blockwise transfer

Hi Achim,

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).

Grüße, Carsten