[Nfd-dev] 1-to-Many NDN-RTC test and hub strategy

Mon Jun 27 11:39:52 PDT 2016

Hi Junxiao,

Thanks for your input. I think I might know what the problem is. It’s in NDN-RTC library, as nonce values are being set by NDN-RTC currently.
Jeff Thompson introduced refreshNonce() which uses crypto library for nonce generation. Once I update NDN-RTC to the latest NDN-CPP, this should provide better results.
In any way, currently, NDN-RTC needs to know expressed Interests nonce values to track incoming data.

Thanks,

--
Peter Gusev

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748
peetonn_ (skype)

Software Engineer/Programmer Analyst @ REMAP UCLA

Video streaming/ICN networks/Creative Development

On Jun 26, 2016, at 5:07 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Peter

The trace is attached to https://redmine.named-data.net/issues/3642#note-12 for permanent record.
I can see a lot of Nack-Duplicates from the trace:
vagrant at m0212:~$ ndndump -r capture.pcap | grep -v 10.10.12.3 | sed -e 's/From: 10.10.12.//<http://10.10.12.//>' -e 's/, To: 10.10.12./-<http://10.10.12./->>/' -e 's/, Tunnel Type: UDP, / /' -e 's|/ndn/edu/ucla/remap/ndnrtc/user/client1/streams/camera/low/key|()|' | grep 'Nonce=1732610923'
1466801763.692043 4->2 INTEREST: ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.706693 7->2 INTEREST: ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.706810 2->7 NACK: Duplicate, ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.732589 6->2 INTEREST: ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.732702 2->6 NACK: Duplicate, ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.822424 12->2 INTEREST: ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.822546 2->12 NACK: Duplicate, ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.825780 9->2 INTEREST: ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.825867 2->9 NACK: Duplicate, ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.838540 10->2 INTEREST: ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.838657 2->10 NACK: Duplicate, ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.854087 5->2 INTEREST: ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.854200 2->5 NACK: Duplicate, ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.934206 11->2 INTEREST: ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.934301 2->11 NACK: Duplicate, ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801764.041182 8->2 INTEREST: ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801764.041306 2->8 NACK: Duplicate, ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801764.154624 13->2 INTEREST: ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801764.154732 2->13 NACK: Duplicate, ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923

Protocol requires Name+Nonce combination to be unique<http://named-data.net/doc/ndn-tlv/interest.html#nonce>, but the same Nonce is being used by consumer 4,7,6,12,9,10,5,11,8,13. As a result, all except consumer 4 will not get Data.
Even if consumer 4 gets Data this time, if other consumers are still generating the same stream of Nonces, the next Interest from consumer 4 may arrive later than the duplicate Interest from other consumers, causing consumer 4 to receive a Nack-Duplicate and therefore lose track of the video stream.

This is either a bug in the library, or you are using the library incorrectly. You may get more help on ndn-lib mailing list.

Yours, Junxiao

On Fri, Jun 24, 2016 at 2:16 PM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:

What I meant is that all consumers start simultaneously and what I repeatedly observe, is that they are unable to catch up with the latest produced data in a synchronous manner, what is expected. Instead, chasing phase resolution happens one (or few) consumer(s) at a time. Consumers are identical and in the beginning express same interest - with rightmost child selector enabled.
Here <http://ec2-52-90-158-238.compute-1.amazonaws.com:3000/dashboard/db/ndn-rtc-test-real-time-metrics?panelId=4&fullscreen&from=1466801762500&to=1466801788564>  (login/pw: guest/ndnguest) you can see “rebufferings stairs” - which indicate that consumer was not able to get any data, so it started over. It feels like NFD was answering one consumer (rightmost interest) at a time.

I attached pcap file for the first 1-1.5 minute of test.

I ran more 1-to-10 tests recently (here are the results<http://ec2-52-90-158-238.compute-1.amazonaws.com:3000/dashboard/db/ndn-rtc-tests-test-run-overview?from=1466566688346&to=1466567022507&var-runtime=15m> of one out five tests) and observe an unusual behavior: consumers are not able to get data all simultaneously, instead - they join one-by-one. This can be seen from rebufferings graph<http://ec2-52-90-158-238.compute-1.amazonaws.com:3000/dashboard/db/ndn-rtc-tests-test-run-overview?from=1466566688346&to=1466567022507&var-runtime=15m&panelId=15&fullscreen> and incoming traffic graph<http://ec2-52-90-158-238.compute-1.amazonaws.com:3000/dashboard/db/ndn-rtc-tests-test-run-overview?from=1466566688346&to=1466567022507&panelId=20&fullscreen&var-runtime=15m>. I see that, consumers get timeouts for the initial interests.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160627/31ff734a/attachment.html>