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

[Alex Afanasyev]

I think what we are talking here are two orthogonal issues.  The first priority here is to define NDNLP2 as a protocol to work as adaptation layer under an assumption that parameters of the link are known.

If we get to the point that we need to negotiate NDNLP features on the link, then we would need to figure out how to do this negotiations, e.g., with some interests/data handshakes or some other way.

---
Alex

> On Jun 11, 2015, at 7:27 AM, Dave Oran (oran) <oran at cisco.com> wrote:
> 
>> 
>> On Jun 11, 2015, at 10:19 AM, Junxiao Shi <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.
> How do you get the management command to the node if the link hasn’t come up with NDNLP2 running yet?
> How to you “reset” the link if it gets desynchronized due to a bad management command setting?
> How do you do version checking?
> How does a receiver tell a transmitter what is the acceptable maximum MTU?
> 
> I don’t have a problem using Interest/Data exchanges as the way to do the initialization handshake, but I don’t see how this works reasonably when starting from an unknown or incorrect state, and I don’t see how the link state machine is maintained.
> 
>> 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> 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?
> 
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150611/50cf637a/attachment.bin>