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

christian.tschudin at unibas.ch christian.tschudin at unibas.ch
Sat Jun 13 09:21:15 PDT 2015


Hi Dave,

we should extend the small workgroup we had at Dagstuhl on operational 
NW management. Iterating from then: NW mgmt is the killer app - if it's 
badly done you are dead.

See you in Prague,
christian


On Sat, 13 Jun 2015, Dave Oran (oran) wrote:

>
>> On Jun 12, 2015, at 4:26 PM, Marc.Mosko at parc.com wrote:
>>
>> Dave,
>>
>> I think BFD has some good features, but it does not itself have a discovery mechanism and must be configured.  It also has some older authentication mechanisms.  It also reserves point-to-multipoint for future use, which for router-to-router links is probably not a problem but if it is expected to run on every node on a LAN, I think the point-to-point nature of BFD would not scale well.  BFD does not include a capabilities exchange, except for its own parameters, so we would need to do something beyond what it offers (without getting as far out there as ML-PPP).
>>
> Good points. I withdraw the suggestion about BFD as a model for auto-configuration, although it is definitely worth looking at as a model for how to do an adjacency maintenance protocol.
>
>> There is quite a bit of work on neighbor discovery and link maintenance, so I think we can put together something that would be ok to run on all nodes on a multiple access link without being overwhelming.  Also, if one uses a route-reflector approach then one does not need to monitor a full mesh but only those in-use destinations.
>>
> It would be really good to work together on this (i.e. the NDN and CCN communities). We’ve done some internal work at Cisco as well, but mostly as an experimentation harness in Python to try to get the semantics right before worrying about packet formats.
>
> Maybe we could collaborate on some talks at ICNRG in Prague to try to scope the work and prevent divergence in our designs? Seems this is an area where our other design differences won’t affect things much.
>
> DaveO.
>
>> Marc
>>
>>
>> On Jun 12, 2015, at 4:57 PM, Dave Oran (oran) <oran at cisco.com> wrote:
>>
>>>
>>>> On Jun 11, 2015, at 5:59 PM, Alex Afanasyev <alexander.afanasyev at ucla.edu> wrote:
>>>>
>>>> I think what we are talking here are two orthogonal issues.
>>> Well, we differ on that. I don’t think they are orthogonal at all.
>>>
>>>> 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.
>>>>
>>> But they aren’t - the purpose of a link layer adaptation protocol is to…well…adapt to the link. In some cases in fact, you need to measure the link in order to know what the adaptation should be. While this is an ancient example that may not be applicable now, the general principle may apply:
>>>
>>> When we were deigning ISIS we discovered that some Ethernets would pass full link-sized packets and some would not (either due to physical layer errors or buggy repeaters). So, one could initialize the link and even exchange small packets, but real packets would get dropped. So, we made sure that the link initialization protocol padded the hello packets to the maximum size. (This had some amusing second-order consequences, such as what to put in the padding - different people were were funny in a number of creative ways).
>>>
>>> I’ll also note that failing to do this caused us to have many different adjacency-establishment protocols on top of the same kind of link, which in turn resulted in multiplicity of link management schemes, which even now is not cleaned up. At least now we have BFD, which has a way to unify these separate protocols under one umbrella. Maybe we should adopt BFD as the substrate to do the NDN-specific link adaptation features rather than starting form scratch?
>>>
>>> You can of course go too far in the other direction, for example with the PPP multi-layer link management stuff which got unnecessarily complicated.
>>>
>>>> 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.
>>> I think we need to do this now - it’s to me a fundamental part of defining the link adaptation protocol(s).
>>>
>>>>
>>>> ---
>>>> 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
>>>>
>>>
>>> _______________________________________________
>>> 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
>


More information about the Ndn-interest mailing list