[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