Re: [core] Fw: New Version Notification for draft-bhattacharyya-core-a-realist-00.txt

[Christian Amsüss <[e-mail]>]

Hello Abhijan,

On Sun, Oct 07, 2018 at 12:53:24AM +0530, Abhijan Bhattacharyya wrote:
> A new draft [...]  of real-time streaming

I've had a brief look at this draft, and have some questions and
comments:

* I assume that an I-Frame is still larger than an MTU, thus transported
  in the stream it would still occupy multiple exchanges. Given that you
  stick with NSTART=1 ("MUST wait to send any further segment"), won't
  the round-trip times for the (how-many?) CON exchanges bring
  throughput to a halt at every I-Frame?

* The stream states look like something that should not be managed in an
  option but can be managed at REST level by using established
  mechanisms: "Create an entity (stream) and give a handle that we can
  use to talk about it" is commonly expressed by POSTing somewhere
  and receiving a URI for that stream as a Location.

  I'll try to re-phrase the exchange on p9 in such terms:

   Client (Producer)                                  Server (Consumer)
   |                                                  |
   | POST: CON;                                       |
   |       URI=/video;                                |
   |       Payload= CBOR or JSON                      |\
   +------------------------------------------------->| |
   |                                                  | |Stream
   | ACK;                                             | |negotiation
   | Response = 2.04 CHANGED                          | |
   | Location: /five-bit-id                           | |
   |<-------------------------------------------------|/
   :                                                  :
   :                                                  :
   |(First segment of an MJPEG frame. Contains        |
   | meta-data. Critical segment needs reliable       |
   | delivery.)                                       |
   |                                                  |
   | PUT: CON;                                        |
   |       URI=/five-bit-id?t=123&pos=0               |
   |       Payload= <Bytes_in_1st segment>            |\
   +------------------------------------------------->| |
   |                                                  | |
   | ACK;                                             | |
   | Response = 2.04 CHANGED                          | |
   |<-------------------------------------------------| |
   |(Second segment of an MJPEG frame. Contains       | |
   | non-meta-data. Non-critical segment- best effort | |
   | transfer.)                                       | |
   |                                                  | | Stream
   | PUT: NON;                                        | | ongoing
   |       URI=/five-bit-id?t=123&pos=1024;           | |
   |       No-response = 127                          | |
   |       Payload= <Bytes_in 2nd _segment>           | |
   +------------------------------------------------->| |
   |                                                  | |
   :                                                  : |

   The re-negotiation information could then go into unsuccessful
   messages (eg. 4.xx Too Many Requests, with a payload indicating to
   increase compression).

   This example moves the stream ID into the URI path and both timestamp
   and position into the URI-Query. I've expressed both timestamp and
   position in decimal format, but that shouldn't be a show stopper; if
   it causes trouble, we'll come up with something (eg. a way of having
   a compressed URI query that's transmitted as int but means a
   decimal-encoded URI-Query component).

   If the offsets and lengths of the messages within a time slice are
   always block-sized, it would be well possible to use blockwise
   transfer for the individual time frames. AFAICT it should be within
   the specification to have some blocks CON transferred, some NON even
   with no-response. As processing of the time frames is not atomic, the
   application could work with blocks that are missing. That'd also give
   us access to other established mechanisms, like sending a Size1
   option with the pos=0 package of a timestamp to indicate how many
   butes there will be for this timestamp.

* In general, video streaming has been my classical example of things
  you would not want to do over CoAP, so please forgive my skepticism.
  I'd be happy to be shown to be wrong, but that might need statistical
  comparison to RTP streaming, and practical demonstration (though I
  only might be saying this because I want to try remote piloting a UAV
  over CoAP myself ;-) )

Best regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom