[ndnSIM] behavior of consumer and provider
yao hu
huyao0107 at gmail.com
Thu Apr 25 20:31:41 PDT 2013
Hi Alex,
Thanks for your explanation. But I am still curious about why producer node
needs to forward interest to NetDevice. Take the following simple topology
for example.
(NetDeviceFace) (NetDeviceFace)
+--------+ /x +--------------+ /x +---------------+
| client | ---------- | producerNode | --------------- | someOtherNode |
+--------+ +--------------+ +---------------+
| /x (AppFace)
|
|
+-------------+
| producerApp |
+-------------+
If the producerNode received the interest (under the prefix /x), it will
send the interest to AppFace (the interest will be satisfied). That is very
reasonable. However, does it need to forward the interest to someOtherNode
through NetDeviceFace. As you said, applications not always can satisfy all
interest under specific prefix, but from my observance to the prior
experiments (I made some change in CustomStrategy::DoPropagateInterest),
producerNode can satisfy each node under /x and send Data packet back to
client. Besides, it still have a chance (not every time, just in a small
possibility) to forward the interest to someOtherNode. Is my observance
wrong? Or what is the cause for the producerNode to forward interest (that
will be satisfied to AppFace) to someOtherNode?
Thanks very much~
Regards,
huyao
2013/4/26 Alex Afanasyev <alexander.afanasyev at ucla.edu>
> Hi huyao,
>
> Got it. Yes, ID has exactly the same meaning for any face type, regardless
> of its type. ndn::L3Protocol knows only about Face abstraction and doesn't
> care (should it care?) what type of face it. In the forwarding strategy,
> you can try to distinguish and prioritize application faces, but it should
> not be the only option to forward an interest, since applications not
> always can satisfy all interest under specific prefix.
>
> And another yes, when some interest can be satisfied from the cache, this
> interest doesn't go beyond ndn::l3Protcol and forwarding strategy, never
> having any exchange involving application and application face.
>
> ---
> Alex
>
>
> On Apr 25, 2013, at 9:13 AM, yao hu <huyao0107 at gmail.com> wrote:
>
> Hi Alex,
>
> Thanks for your explanation.
>
> (1) Saying "AppFace and NetDeviceFace share FaceId", I meant that if I
> want to write my own forwarding strategy in CustomStrategy::DoPropagateInterest,
> should I consider AppFace as one usual FaceId like NetDeviceFace?
> Especially, for a producer node, do I need to intentionally control the
> incoming interest not to forward towards some other node and meanwhile make
> it towards AppFace to be satisfied? That seems a little strange though.
>
> (2) Just for a confirmation. Intermediate nodes satisfy interest directly
> through cache (if possible), not through AppFace? While for producer node,
> it satisfies interest through AppFace?
>
> Regards,
> huyao
>
>
>
> 2013/4/25 Alex Afanasyev <alexander.afanasyev at ucla.edu>
>
>> Hi huyao,
>>
>> What do you mean by "AppFace and NetDeviceFace share FaceId"? Each face
>> on the node has its own unique id, doesn't matter, NetDeviceFace of
>> AppFace...
>>
>> Your observation about the current situation with face IDs is exactly
>> right: application faces have IDs that are numerically larger than any
>> other NetDevice face id. However, this happened completely by "accident"
>> and you should not really rely on it in the forwarding strategy. If you
>> want to determine if a specific Ptr<Face> is actually an application face,
>> a much safer way is to do a DynamicCast or (better, but I'm not sure yet
>> how it can be implemented) mark application faces somehow in FIB entries:
>>
>> Ptr<Face> someFace = ...;
>>
>> if (DynamicCast<AppFace> (someFace))
>> {
>> // someFace is application face
>> }
>> else
>> {
>> // someFace is some other type of face
>> }
>>
>> ---
>> Alex
>>
>> On Apr 24, 2013, at 5:24 PM, yao hu <huyao0107 at gmail.com> wrote:
>>
>> Hi Alex,
>>
>> Thanks very much for your explicit explanation.
>> Then, for my understanding, it depends on me to decide whether the
>> satisfied interest will be forwarded again towards other nodes (someOtherNode
>> in your example) or not. If I send it to both AppFace and NetDeviceFace
>> which share FaceId, it will do this. And also, from my simple observance
>> from L3RateTracer, if one node connects to two other nodes, face 0 and face
>> 1 is the NetDeviceFace, while face 2 will be the AppFace. Is my
>> understanding right?
>>
>> Regards,
>> huyao
>>
>>
>>
>> 2013/4/25 Alex Afanasyev <alexander.afanasyev at ucla.edu>
>>
>>> Hi!
>>>
>>> 1) Yes. There is something like PIT in consumer, but in much more
>>> simplistic format. In consumer it is just a container, containing
>>> outstanding sequence number and last retransmission time (m_seqTimeouts
>>> variable in apps/ndn-consumer.h). The code uses boost::multi_index
>>> container to have separate indices by sequence number (to efficiently
>>> remove) and retransmission time (for retransmission detection).
>>>
>>> 2) Let me show you my understanding of your question with slightly
>>> different topology
>>>
>>> (NetDeviceFace) (NetDeviceFace)
>>> +--------+ /x +--------------+ /x +---------------+
>>> | client | ---------- | producerNode | --------------- | someOtherNode |
>>> +--------+ +--------------+ +---------------+
>>> | /x (AppFace)
>>> |
>>> |
>>> +-------------+
>>> | producerApp |
>>> +-------------+
>>>
>>> Let's say we have three nodes, one is client, one producer, and one is
>>> producerNode. Prefix /x (under which client will be sending interests) is
>>> routed:
>>> - on client: the only NetDeviceFace (towards producerNode)
>>> - on producerNode: to AppFace (to producer app), to NetDeviceFace
>>> (towards someOtherNode)
>>>
>>> When producerNode receives an interests from the client, the strategy
>>> may send interest towards application (and this interest will be satisfied)
>>> and towards some other node.
>>>
>>> Among the existing strategies, only ns3::ndn::fw::Flooding is doing
>>> this, since it is very simple and dumb strategy. BestRoute and
>>> SmartFlooding forward interest only to a "green" face (if available), which
>>> implies that they will forward only to the application (ndn::Producer marks
>>> the application face "green").
>>>
>>> ---
>>> Alex
>>>
>>> On Apr 24, 2013, at 8:17 AM, yao hu <huyao0107 at gmail.com> wrote:
>>>
>>> > Hi Alex,
>>> >
>>> > I have two uncertain issues about the behavior of consumer and
>>> provider for confirmation.
>>> >
>>> > (1) Is there any record like PIT for consumer or requester to memorize
>>> past Interest transmission? Possibly for its future retransmission.
>>> >
>>> > (2) Say in a tree topology. If the root as the provider has satisfied
>>> the incoming Interest to send back its according Data. Is it possible to
>>> again forward the Interest to other branches (except the branch for the
>>> incoming Interest)? I am asking this because in my forwarding strategy, I
>>> saw some traffic in other branches, however I just modified
>>> DoPropagateInterest, no other basic ndn functions.
>>> >
>>> > Your reply will be really appreciated.
>>> >
>>> > Regards,
>>> > huyao
>>> >
>>> > _______________________________________________
>>> > ndnSIM mailing list
>>> > ndnSIM at lists.cs.ucla.edu
>>> > http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim
>>>
>>>
>> _______________________________________________
>> ndnSIM mailing list
>> ndnSIM at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim
>>
>>
>>
> _______________________________________________
> ndnSIM mailing list
> ndnSIM at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20130426/a9c2c32a/attachment.html>
More information about the ndnSIM
mailing list