Re: [DNA] IMPORTANT: Combined DNA Solution draft

[Christian Vogt <chvogt@tm.uka.de>]

>>> [...]
>>>
>>>   - If the RS has a landmark and the router recognizes it
>>>     a short RA is possible.
>>>   - If the RS has a landmark but the router doesn't
>>>     understand it, the landmark is ignored and a complete RA is sent
>>>     that the host can use to make an immediate decision.
>>>   - If the RS has no landmark, then the router sends a
>>>     complete RA that the host can again make use of immediately.
>>
>>
>> Its agreed that if complete RAs can be used then there's
>> really no issue (other than perhaps loss of a little bit of
>> bandwidth, but I wouldn't worry about that). However, in
>> your second case above, what happens if the RS has a landmark,
>> the router doesn't implement them, and it can't fit all the
>> prefixes in the complete RA? It seems that the router will
>> make a "random" decision of what prefixes to include, and
>> since it doesn't recognize the landmark option, it may not
>> include the host's prefix. Will this cause a problem?
>
>
> I don't think so.  The choice of prefixes to include is not quite
> random, because the router is required to include the "LinkID" prefix.
> That may not be the prefix that the host picked as a landmark, but
> it will have been received by the host in any earlier RAs if movement
> has not taken place.  Note that I removed the word optional in the
> suggested text for the previous comment because the the language in
> section 6 does not make the LinkID inclusion optional.


I thought you agreed earlier during your discussion that Landmark and
LinkID are optional for hosts only, but both mandatory for routers.

If you change the draft in this regard, a router not understanding the
Landmark option would consequently not support the DNA Protocol 3 at
all.  But such a router would not support LinkID either, and the host
would end up having to apply CPL logic anyway to arrive at a movement
decision.

The host recognizes that it must use CPL because it sent a Landmark
option with the RS, but the solicited RA neither includes a Landmark
option nor has the C flag set.

This said, I don't see a reason why "case 2" (i.e., the RS has a
landmark but the router doesn't understand it) need to be considered for
this protocol at all.

Am I missing something?

- Christian

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/



Brett Pentland wrote:
> Jari Arkko wrote:
> 
>> Brett Pentland wrote:
>>
>>>>>   Frequently, all routers on a link will advertise the same set of
>>>>>   prefixes and so this technique will incur no space penalty. 
>>>>> However,
>>>>>   on links where routers advertise different sets of prefixes, packets
>>>>>   may be larger.  To combat this, two optional mechanisms are defined.
>>>>>  
>>>>>
>>>>  From what I understand, Landmark RAs can actually be
>>>> shorter than regular RAs, even if all routers have the
>>>> same prefixes. If there's, say, three prefixes, then the
>>>> optimized unicast answer can include just the landmark
>>>> but not the other options. Or am I missing something?
>>>
>>>
>>>
>>>
>>> Yes, that's true.  This is one of the techniques offered below that can
>>> reduce the RA size.
>>
>>
>>
>> Right. But the text in the draft seemed to be saying that
>> these optimizations are only for the situation where different
>> prefixes are advertised by different routers. Can we get that
>> fixed?
> 
> 
> Ah, ok, I get it now.  I'll fix it up.  How about a change from:
> 
>    Frequently, all routers on a link will advertise the same set of
>    prefixes and so this technique will incur no space penalty.  However,
>    on links where routers advertise different sets of prefixes, packets
>    may be larger.  To combat this, two optional mechanisms are defined.
> 
> to:
> 
>    Though frequently all routers on a link will advertise the same set
>    of prefixes and thus experience no cost in making the RAs complete,
>    there is potential for the RAs to be large when there are many
>    prefixes advertised.  Two mechanisms are defined that allow certain
>    RAs to be reduced in size.
> 
>>
>>>>>   One uses a technique called a "landmark", where the host chooses one
>>>>>   of the prefixes as a landmark prefix, and then includes this in the
>>>>>   Router Solicitation message in the form of a question "am I still
>>>>>   connected to the link which has this prefix?".  The landmark is
>>>>>   carried in a new option, called the Landmark Option.
>>>>>
>>>>>   A second mechanism for reducing packet sizes applies to unsolicited
>>>>>   Router Advertisements.  By selecting one prefix on the link to be
>>>>> the
>>>>>   "link identifier", and making sure that it is included in every
>>>>>   advertisement, it is possible to omit some prefixes.  Such
>>>>>   advertisements will not inform a host of all of the prefixes at
>>>>> once,
>>>>>   but in general these unsolicited advertisements will not be the
>>>>> first
>>>>>   advertisement received on a link.  Inclusion of the link identifier
>>>>>   prefix simply ensures that there is overlap between the sets of
>>>>>   prefixes advertised by each router on a link and that hosts will
>>>>> thus
>>>>>   not incorrectly interpret one of these incomplete RAs as an
>>>>>   indication of movement.
>>>>>  
>>>>>
>>>> I have two issues with this. One is that the optionality
>>>> should be defined in a stricter way (and as far as I can
>>>> see its not done later either, at least not in 6.1.5.1). It
>>>> seems obvious to me that if we are touching code in the
>>>> routers, we should at the same time make it mandatory
>>>> to support the optimized decision mechanism. Then it
>>>> can be optional for _hosts to use_. If router support
>>>> is optional then we end up in a situation where landmark
>>>> request may fail, which consumes time.
>>>
>>>
>>>
>>>
>>> You may be right, but I'm not sure.  The intent here is that the base
>>> means for determining link change is the complete RA.  If both
>>> the host and router support landmarks, then the smaller RA
>>> is possible.  I can't think of a good reason why a router would
>>> not want to support landmarks, but I don't think whether it does
>>> or doesn't breaks anything.
>>>
>>>   - If the RS has a landmark and the router recognizes it
>>>     a short RA is possible.
>>>   - If the RS has a landmark but the router doesn't
>>>     understand it, the landmark is ignored and a complete RA is sent
>>>     that the host can use to make an immediate decision.
>>>   - If the RS has no landmark, then the router sends a
>>>     complete RA that the host can again make use of immediately.
>>
>>
>>
>> Its agreed that if complete RAs can be used then there's
>> really no issue (other than perhaps loss of a little bit of
>> bandwidth, but I wouldn't worry about that). However, in
>> your second case above, what happens if the RS has a landmark,
>> the router doesn't implement them, and it can't fit all the
>> prefixes in the complete RA? It seems that the router will
>> make a "random" decision of what prefixes to include, and
>> since it doesn't recognize the landmark option, it may not
>> include the host's prefix. Will this cause a problem?
> 
> 
> I don't think so.  The choice of prefixes to include is not quite
> random, because the router is required to include the "LinkID" prefix.
> That may not be the prefix that the host picked as a landmark, but
> it will have been received by the host in any earlier RAs if movement
> has not taken place.  Note that I removed the word optional in the
> suggested text for the previous comment because the the language in
> section 6 does not make the LinkID inclusion optional.
> 
>>> If it is unclear then clearly the text needs some tweaking :)
>>> They are not meant to be compared with one another because
>>> they apply in different situations.  Landmarks are useful
>>> for the RS/unicast RA exchange.  LinkID allows unsolicited
>>> RAs to be shortened.
>>>
>>> In this draft, hosts have no notion of the LinkID.  They are
>>> looking for RAs that have no prefixes in common with those that
>>> they have already seen as an indication that they have moved to
>>> a new link.  The LinkID is just a way to make sure that there
>>> will always be overlap between the sets of prefixes in RAs that
>>> are advertised on a link.
>>
>>
>>
>> Your explanation makes sense, but I'm still unsure if
>> the arrangement has to be the way it is. For instance,
>> it would seem that if hosts picked landmark the same
>> way as routers pick linkid, then we would need just
>> one mechanism.
> 
> 
> Hmm.  So the host selects the landmark the same way as the routers
> pick the linkid and then rather than including a landmark
> option in the RA the router just prepares to send its usual RA (which
> must include the linkid) but if the landmark and linkid
> match, then the router can omit everything except the linkid?
> That might work.  Is it what you had in mind?
> 
>> Or if we used just Landmark... not
>> sure I see a big need to reduce packet sizes in unsolicited
>> RAs.
> 
> 
> There's also the assurance of prefix overlap even when it is not
> possible to fit all of the prefixes in a single RA.
> 
>>
>> These alternatives have probably been explored in depth
>> already, sorry if I'm repeating questions that you guys have
>> worked on in the design teams etc. for a long time.
> 
> 
> No that's fine.  This partly comes up because of the attempt to
> merge ideas from two previous proposals, and so is fairly recent.
> 
>>>>
>>>> Does scope matter?
>>>
>>>
>>>
>>>
>>> Well, it must be greater than link-scope.  Beyond that, I guess
>>> that uniqueness is more important than scope.  A ULA prefix,
>>> for example, should be fine even though it has local scope.
>>> Perhaps some explanatory text to this effect?  How about:
>>>
>>>    The prefix MUST be one of those that the host has
>>>    used to assign a non-link-local address to itself.
>>>    While any scope greater than link-scope is acceptable,
>>>    the prefix SHOULD be one that is unlikely to be advertised
>>>    on another link.  Globally Aggregatable Unicast Address
>>>    prefixes and Unique Local Address prefixes are examples
>>>    of this.
>>
>>
>>
>> Your explanation above may be enough, not sure if you
>> need to add anything to the draft. Is there a prefix type
>> that is likely to be non-unique (other than link-local)?
> 
> 
> None that leap to mind.  I guess I was just allowing for the
> possibility.
> 
>>>>
>>>> Suggestion: don't talk about the latter two at all. Change
>>>> text to talk about case 1.
>>>
>>>
>>>
>>>
>>> I think this was getting at the latter two.  With case 1 were you
>>
>>
>>
>> Ok. Some clarification in the text is probably needed.
>>
>>> referring to the time between sending an RS and receiving an RA?
>>> I don't think we have discussed that at all, so it's a good one to
>>> discuss.  Should packets from upper layers be blocked until
>>> completion of DNA (and possible address reconfiguration)?
>>> I'm not sure about that one.  On one hand we don't want to lose
>>> packets if we have actually moved, but on the other, we probably
>>> don't want to sit around waiting for an RA when we're really still
>>> on the same link (maybe there's only one router and the first RA
>>> got lost).  I'd probably lean towards blocking.  Does anyone have
>>> any suggestions?
>>
>>
>>
>> No, but I'd note that there's both outgoing and incoming
>> packet issues.
> 
> 
> So you don't think the draft should say one way or another, but should
> note the issue, or it needs to discuss the issue and note that it
> affects both outgoing and incoming packets?
> 
> Thanks again for your help.
> Brett.