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

[Abhijan Bhattacharyya <[e-mail]>]

Hi Christian,
It is a pleasure to get your valuable comments. Probably the subject 
matter needs to be discussed in the broader context of real-time 
time-series streaming for IoT. Your inputs are important in this regard.

Let us share some ready thoughts in response to some of your comments. We 
can definitely discuss further. 

> * 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?

Yes, the possibility cannot be ignored. However, since I-frames are 
essentially JPEG encoded spatially compressed frames so similar techniques 
used in the MJPEG streaming example can be used. So one can sub-classify 
critical and non-critical information within I-frames and switch the 
semantics accordingly. Anyway, one thing that we need to bear in mind is 
that the I-frames are sparse and separated by the scale of the GoP. P / B 
frames are usually very small in size. So one gets some time to transfer 
the I-frames and then may be serialize the P and B frames in subsequent 
best-effort delivery. Depends on design experiences. May be we can put 
some text regarding this in future versions. 

Having said that, I admit one of your later points where you have 
mentioned about some of the possible optimizations in block wise transfer. 
 These things can be discussed in a broader spectrum. At present we did 
not attempt to disrupt the Block-wise transfer mechanism as it has been 
created with a specific use case of reliable large data delivery. We need 
to define what should be the behaviour if a block option is used with 
No-Response (if at all).

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

What you propose is definitely a sensible approach. 
But we tried to follow the approach in existing streaming standards and 
put the specific header options to help the consuming end relate the 
components of a series-transfer. One thing to note is that in this case 
the header over-head due to stream control information has a deterministic 
limit. Parsing is also straight forward with minimal processing overhead. 
Stream-state in the header helps quick understanding on agreement/ 
disagreement from the other party. In case we put the details in a URI 
query string then that impacts the effective length of the header and we 
need special mechanism to compress the URI. We wanted to avoid these 
complexities. The philosophy is to minimise control level processing to 
cater the hard real time requirements for live feed in AR control 
applications like automated VSLAM (Visual Simultaneous Localization and 
Mapping) for dumb robot terminals and UAVs. So the terminal is not 
manually remote controlled. 

We assume that the time-stamp is presented in epoch time. 

Another point is that we chose to provide autonomy to the producer to 
propose the stream-ID through header option. We consider the typical case 
where a remote (UAV) terminal is depleted of energy and replaced by 
another terminal, which streams as soon as commissioned, using the same 
stream ID (keeping an option for pre-provisioning). It becomes seamless 
for the consumer.

> * 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 ;-) )
>  

RTP is something that will automatically come as a first thought. However, 
according to our experience, commercial IP based streaming implementations 
are using custom protocols on TCP. These protocols are quite in line with 
the usual current practice for RESTful streaming over public Internet 
which uses HTTP-streaming with ABR. So, we tried to create an efficient 
streaming counterpart of HTTP-streaming for IoT. ABR can be an added 
feature to what we proposed in the draft. In future AR the producer may 
not only stream multimedia but can send mulSEmedia (multi SEnsory media) 
with video as a sensory input. So we wanted to have a RESTful protocol 
which is equally efficient in transferring sensor data as well as large 
streams. Also, as we have mentioned in draft, CoAP allows us to create the 
intelligent switch to balance between real-time and reliable delivery 
while optimizing the resource usage and allowing flexibility to react to 
the connection environment. 

Having said that, we have done bench marking experiments to compare with 
RTP. We are not doing bad actually (however, definitely you need to change 
the default time-out limits, etc. for the real-time). 

We can present the approach and use cases in more detail with descriptions 
of the experiments and the bench marking results for further discussion in 
a physical meeting. 

Thank you.
With Best Regards
Abhijan Bhattacharyya
Consultant / Scientist,
{Internet Protocols | 5G | Standardization}, 
TCS Research,
Tata Consultancy Services
Building 1B,Ecospace
Plot -  IIF/12 ,New Town, Rajarhat,
Kolkata - 700160,West Bengal
India
Ph:- [phone]
Cell:- [phone] | [phone]
Mailto: [e-mail]
Website: http://www.tcs.com
____________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Consulting
____________________________________________


"Christian Amsüss" <[e-mail]> wrote on 10/09/2018 12:55:35 
PM:

> From: "Christian Amsüss" <[e-mail]>
> To: "Abhijan Bhattacharyya" <[e-mail]>
> Cc: [e-mail], "Hemant Rath" <[e-mail]>
> Date: 10/09/2018 12:55 PM
> Subject: Re: [core] Fw: New Version Notification for draft-
> bhattacharyya-core-a-realist-00.txt
> 
> 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
> [attachment "signature.asc" deleted by Abhijan Bhattacharyya/KOL/TCS] 
> "External email. Open with Caution"
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you