Early Review of draft-bichot-msync-08
review-bichot-msync-08-artart-early-amsuess-2023-03-01-00

General summary
===============

My impression of this protocol is that while it has several aspects that need
work, it's on a good track towards a solution to the media multicast problems
it addresses.

However, this also (possibly inadvertently) describes a useful contribution to
the HTTP ecosystem, as the protocol seems to be suitable for distribution of
other data already. (For example, it could be used to distribute software
updates). I think that splitting the document conceptually into how to stream
(in the first place, arbitrary) sets or ranges of resources through multicast,
and a second part that deals with peculiarities of media streams (such as 3.8.2
that the manifest should be sent wherever the data is sent). Mechanisms like
this have been discussed around draft-ietf-core-observe-multicast-notifications
in the context of constrained devices, which has informally been applied also
for firmware updates.

Questions and comments
======================

* Given this is built on HTTP's architecture, there may be some benefits to
  reap in terms of simplification by building on it:

  * In section 2 there is a lot of description on how the multicast server
    obtains the data through the HAS from the origin server, and how the
    multicast receiver is a gateway that relays the received data through the
    HAS again. This makes sense to set the stage and paint the expected usage
    scenario, but for normative text (and even later parts of section 2) the
    protocol is essentially between a server and a client, no matter whether
    either of them serves as a proxy.

  * As noted in the general summary, most of this is independent of whether
    media or other resources are transported. This should also be reflected in
    the structure. For example, the semantics of the Object URI field need not
    be part of the HAS protocol dependent section. For other components it's
    less clear how they are used, but chances are there are corresponding
    concepts in HTTP already.

* 3.1 "MSYNC Packet Format", "Whenever this object ID change that means the
  transfer of the previous object is finished". Packets can be reordered in
  transit. Will this make later packets unusable to the receiver?

  Also later in 3.7 "the MSYNC sender MUST send the following MSYNC packets in
  the specified order": Reception in that order is generally not guaranteed, so
  why make this a requirement?

  If recipients need to reorder packets, it may make sense to prescribe some
  form of object identifier incrementing (eg. that they always increase by 1).
  This would make it easier for the recipient to distinguish stray packets
  received from previously processed objects (which could be discarded) from
  the first data packet that was received ahead of the corresponding info
  packets (which better be stored).

* 3.2 "object URI size" / "object URI": This appears to be redundant and
  needlessly complex, given that UDP already gives the packet length. If for
  alignment reasons the size needs to be a multiple of 4, that property could
  also be obtained by nul-padding (without indicating the padding length)
  because 0x00 is not a legal character in a URI -- but I think that'd need
  good justification.

* 3.4 "Object HTTP Header Packet": After reading the whole document I found
  myself wondering which kind of headers would be transported here.

* 3.5 "super object offset": I'd like to see alternatives to the object /
  super-object split explored -- if it's just about length not being known in
  advance, the separation might be overkill. Comparing to Content-Range might
  help here.

* 3.7 "then only one object info packet MUST be sent.": Is not doing this an
  interoperability hazard? If not, why the MUST? (And on the "curious
  questions" level, why is it forbidden?)

* 3.8.1.1 I'm not familiar with the precise HLS and DASH concepts used, but if
  this is all only about resources whose content changes over time, it may make
  sense to utilize ETag instead of a media-specific concept. This could replace
  the media sequence item in the object info packet. (If not, some more detail
  could help generalize this).

* 3.8.1.2 "Object URI": Comparing URIs as substrings is a highly irregular
  operation.  Appeding a hash characterh ("#") already has a defined meaning in
  URI references (setting the fragment identifier, or extending it if one was
  present before), which is not aligned with how numbers are appended here.

  I'd make a more concrete suggestion on how to improve this, but that'd
  require full understanding of how it is supposed to work, and given that CTE
  is not expanded (and HTTP does not use Content-Transfer-Encoding as which I'd
  read it), the intended operation is unclear.

Specification clarity
=====================

* 3.1 "sub-header" (and other >8-bit numbers): While frequent readers of IETF
  documents will be aware that this is intended to be encoded in Network Byte
  Order (also called big-endian), some readers might appreciate this being
  explicit.

* 3.2 "object CRC": Which polynomial?

* 3.2 "object type", "mtype": It is unclear to me why these need to be
  indicated, given that their URIs are known for entry points. Both appear to
  be overlapping with media types, which could replace both fields.

* 3.2 "media sequence": "The default value is 0x00". Given the field is not
  optional, I think this would better be phrased along the lines of "If this
  field is unused, it MUST be set to 0x00, and receivers MUST ignore it."

* 3.4 "Object HTTP Header Packet" serializes HTTP headers. Given there are now
  multiple versions of the HTTP protocol with different expressions for how
  headers are encoded, please consider referencing into a concrete document for
  the format.

* 3.4 "Object HTTP Header Packet" vs. 3.5 "super object offset": Does the use
  of super objects imply that the Content-Range header will not be used?
  Otherwise, how do they interact?

  Depending on earlier items, the Content-Format header may have some overlap
  with the mtype.

  It may be prudent to define which takes precedence, or (as I'd prefer) that
  the headers that are redundant with info packet fields are forbidden in
  header packets.

* 3.4 "Object HTTP Header Packet": It pains me to say it, but it may make sense
  to check with HTTP experts on whether 64KiB is a reasonable limit for HTTP
  headers.

Versioning
==========

* 3.1 "version": What's the evolution plan for this protocol? How are
  recipients supposed to react to packets with a different protocol version?

* 3.1 "packet type": This appers to be the main extension point for the
  protocol. How are recipients supposed to react to packets with unknown packet
  types? What is the procedure for adding packet types? If it's not "publish an
  RFC that updates this document", this would need a registry.

  Same goes for mtype (but see also main comment on mtype).

Curious questions
=================

* Why is the Object Info Packet sent with distinct packet types, instead of
  just being transmitted twice?

* 3.7: "source IP address, destination multicast IP address and destination
  transport port number is the discriminator". Why was the source IP included
  but the source port not? If fail-over was considered, allowing variation in
  the source IP would appear to be a good choice, whereas allowing variation in
  the source port contributes only marginally there (and off my head I would
  see no other reason).

Editorial notes
===============

* 1. Introduction: Please expand ABR

* 1.2 Terminology: Please expand CTE (presumably to Content-Transfer-Encoding?)

* 1.2 Definitions: I think this would be better readable if it were in
  a bottom-up sequence. Someone new to the topic (like me) needs to jump
  forward a lot, and the current alphabetical sorting is not that relevant any
  more when there is full-text search in all relevant media.

* 1.2 "HTTP Adaptive Streaming (HAS) session": Maybe substitute "init" with
  "init segments" for better flow. (Although flow would also be helped by
  having read "init segment" earlier).

* 1.2 "media": How the term is used in "media chunk", "media segment" etc seems
  to imply that as used here there is always a temporal component to it.

* 3.4 "Object HTTP Header Packet" talks of "one HTTP header". In RFC7230 there
  are many "header fiels" joint in a "header section" (also called "the
  headers"), but never "a header".

* various typo: "mechanism.; this"; "teh"
* capitalization: "streaming, The"; "if the object"

Scope notes
===========

* I am only very vaguely familiar with RTP, thus my reading of section 3.9 was
  very superficial.