Subject: [Suit] Broadcast Delivery

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 24 Oct 2017 05:14:58 +0000

Delivery of firmware over a multicast transport mechanism is very hard and involves significant congestion issue. I don’t think the IETF currently has a transport protocol that's really suitable for this. I would prefer to see the WG charted for this  to be clearly out of scope for the first deliverable.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 26 Oct 2017 22:01:13 -0500

Hi, Cullen,

On Tue, Oct 24, 2017 at 12:14 AM, Cullen Jennings (fluffy) <[email-masked]
> wrote:

> Delivery of firmware over a multicast transport mechanism is very hard and
> involves significant congestion issue. I don’t think the IETF currently has
> a transport protocol that's really suitable for this. I would prefer to see
> the WG charted for this  to be clearly out of scope for the first
> deliverable.

The odds are at least 2:1 that I agree with you, but just to make sure
we're agreeing on the same thing, are you thinking that

   - firmware delivery over multicast transport would be out of scope for
   the first deliverable, or
   - firmware delivery over multicast transport with a purpose-specific
   congestion control would be out of scope for the first deliverable, or
   - development of a general-purpose multicast transport protocol
   appropriate for firmware delivery would be out of scope

?

Curiously yours,

Spencer, as an individual (who already balloted Yes on the SUIT charter)

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 26 Oct 2017 22:25:54 -0600

If we had some other group in the IETF that had put together a multicast transport protocol that worked well for things like this, I think there would be interest in using it for delivering firmware updates.

But doing a transport like that is not easy and should not be done in this WG - I think of it as a fairly different skill set than the people I would hope would come this WG. If such a thing got developed, I can imagine figuring out how to use that transport for this firmware update could be added at a later stage to this WG but I would still want to get a non multicast version done first as that is what is most needed. 

I am aware of the FLUTE work - that seemed hard to use for firmware updates so I had not pursued that for Cisco devices. If there are people doing firmware updates with FLUTE, I would *love* to hear about their experiences at the BOF. It could easily change my mind. 

> On Oct 26, 2017, at 9:01 PM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Cullen,
> 
> On Tue, Oct 24, 2017 at 12:14 AM, Cullen Jennings (fluffy) <[email-masked]> wrote:
> The odds are at least 2:1 that I agree with you, but just to make sure we're agreeing on the same thing, are you thinking that
> 	• firmware delivery over multicast transport would be out of scope for the first deliverable, or

Probably out of scope for v1 unless a suitable multicast transport protocol already exists.

> 	• firmware delivery over multicast transport with a purpose-specific congestion control would be out of scope for the first deliverable, or

If this WG would be doing the congestion control, then yes, out of scope for v1 

> 	• development of a general-purpose multicast transport protocol appropriate for firmware delivery would be out of scope

Definitely out of scope for this WG to last done. 

> _______________________________________________
> Suit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 27 Oct 2017 00:12:28 -0500

Hi, Cullen,

On Thu, Oct 26, 2017 at 11:25 PM, Cullen Jennings <[email-masked]> wrote:

>
> If we had some other group in the IETF that had put together a multicast
> transport protocol that worked well for things like this, I think there
> would be interest in using it for delivering firmware updates.
>
> But doing a transport like that is not easy and should not be done in this
> WG - I think of it as a fairly different skill set than the people I would
> hope would come this WG. If such a thing got developed, I can imagine
> figuring out how to use that transport for this firmware update could be
> added at a later stage to this WG but I would still want to get a non
> multicast version done first as that is what is most needed.
>
> I am aware of the FLUTE work - that seemed hard to use for firmware
> updates so I had not pursued that for Cisco devices. If there are people
> doing firmware updates with FLUTE, I would *love* to hear about their
> experiences at the BOF. It could easily change my mind.
>
>
> > Delivery of firmware over a multicast transport mechanism is very hard
> and involves significant congestion issue. I don’t think the IETF currently
> has a transport protocol that's really suitable for this. I would prefer to
> see the WG charted for this  to be clearly out of scope for the first
> deliverable.
> >
> >       • firmware delivery over multicast transport with a
> purpose-specific congestion control would be out of scope for the first
> deliverable, or
>
> >       • development of a general-purpose multicast transport protocol

Excellent, we agree. And I'm interested in requirements for multicast
transport protocols as they are identified.

Spencer

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 27 Oct 2017 07:23:32 +0200

> If we had some other group in the IETF that had put together a multicast transport protocol that worked well for things like this, I think there would be interest in using it for delivering firmwar…

MPL (RFC7731) actually is close enough to being a multicast transport protocol that it might be useful with some additional profiling.
(For a definition of “multicast”.)

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Fri, 27 Oct 2017 11:31:30 -0400

Cullen Jennings <[email-masked]> wrote:
    > But doing a transport like that is not easy and should not be done in
    > this WG - I think of it as a fairly different skill set than the people
    > I would hope would come this WG. If such a thing got developed, I can
    > imagine figuring out how to use that transport for this firmware update
    > could be added at a later stage to this WG but I would still want to
    > get a non multicast version done first as that is what is most needed.

I agree strongly: multicast is out of scope of this charter and should be.

Let's get the formats right and worry less about the transport for now.

the charter says:
    * A mechanism to transport firmware images to IoT devices.

but the work items do not include any transport work.

My take on this is that in order to get images to class 1 devices that we may
have to chop up the image into digestable bits, and this will require a
standard way to describe which chunk to transfer next.  That might not
involve any new technology; it could be done with rfc7233 HTTP/1.1 Range
Requests, or could be consist of a JSON manifest that included a bunch of
URLs for the chunks, or... there are many pre-existing things.

<BLUESKYING>
Also, if the devices are arranged in an LLN mesh (via RPL/MPL), then
multicast takes on a slightly different flavour than we are used to with
ethernet.   Depending upon the capabilities of the devices, it might be
possible for each layer in the mesh to feed the next layer; a kind of
application-layer multicast.

Yet, from an *operational* point of view, sometimes it's better to upgrade
devices from the leafs inward than from the inside outside, since it's less
disruptive if it turns out that there is a problem with the upgrade.
</BLUESKYING>

    > updates so I had not pursued that for Cisco devices. If there are
    > people doing firmware updates with FLUTE, I would *love* to hear about
    > their experiences at the BOF. It could easily change my mind.

:-)
Are you thinking about Cisco phone devices which might all be on a flat-ish VLAN?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-