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

Junxiao Shi shijunxiao at email.arizona.edu
Sun Jun 26 17:07:43 PDT 2016


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.//' -e 's/, To: 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> 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/20160626/6fa07438/attachment.html>


More information about the Nfd-dev mailing list