[Nfd-dev] review request: NDNLPv2 NACK, Fragmentation, LocalControlHeader

Ignacio.Solis at parc.com Ignacio.Solis at parc.com
Thu Jun 11 11:35:31 PDT 2015


I’m not sure I follow.

If I am a laptop, and need to connect to a WiFi router.  Do I need to know in advance what the WiFi router settings are?   Does the WiFi router need to send me a management command to “remotely” set my settings?

Does my laptop send a command to the router to say: "on my face, disable indexed fragmentation and enable B-E fragmentation”?

Are we going to need a probing protocol that sends packets until something works?  Specially if  "those packets transmitted prior to the command and received afterwards would be processed incorrectly and likely got dropped”.  Which brings up the question of, does the command have to be sent under the right settings?  Does the command have acknowledgements of execution?   Pardon my ignorance, I’m new to this topic, maybe this is all explained in the document.

Nacho

--
Nacho (Ignacio) Solis
Protocol Architect
Principal Scientist
Palo Alto Research Center (PARC)
+1(650)812-4458
Ignacio.Solis at parc.com

On 6/11/15, 7:19 AM, "Junxiao Shi" <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Dave

Enabled features can be set at compile time, in the configuration file, or through management commands.

Defaults for NFD are:

  *   Ethernet multicast and UDP multicast: indexed fragmentation, network NACK
  *   UDP unicast: indexed fragmentation, network NACK
  *   TCP: network NACK
  *   TCP local and UNIX socket: network NACK, local cache policy
     *   turn on with management command: consumer controlled forwarding, incoming face indication

There is no handshake because the receiver needs to know what NDNLPv2 features are enabled when processing the handshake packet.
However, since NDNLPv2 features can be controlled through management commands, it's possible to determine an initial set of enabled features at compile time or in the configuration file, and then change the features during runtime. This has a similar effect of handshake, because a management command can be sent from a remote node. For example, an end host can send a command "on my face, disable indexed fragmentation and enable B-E fragmentation" to the router, and the next packet will use the new fragmentation feature; but those packets transmitted prior to the command and received afterwards would be processed incorrectly and likely got dropped.

Yours, Junxiao

On Thu, Jun 11, 2015 at 4:32 AM, Dave Oran (oran) <oran at cisco.com<mailto:oran at cisco.com>> wrote:
> The protocol in charge is determined by the link, not determined by every packet.
> Before an NDNLPv2 packet is processed, the receiver already knows what features are enabled.
How? Not by hand on each end I hope? No initialization handshake?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150611/adf5fc2a/attachment.html>


More information about the Nfd-dev mailing list