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

Christian Amsüss <christian@amsuess.com> Tue, 09 October 2018 07:25 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09E51311C0 for <core@ietfa.amsl.com>; Tue, 9 Oct 2018 00:25:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Po_V87EmyMpL for <core@ietfa.amsl.com>; Tue, 9 Oct 2018 00:25:39 -0700 (PDT)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F67A1310C5 for <core@ietf.org>; Tue, 9 Oct 2018 00:25:38 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 1CCE441A90; Tue, 9 Oct 2018 09:25:37 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 2B4402A; Tue, 9 Oct 2018 09:25:36 +0200 (CEST)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id CD8B310E; Tue, 9 Oct 2018 09:25:35 +0200 (CEST)
Received: (nullmailer pid 19861 invoked by uid 1000); Tue, 09 Oct 2018 07:25:35 -0000
Date: Tue, 9 Oct 2018 09:25:35 +0200
From: Christian =?iso-8859-1?Q?Ams=FCss?= <christian@amsuess.com>
To: Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.com>
Cc: core@ietf.org, Hemant Rath <hemant.rath@tcs.com>
Message-ID: <20181009072535.GA31858@hephaistos.amsuess.com>
References: <OF6F7D9482.0418744D-ON6525831E.0068D037-6525831E.006A8351@tcs.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO"
Content-Disposition: inline
In-Reply-To: <OF6F7D9482.0418744D-ON6525831E.0068D037-6525831E.006A8351@tcs.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/2u8Hb_dzbs9aHT3iBUh7-r4yCRk>
Subject: Re: [core] Fw: New Version Notification for draft-bhattacharyya-core-a-realist-00.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Oct 2018 07:25:42 -0000

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