<div dir="ltr"><div class="gmail_quote">Hi Adhy<br><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Regarding the issue of delaying Interest and Data packets, would it make sense to implement the logic in the Ethernet face? I believe I would have to modify the "EthernetTransport::<wbr>sendPacket" method in the <a href="https://github.com/named-data/NFD/blob/master/daemon/face/ethernet-transport.cpp#L99" target="_blank">ethernet-transport.cpp</a> to get the location from the packet name and delay the forwarding accordingly. Is that correct? (sorry I don't have experience with Ethernet faces)<br></div></blockquote><div><br></div><div>Transport is definitely the wrong place, because Transport should not care about the packet format. It could be NDNLPv2, or something completely differently.<br></div><div>Without understanding the packet format, it is impossible for Transport to extract the packet name.<br><br></div><div>LinkService and forwarding are two candidates for such a feature. The criteria is to determine whether the feature should be a face feature or a forwarding feature.<br></div><div>You mentioned earlier that the purpose of delaying packet transmission is to avoid collisions. If the design operates entirely within a face and does not take inputs from traffic on other interfaces, this should belong to face system and thus be implemented in LinkService.<br><br></div><div>Yours, Junxiao <br></div></div></div>