Re: [DNA] IMPORTANT: Combined DNA Solution draft

[Brett Pentland <brett.pentland@eng.monash.edu.au>]

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.