[Nfd-dev] Ethernet unicast faces

Sat Aug 12 16:26:19 PDT 2017

Niels,

The change enabling fragmentation/reassembly by default on Ethernet
faces has been merged. You may want to try again using NFD revision
00a3c9dc8629285d1115f35b65148772fa520d84 (or any later revisions).

Please let us know of any issues you might encounter, the unicast
Ethernet code is fairly new and only lightly tested.

Thanks,
Davide

On Thu, Aug 10, 2017 at 12:02 PM, Davide Pesavento
<davide.pesavento at lip6.fr> wrote:
> Hi Niels,
>
> EthernetChannel doesn't currently enable NDNLPv2 fragmentation/reassembly on
> unicast Ethernet faces. I think that should be changed to behave like the
> multicast faces. I will submit an NFD patch later today.
>
> At the moment, there is no way to toggle fragmentation/reassembly on a
> per-face basis via nfdc, but we don't think this feature is necessary as we
> don't have a use case for it (yet). Please let us know if you have a need
> for it.
>
> I'm not sure what you mean by "On multicast Ethernet faces the packets are
> capped at the MTU". You should be seeing one or more fragments, each of them
> not greater than the interface MTU, coming out of those faces. Can you
> elaborate on the problem you're experiencing please?
>
> Thanks,
> Davide
>
> On Thu, Aug 10, 2017 at 4:30 AM, Adrichem, N.L.M. (Niels) van
> <niels.vanadrichem at tno.nl> wrote:
>>
>> Hello Susmit,
>>
>>
>>
>> Thank you for your answer, the unicast ethernet faces work according to
>> your instructions and examples.
>>
>>
>>
>> In our scenario, there needs to occur fragmentation due to a large Data
>> object size. Currently, we find that Data objects exceeding the link MTU of
>> a unicast are dropped (which is expected without a link adaptation layer
>> such as NDNLPv2). On multicast Ethernet faces the packets are capped at the
>> MTU, which we think may be a minor bug, though it is not of influence to our
>> work yet.
>>
>>
>>
>> We understood that the link adaptation layer NDNLPv2 is able to fragment
>> and reassemble objects exceeding a link’s MTU and retransmit missing
>> fragments on a hop-by-hop basis. However, the current Ethernet faces do not
>> seem to use this encoding. Instead of the expected TLV-type 0x64 for
>> NDNLPv2, we find in Wireshark that the TLV-types 0x05 and 0x06 for Interests
>> and Data objects are directly encapsulated into Ethernet without the NDNLPv2
>> link adaptation layer. Do you, or any of the other readers, have pointers
>> towards configuring NDNLPv2 over Ethernet faces?
>>
>>
>>
>> Best regards,
>>
>> Niels van Adrichem
>>
>>
>>
>> From: susmit.shannigrahi at gmail.com [mailto:susmit.shannigrahi at gmail.com]
>> On Behalf Of Susmit
>> Sent: woensdag 9 augustus 2017 17:27
>> To: Wissingh, B.F. (Bastiaan) <bastiaan.wissingh at tno.nl>
>> Cc: Susmit <susmit at cs.colostate.edu>; Teng Liang
>> <philoliang2011 at gmail.com>; nfd-dev at lists.cs.ucla.edu; Adrichem, N.L.M.
>> (Niels) van <niels.vanadrichem at tno.nl>
>> Subject: Re: [Nfd-dev] Ethernet unicast faces
>>
>>
>>
>> Hi Bastiaan,
>>
>> This link has a few examples:
>> https://redmine.named-data.net/issues/4012#change-19566
>>
>> For your example, could you try to modify your command to this?
>>
>> nfdc face create ether://[00:0c:29:de:37:fb] local dev://ens.38
>>
>> Thanks.
>>
>>
>>
>>
>>
>> On Wed, Aug 9, 2017 at 9:21 AM, Wissingh, B.F. (Bastiaan)
>> <bastiaan.wissingh at tno.nl> wrote:
>>
>> Hi all,
>>
>>
>>
>> As Niels and I are both working on this topic, I’ve been playing around a
>> bit with the master branch version of NFD today (version=0.5.1-115-g79a9208)
>> in order to see if we could get the Unicast-Ethernet faces to work.
>>
>>
>>
>> Even though I found some documentation
>> (https://named-data.net/doc/NFD/current/manpages/nfdc-face.html) on how to
>> create these Unicast Ethernet faces, I can’t seem to get it to work… I’ve
>> been trying all kinds of parameter combinations with nfdc, but without any
>> luck.
>>
>>
>>
>> It seems that it is unable to parse the second command (so the local
>> FaceURI). When I issue for example “nfdc face create
>> ether://[00:0c:29:de:37:fb] dev://ens38” it returns with “cannot parse
>> 'dev://ens38' as an argument name”.
>>
>>
>>
>> Do you have any hints on how to create such Ethernet Unicast face? Also,
>> if a Unicast Ethernet face is created, will this ‘automatically’ enable the
>> usage of NDNLPv2 on that Face?
>>
>>
>>
>> Looking forward to a response,
>>
>>
>>
>> Best regards,
>>
>> Bastiaan Wissingh
>>
>>
>>
>> Van: Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu> namens Susmit
>> <susmit at cs.colostate.edu>
>> Datum: woensdag 2 augustus 2017 18:05
>> Aan: Niels van Adrichem <niels.vanadrichem at tno.nl>
>> CC: "nfd-dev at lists.cs.ucla.edu" <nfd-dev at lists.cs.ucla.edu>, Teng Liang
>> <philoliang2011 at gmail.com>
>> Onderwerp: Re: [Nfd-dev] Ethernet unicast faces
>>
>>
>>
>> Hi Niels,
>>
>> This feature has already been merged, you might want to check-out the
>> master branch to try it out.
>> https://redmine.named-data.net/issues/4011
>>
>> Thanks.
>>
>>
>>
>> On Wed, Aug 2, 2017 at 9:37 AM, Adrichem, N.L.M. (Niels) van
>> <niels.vanadrichem at tno.nl> wrote:
>>
>> Hello everybody,
>>
>>
>>
>> Awaiting unicast-Ethernet encapsulation, we are currently using UDP+IP
>> encapsulation to achieve our functionality. However, we are facing some
>> issues that with IP fragmentation the probability of packet loss increases
>> greatly, while retransmission of missing fragments is absent.  We understand
>> NDNLPv2 will have a retransmission-strategy for missing fragments of a
>> segment larger than the MTU. Will this already be implemented in the unicast
>> interface implementation you are currently working on?
>>
>>
>>
>> Please let us know if we can help evaluate a prototype, we are eager to
>> work with NDN as the only network-layer forwarding protocol.
>>
>>
>>
>> Best regards,
>>
>> Niels van Adrichem
>>
>>
>>
>> From: Alex Afanasyev [mailto:aa at cs.ucla.edu]
>> Sent: maandag 27 maart 2017 15:47
>> To: D'Acunto, L. (Lucia) <lucia.dacunto at tno.nl>
>> Cc: Lixia Zhang <lixia at cs.ucla.edu>; nfd-dev at lists.cs.ucla.edu; Davide
>> Pesavento <davide.pesavento at lip6.fr>; Adrichem, N.L.M. (Niels) van
>> <niels.vanadrichem at tno.nl>; Eric Newberry <enewberry at email.arizona.edu>;
>> Teng Liang <philoliang2011 at gmail.com>
>>
>>
>> Subject: Re: [Nfd-dev] Ethernet unicast faces
>>
>>
>>
>> Davide, Eric, Tang, Junxiao, and I are in charge of this and we will try
>> to finalize the implementation quick.
>>
>>
>>
>> ---
>>
>> Alex
>>
>>
>>
>> On Mar 27, 2017, at 8:20 AM, D'Acunto, L. (Lucia) <lucia.dacunto at tno.nl>
>> wrote:
>>
>>
>>
>> Hi Lixia,
>>
>> This is very good news!
>>
>> It would be great if you could give us the contact details of the person
>> in charge of this project.
>>
>>
>>
>> Thanks, and best regards,
>>
>> Lucia
>>
>>
>>
>> From: Lixia Zhang [mailto:lixia at cs.ucla.edu]
>> Sent: maandag 27 maart 2017 13:41
>> To: Adrichem, N.L.M. (Niels) van
>> Cc: D'Acunto, L. (Lucia); nfd-dev at lists.cs.ucla.edu; Alex Afanasyev;
>> Davide Pesavento
>> Subject: Re: [Nfd-dev] Ethernet unicast faces
>>
>>
>>
>> unicast Ethernet was one of the hackathon projects over the weekend.
>>
>> my understanding is that the code should be available real soon.
>>
>>
>>
>> On Mar 27, 2017, at 1:07 AM, Adrichem, N.L.M. (Niels) van
>> <niels.vanadrichem at tno.nl> wrote:
>>
>>
>>
>> Hello everybody,
>>
>>
>>
>> As a work-around we will now use IP or UDP/IP encapsulation, but
>> ultimately we would like to use only L2-/Ethernet-encapsulation to show that
>> these types of L3-forwarding functions can be handled using just NDN.
>>
>> I understand from the documentation that Ethernet multicast functionality
>> is achieved through a PCAP filter on the multicast Ethernet address without
>> setting the interface in promiscuous mode, suggesting a similar approach can
>> be achieved through a PCAP filter on an interface’s own unicast Ethernet
>> address without setting the interface in promiscuous mode.
>>
>>
>>
>> Best,
>>
>> Niels
>>
>>
>>
>> From: D'Acunto, L. (Lucia)
>> Sent: vrijdag 24 maart 2017 17:49
>> To: nfd-dev at lists.cs.ucla.edu; Alex Afanasyev <aa at CS.UCLA.EDU>; Davide
>> Pesavento <davide.pesavento at lip6.fr>
>> Cc: Adrichem, N.L.M. (Niels) van <niels.vanadrichem at tno.nl>
>> Subject: Ethernet unicast faces
>>
>>
>>
>> Hi Alex, Davide, all,
>>
>> I have a question about Ethernet unicast faces in NDN for usage in Wifi
>> ad-hoc.
>>
>> Do you have plans to re-implement Ethernet Unicast faces? we just
>> discovered that was removed and NFD only offers Ethernet Multicast faces for
>> now. For our ICN-IoT with WiFi Ad-hoc project this is a bit of a problem,
>> since we want to retransmit on the same WiFi interface (which again is
>> disabled in the dissemination strategy for Ethernet Multicast faces), and
>> want to use the source and destination MAC address to respectively indicate
>> who should be the next hop to retransmit the Data object and Interest.
>>
>>
>>
>> We would appreciate your help (or work arounds) with this retransmission
>> problem.
>>
>>
>>
>> Thanks!
>>
>> Lucia
>>
>>
>>
>>
>>
>> Lucia D'Acunto, PhD
>> Research Scientist
>> Media Networking
>>
>> T +31 (0)88 866 71 37
>> M +31 (0)64 696 60 10
>> E lucia.dacunto at tno.nl
>>
>>
>>
>>
>>
>> <image001.gif>
>>
>> TNO | New Babylon | Anna van Buerenplein 1, 2595DA,  The Hague, The
>> Netherlands
>>
>>
>>
>>
>>
>>
>>
>> This message may contain information that is not intended for you. If you
>> are not the addressee or if this message was sent to you by mistake, you are
>> requested to inform the sender and delete the message. TNO accepts no
>> liability for the content of this e-mail, for the manner in which you use it
>> and for damage of any kind resulting from the risks inherent to the
>> electronic transmission of messages.
>>
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>
>>
>>
>>
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>
>>
>>
>>
>>
>> --
>>
>>
>> ====================================
>> http://www.cs.colostate.edu/~susmit
>> ====================================
>>
>>
>>
>>
>> --
>>
>>
>> ====================================
>> http://www.cs.colostate.edu/~susmit
>> ====================================
>>
>>
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>
>