[Nfd-dev] Ethernet unicast faces

Sat Aug 12 17:17:41 PDT 2017

Hi Davide,

On behalf of Niels (who is probably sound asleep now 😊 : Thanks!

At first glance, it seems to be working \0/
(Just did a quick test with ndncatchunks/ndnputchunks over a unicast Ethernet face in the CORE emulator)

Thanks again,
Ronald in 't Velt

> -----Original Message-----
> From: Davide Pesavento [mailto:davide.pesavento at lip6.fr]
> Sent: zondag 13 augustus 2017 1:26
> To: Adrichem, N.L.M. (Niels) van <niels.vanadrichem at tno.nl>
> Cc: Wissingh, B.F. (Bastiaan) <bastiaan.wissingh at tno.nl>; Velt, R. (Ronald) in
> 't <Ronald.intVelt at tno.nl>; nfd-dev at lists.cs.ucla.edu
> Subject: Re: [Nfd-dev] Ethernet unicast faces
> 
> 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
> >>
> >