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

Ignacio.Solis at parc.com Ignacio.Solis at parc.com
Sun Jun 14 23:22:14 PDT 2015


We¹re in favor of discussing this in Prague.

Nacho

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





On 6/13/15, 5:42 AM, "Dave Oran (oran)" <oran at cisco.com> 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