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

[Abhijan Bhattacharyya <[e-mail]>]

Hi Alex,

>Thank you for the report. .....  I trust it and it is good for
>video.

Thank you.

>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. 
> ..............  For these reasons, that have little to do directly with video latency, 
> one must consider seriously IPv6 for A-REaLiST.

All your points are taken. We appreciate them as the fundamental considerations for moving towards IPv6. Even India is now have an enormous IPv6 adoption since the LTE roll-out. A-REaLiST, as mentioned earlier, is IP backbone agnostic.

>I am not sure 6LowPAN pipe is relevant for IPv6-over-OCB.

Well, we never intended to say that we transfer video over 6LowPAN. We referred to 6LowPAN just to highlight the fact that CoAP by design is compatible with IPv6 and works well for sensors deploying 6LowPAN stack.

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

CoAP is an application layer protocol and can work on both IPv4 and IPv6. The specification (RFC 7252) has plenty of mentions about IPv6 (11 times in the body of the specification. 5 more in the reference section). You may please check here (https://tools.ietf.org/html/rfc7252).

Yes it is an end-to-end protocol. The end-points may connect directly (just like what we did during the presented experiments) or you may go through via proxies or gateways. 
Traversing the NAT will be possible if you have the setting done through port-mapping , etc. just like any other system.

May be we can discuss more if we get a chance to meet face to face.

Thank you. Happy to discuss more.


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
____________________________________________


-----"its" <[e-mail]> wrote: -----

>To: Abhijan Bhattacharyya <[e-mail]>
>From: Alexandre Petrescu 
>Sent by: "its" 
>Date: 02/15/2019 06:24PM
>Cc: Carsten Bormann <[e-mail]>, [e-mail], "[e-mail]"
><[e-mail]>, its <[e-mail]>
>Subject: Re: [ipwave] Adaptive RESTful Real-time Live Streaming for
>Things (A-REaLiST)'
>
>"External email. Open with Caution"
>
>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-co
>nsolidated-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:- [phone] 
>> Cell:- [phone] | [phone] Mailto:
>> [e-mail] Website: http://www.tcs.com
>> <http://www.tcs.com/> ____________________________________________ 
>> Experience certainty. IT Services Business Solutions 
>> Consulting ____________________________________________
>> 
>> 
>> "its" <[e-mail]> wrote on 02/08/2019 09:07:10 PM:
>> 
>>> From: "Alexandre Petrescu" <[e-mail]> To:
>>> "Abhijan Bhattacharyya" <[e-mail]>, "Carsten
>>> Bormann" <[e-mail]> Cc: "[e-mail]" <[e-mail]>,
>>> [e-mail] Date: 02/08/2019 09:08 PM Subject: Re: [ipwave]
>>> Adaptive RESTful Real-time Live Streaming for Things (A-REaLiST)' 
>>> Sent by: "its" <[e-mail]>
>>> 
>>> "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-real
>ist
>>
>> 
>>> 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:- [phone] | [phone] Mailto:
>>>> [e-mail]
>> <mailto:[e-mail]>
>>>> Website: http://www.tcs.com <http://www.tcs.com/> 
>>>> ____________________________________________ Experience
>>>> certainty. IT Services Business Solutions Consulting 
>>>> ____________________________________________
>>>> 
>>>> 
>>>> -----"its" <[e-mail] <mailto:[e-mail]>>
>> wrote: -----
>>>> To: "Alexandre Petrescu" <[e-mail] 
>>>> <mailto:[e-mail]>> From: "Carsten Bormann" 
>>>> Sent by: "its" Date: 01/31/2019 06:12PM Cc: "Abhijan
>>>> Bhattacharyya" <[e-mail] 
>>>> <mailto:[e-mail]>>, "Michael Richardson" 
>>>> <[e-mail] <mailto:[e-mail]>>, [e-mail] 
>>>> <mailto:[e-mail]> 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&#8217;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 &#8216;IPv6' in the draft. [&#8230;] If you
>>>>> add &#8216;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&#8217;t know there is a lot to say.
>>>> 
>>>> Grüße, Carsten
>>>> 
>>>> _______________________________________________ its mailing list 
>>>> [e-mail] <mailto:[e-mail]> 
>>>> 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 
>>> [e-mail] https://www.ietf.org/mailman/listinfo/its
>>> 
>
>_______________________________________________
>its mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/its
>