Re: [core] [ipwave] Adaptive RESTful Real-time Live Streaming for Things (A-REaLiST)'

Alexandre Petrescu <alexandre.petrescu@gmail.com> Fri, 15 February 2019 12:53 UTC

Return-Path: <alexandre.petrescu@gmail.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 E2CD6130E73; Fri, 15 Feb 2019 04:53:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level:
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] 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 lKnUBr8-Cq7a; Fri, 15 Feb 2019 04:53:39 -0800 (PST)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4128F1275F3; Fri, 15 Feb 2019 04:53:39 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x1FCratv066722; Fri, 15 Feb 2019 13:53:36 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 546FD206112; Fri, 15 Feb 2019 13:53:36 +0100 (CET)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3F41C2017FE; Fri, 15 Feb 2019 13:53:36 +0100 (CET)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x1FCrae6032630; Fri, 15 Feb 2019 13:53:36 +0100
To: Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.com>
Cc: Carsten Bormann <cabo@tzi.org>, "core@ietf.org" <core@ietf.org>, its@ietf.org, its <its-bounces@ietf.org>
References: <F77679C6-F723-4494-AF98-879716A33109@tzi.org> <08d7924f-55c5-f89a-c2f6-cccb3fa4d071@gmail.com> <OF3CBB4EB2.92610A3E-ON6525838C.0016A8F0-6525838C.0016B40C@tcs.com> <OFF2B85497.9C80F088-ON65258392.0070751E-65258392.0078F3DE@tcs.com> <3c66d20e-2db2-7e15-6080-ce3646f848f6@gmail.com> <OF8BDBB757.735694C3-ON65258397.006524D8-65258397.00686F21@tcs.com> <603fbed4-0a32-456e-7883-28dbbc9f8ca4@gmail.com> <OF48461931.293710BC-ON652583A1.0022701A-652583A1.0023A240@tcs.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <c87475ca-58be-a2dd-b8fd-e536838a5adb@gmail.com>
Date: Fri, 15 Feb 2019 13:53:36 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <OF48461931.293710BC-ON652583A1.0022701A-652583A1.0023A240@tcs.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/z9dYeKTXkWeY97dgjSmW70Xk0zI>
Subject: Re: [core] [ipwave] Adaptive RESTful Real-time Live Streaming for Things (A-REaLiST)'
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: Fri, 15 Feb 2019 12:53:43 -0000

Abhijan,

Thank you for the message.

Le 14/02/2019 à 07:29, Abhijan Bhattacharyya a écrit :
[...]
> We made a PoC of the concept and the experimentation and outcomes are
>  presented in Pages 78-80 of 
> https://datatracker.ietf.org/meeting/103/materials/slides-103-core-consolidated-slides-07.pdf


Thank you for the report.

It shows photo of testbed with laptops and raspberry Pis, and a
theoretical sketch of drone-to-access-point topology; it illustrates
that video streaming with A-REaLiST has better performance numbers (F,
PSNR, latency) than HTTP Streaming.  I trust it and it is good for video.

> But we used IPv4 pipe. While it is worth to do an experiment on how
> IPv6 improves the performance (it can only improve I believe).

It is good you used IPv4 pipe initially.

The IPv6 (instead of IPv4) recommendation is not for providing better
performance numbers (F, PSNR, latency) by using IPv6 instead of IPv4.
But it is for scaling up the laptop demonstrator to numerous drones and
access points outdoors where drones can fly, all while being connected
to the Internet.

Using IPv4 one may never be able to connect the drone-and-AP setting in
the outdoors, because there is no cellular  operator that gives enough
IP addresses for a scaleable setting.  In certain countries it is next
to impossible, whereas in others it is still possible but just for a 
little time.

IPv4 and NAT may be a solution, but that begs the question whether the
drone-and-AP setting using A-REaLiST protocol can work across NAT.  I
can understand that A-REaLiST needs to initiate in just one direction 
(so it is compatible with NAT): video initiated from drone to operator; 
but outdoors the operator must also initiate control to the drone, tell 
it where exactly to point the camera - s/he will require you the other 
direction to work too (send initial TCP/IP from control station to 
drone), and that is probably little compatible with NAT.

