Re: addition of TLV to locator ID or locator ID set

["Jason Schiller (schiller@uu.net)" <jason.schiller@mci.com>]

On Wed, 21 Sep 2005, Iljitsch van Beijnum wrote:

> Date: Wed, 21 Sep 2005 23:35:33 +0200
> From: Iljitsch van Beijnum <iljitsch@muada.com>
> To: Jason Schiller <jason.schiller@mci.com>
> Cc: shim6-wg <shim6@psg.com>
> Subject: Re: addition of TLV to locator ID or locator ID set
> 
> On 21-sep-2005, at 21:00, Jason Schiller (schiller@uu.net) wrote:
> 
> > Summary:  support for an additional TLV is required in order to  
> > allow for
> > a destination (sink) to signal to a source which links should be  
> > utilized
> > to carry traffic inbound to the destination (sink).
> 
> You're of course completely right that something closely resembling  
> this should be part of the shim. Thank you for writing it down  
> explicitly.
> 
> > 3. Lowest latency -- paths with lower measured latency will be  
> > preferred
> > over paths with higher latency.  A value set will be added or  
> > subtracted
> > to the measured value for biasing
> 
> Hmmm...
> 
> I'm not sure we can cook something digestable from the delay, except  
> that if we're first using address pair AX with delay N, and then pair  
> BY has delay M where M is a lot larger than N, it probably makes  
> sense to continue to test CZ and so on, while if M <= N there is no  
> need to search any further.
> 
> > An additional draft will need to be written to define the default
> > locator ID selection process, and how the TLVs will be used to modify
> > locator ID selection.
> 
> Please don't say "locator ID", it sound like "dry wet". We have  
> locators and identifiers, both are addresses and some addresses are  
> both.
> 
> Since at this stage, we're only considering the case where the  
> initial session setup happens in a backward compatible way, the shim  
> has no influence over the selection of the initial address pair. We  
> also presume that it's best to engage the shim only when there is an  
> outage. This means that for most traffic, the traffic distribution  
> depends on regular destination and source address choices like they  
> exist today. That's probably not good enough, though. An obvious  
> mechanism to influence this would be SRV records in the DNS, which  
> would need the same TLVs that you propose for the shim in your  
> message (as far as they're missing from the current SRV specs).

I guess what I was envisioning was at least the option to leverage the
shim, and use different locators as soon as the shim6 handshake is
complete rather then waiting for an outage.  

Initial TCP set up should be backward compatabile, and not being a DNS
guy, I'm not sure how much pain is involved in the SRV DNS
records.  Assuming the amount of DNS pain is large, then we need to
consider what is the impact of of picking the address at random at the
start, and switching over to the "optimum" address after a few packets
have been exchanged.

I guess the question to network operators is if there are networks where a
majority of the sessions are a very short lived.


> 
> > Some TLVs may also rely on a forwarding component in order to sort the
> > locator IDs.  I wanted somethin analogous to the current BGP "best"  
> > path.
> 
> Do you mean "best" by virtue of the BGP path selection algorithm left  
> to its own devices, or "best" after having massaged the values the  
> BGP selection algorithm takes into account?
> 

The concept of "best" that I have is something that provides analogous
functionality to what IPv4 BGP AS path.  The concept is using the most
optimum path which in a loose sense is the shortest path.  If there could
be some sort of latency check then the "best" path can be a function of
the strick latency measurment.  

AS pre-pend in IPv4 BGP allows for making the best path a little less
best.  Tis will cause sources that are very close to the best and second
best path to switch over to the second best path.  Sources close to the
best path but far from the sceond best path will not switch.

Adding a biasing factor for the latency measurement, can allow the source
to make the latency check and add the biasing factor, So in this case the
best path is the one with the best latency plus or minus the bias factor.