NFD

The objective here is not to get absolutely accurate information about transmitted packets through socket (this can be taken from the interface stats), but rather byte count for Interest/Data that were transferred through Faces. This is almost the same as packet count that we have now, just expressed in number of bytes, rather than packets.

I think, for network operation purpose, it's more useful to have a byte count at link layer, without distinguishing between Interest and Data.

20140704 conference call decides more clarification is needed.

@John DeHart, please clarity which one is desired:

• link layer byte count without distinguishing between Interest and Data
• network layer byte count
  Limitation: with NDNLP-TLV, if a fragment is lost, other fragments are dropped and not counted in, but they still consumed network bandwidth
• link layer byte count, counting Interest and Data separately
  There is implementation difficulty for this one.

Long term it might be nice to have link layer byte counts for interest and data separately.

For the short term link layer byte count without distinguishing between Interest
and Data would be fine. And it is quite possible that this would be enough for
the long term.

What's the rationale for calling these counters "link layer"? And why do you include NDNLP headers but not Ethernet or TCP?

NDN-TLV is at network layer.

NDNLP is a link protocol for NDN, according to its technical report.
The layer for link protocol is called "link layer".

Ethernet or TCP is at a layer lower than NDNLP.
Their overheads are out of scope of this Task.

For the short term link layer byte count without distinguishing between Interest
and Data would be fine. And it is quite possible that this would be enough for
the long term.

On 20151019, John DeHart confirms:

Yes, I think it will be fine to continue for the long term with a combined byte counter.