For these reasons, that have little to do directly with video latency, 
one must consider seriously IPv6 for A-REaLiST.

> But otherwise there should not be much of an impact higher up by a
> change in the network layer because CoAP is designed with 6LowPAN
> pipe in consideration as already emphasised by Carsten.

I am not sure 6LowPAN pipe is relevant for IPv6-over-OCB.  I would say 
it is not relevant at all.  But it is just a 'would'.

Yes, the 6LowPAN technology is some times used on 802.15.4 links.  The 
IPv6 technology without 6lowpan is some other times used on 802.15.4 
links too.

> May be we can discuss at length if we get an opportunity to present
> this in a physical meeting.

How is CoAP specified with respect to IPv6?  MUST it use IPv6?  Is it 
silent about the 'IPv6' keyword?

How is CoAP specified with respect to directionality?  Is CoAP 
compatible or incompatible with traversing NAT?

How is CoAP specified with respect to end-to-end principles?  MUST CoAP 
use intermediary gateways?

Alex


> 
> 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:- +91 33 66884691 
> Cell:- +919830468972 | +918583875003 Mailto:
> abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com
> <http://www.tcs.com/> ____________________________________________ 
> Experience certainty.        IT Services Business Solutions 
> Consulting ____________________________________________
> 
> 
> "its" <its-bounces@ietf.org> wrote on 02/08/2019 09:07:10 PM:
> 
>> From: "Alexandre Petrescu" <alexandre.petrescu@gmail.com> To:
>> "Abhijan Bhattacharyya" <abhijan.bhattacharyya@tcs.com>om>, "Carsten
>> Bormann" <cabo@tzi.org> Cc: "core@ietf.org" <core@ietf.org>rg>,
>> its@ietf.org Date: 02/08/2019 09:08 PM Subject: Re: [ipwave]
>> Adaptive RESTful Real-time Live Streaming for Things (A-REaLiST)' 
>> Sent by: "its" <its-bounces@ietf.org>
>> 
>> "External email. Open with Caution"
>> 
>> 
>> Le 04/02/2019 à 20:00, Abhijan Bhattacharyya a écrit :
>>> Thank you Carsten for your comments. No one can speak about CoAP
>>> 
> better
>>> than you!
>>> 
>>> Alex, I have uploaded a new version of the draft. The links are
>>> given at the end of this mail. I have indeed tried to address
>>> your concern in
> respect
>>> to making the draft more "IPv6-relevant".
>>> 
>>> As Carsten rightly pointed out that the proposal works at the 
>>> application layer and is built on the foundation of CoAP, so it
>>> is Layer-3 agnostic. Also, as we all know, CoAP is designed for
>>> IPv6. However, implementation on IPv6 may influence the process
>>> of
> determining
>>> the maximum size of information segments. So, a new subsection
>>> has
> been
>>> added as part of the design guidelines. The small addition reads
>>> as
> below:
>>> 
>>> <Quote>
>>> 
>>> 6.3. Determining the segment size
>>> 
>>> Size of the information segment in a CoAP message should be
>> limited by the least
>>> possible MTU for the end-to-end channel. This is to ensure
>> that there is no
>>> undesired conversation state at the lower layers of the
>> protocol stack due to
>>> uncontrolled fragmentation leading to undesired explosion of
>> traffic in the
>>> network. For IPV6 network, the MTU can be determined using
>> Path MTU Discovery
>>> (PMTUD) [RFC8201] which bestows the responsibility of
>> determining the path MTU on
>>> the end-points itself.
>>> 
>>> The size of the segment should be guided by the
>> recommendations as specified in
>>> Section 4.6 of [RFC7252].
>>> 
>>> </Quote>
>>> 
>>> I hope this will now satisfy the criterion of finding IPv6 in the
>>> 
> draft.
>> 
>> Thank you very much for this valuable action.
>> 
>> It is very worth taking into consideration.
>> 
>> From an implementation standpoint, I would like to learn whether
>> some prototype features RESTful Real-time Live Streaming on IPv6,
>> or not
> on IPv6.
>> 
>> Alex
>> 
>>> 
>>> Looping in CoRE list as well to announce the new version to the
>>> WG
> where
>>> this draft originates.
>>> 
>>> Thank you.
>>> 
>>> URL: 
>>> https://www.ietf.org/internet-drafts/draft-bhattacharyya-core-a-
>> realist-01.txt
>>> Status:
> https://datatracker.ietf.org/doc/draft-bhattacharyya-core-a-realist/
>>> Htmlized:
> https://tools.ietf.org/html/draft-bhattacharyya-core-a-realist-01
>>> Htmlized:
>>> 
> https://datatracker.ietf.org/doc/html/draft-bhattacharyya-core-a-realist
>
> 
>> Diff:
>>> https://www.ietf.org/rfcdiff?url2=draft-bhattacharyya-core-a-realist-01
>
>>> 
>> 
>>> 
>>> 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:- +91 33
>>> 66884691 Cell:- +919830468972 | +918583875003 Mailto:
>>> abhijan.bhattacharyya@tcs.com
> <mailto:abhijan.bhattacharyya@tcs.com>
>>> Website: http://www.tcs.com <http://www.tcs.com/> 
>>> ____________________________________________ Experience
>>> certainty. IT Services Business Solutions Consulting 
>>> ____________________________________________
>>> 
>>> 
>>> -----"its" <its-bounces@ietf.org <mailto:its-bounces@ietf.org>>
> wrote: -----
>>> To: "Alexandre Petrescu" <alexandre.petrescu@gmail.com 
>>> <mailto:alexandre.petrescu@gmail.com>> From: "Carsten Bormann" 
>>> Sent by: "its" Date: 01/31/2019 06:12PM Cc: "Abhijan
>>> Bhattacharyya" <abhijan.bhattacharyya@tcs.com 
>>> <mailto:abhijan.bhattacharyya@tcs.com>>, "Michael Richardson" 
>>> <mcr@sandelman.ca <mailto:mcr@sandelman.ca>>, its@ietf.org 
>>> <mailto:its@ietf.org> Subject: Re: [ipwave] Adaptive RESTful
>>> Real-time Live Streaming for Things (A-REaLiST)'
>>> 
>>> "External email. Open with Caution"
>>> 
>>>> If TCP's state machine was a bottleneck, has one tried to use
>>>> UDP instead?
>>> 
>>> I think that is indeed one of the advantages CoAP brings go the
> table here.
>>> 
>>>> Does CoAP work on Ethernet?
>>> 
>>> CoAP was designed to be able to run on UDP, which is on IP which
>>> in
> turn
>>> works very well on Ethernet.
>>> 
>>>> Does CoAP work in an end-to-end manner or does it need
>>>> protocol conversion gateways?
>>> 
>>> I works end-to-end (as long as your network doesn’t break UDP).
>>> 
>>>> I want to ask you: please use IPv6 for CoAP and RESTful.
>>> 
>>> CoAP was designed to work well over IPv6 (but works as well over
>>> IPv4).
>>> 
>>>> Then I searched for the keyword ‘IPv6' in the draft. […] If you
>>>> add ‘IPv6' considerations to it, then I will comment on it.
>>> 
>>> For a CoAP application such as A-REaLiST, IPv6 makes little
>>> difference (beyond being able to assign addresses to both ends in
>>> the first
> place),
>>> so I don’t know there is a lot to say.
>>> 
>>> Grüße, Carsten
>>> 
>>> _______________________________________________ its mailing list 
>>> its@ietf.org <mailto:its@ietf.org> 
>>> https://www.ietf.org/mailman/listinfo/its
>>> 
>>> =====-----=====-----===== 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
>>> 
>> 
>> _______________________________________________ its mailing list 
>> its@ietf.org https://www.ietf.org/mailman/listinfo/its
>>