[ndnSIM] behavior of consumer and provider

[yao hu]

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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20130426/e00a5fa9/attachment.html>