<div dir="auto"><div>Hi Chavoosh</div><div dir="auto"><br></div><div dir="auto">The answer assumes you are working with forwarding or strategy.<br><div class="gmail_extra" dir="auto"><div class="gmail_quote"><br><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div>What is the best way to measure the response time of Interest packets (i.e. <i>the amount of time from receiving an Interest until it gets satisfied</i>)? </div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">The refresh time on PIT in-record reflects when the Interest arrived at the current node from a specific downstream. Subtract Simulator::Now() by the refresh time tells you the response time. However, if the downstream retransmits, the refresh time would be updated to reflect when the last retransmission arrives. In this case, you can't distinguish whether the Data is satisfying the original Interest or the retransmission.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra" dir="auto"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Pit records do not keep any timestamp (e.g. insertion time), so I doubt whether Pit entries can provide us with enough info to measure the response time for a given Interest.</div></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">PIT in-record or out-record refresh time can be used for this purpose when there's no retransmission, as described above.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra" dir="auto"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>, I think it is not an efficient solution to add a record for each Interest into the Measurement table to measure response time.</div></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">It would be a wrong solution prior to NDN Packet Format 3.0, because multiple Interests with same name but different selectors would use the same measurements entry and thus conflict.</div><div dir="auto"><br></div><div dir="auto">Yours, Junxiao</div></div>