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, Erik Nordmark wrote:

> Date: Wed, 21 Sep 2005 16:10:37 -0700
> From: Erik Nordmark <erik.nordmark@sun.com>
> To: "Jason Schiller (schiller@uu.net)" <jason.schiller@mci.com>
> Cc: shim6-wg <shim6@psg.com>
> Subject: Re: addition of TLV to locator ID or locator ID set
> 
> 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).
> 
> Jason,
> 
> I don't see a problem with adding some priority and weight 
> TLV/information to the locators.
> But I wonder if this is supposed to work in the larger scope.
> 
> Take a site with 6 ISPs. This presumably means each of their servers 
> will have 6 AAAA records (one for each prefix).
> Thus the clients out there will lookup www.example.com and get 6 AAAA 
> records in the set (and it is a set; there is no implied order among the 
> records in DNS RRset).
> So the client will try them in an order that example.com can not control 
> (RFC 3484 effects the order presumably).
> 
> Once it has connected using address A5, the client might communicate for 
> a while before it decides to setup the shim context. Thus some packets 
> will flow using A5. When it has setup the context, the client will 
> discover that A1 and A2 has higher priority than A5, using the proposed 
> TLVs/information.
> 
> Should that cause the communication to immediately switch over to A1 or 
> A2, even though A5 is working fine?

I think at the least there needs to be the option to immediately switch
over.

> 
> And what about the fact that the initial communication is done using the 
> information in the DNS, and AAAA records don't have a priority/weight? 
> Should we recommend that applications switch ASAP to using SRV records, 
> so that example.com can express there priority in the SRV records?
> 
> Or would be be sufficient for the long-lived communication (that has 
> setup shim6 state) to switch to the most preferred locators?

I think you are right here, if in gerenal the sessions are long lived,
then the initial packet exhcange prior to the shim6 setup is not a big
deal.  However if a particular network has only short lived sessions this
may be problematic.  I don't know if there are any such networks. 

Also depends on the pain involved in changing DNS (I don't have any
insight into this)
> 
> > Initial TLV scould include:
> > 
> > 1. Link Order -- lower value link order is always used before higher link
> > order
> 
> FWIW The SRV records use the term "priority" for this, so it might make 
> sense to use the same term.
> 
> > 2. Round-robin -- value specified would weight the round-robin.  No value
> > would result in a non-weighted round-robin for all locator IDs in the set.
> 
> > 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
> 
> Do you see latency as being a TLV being passed around, or merely 
> something that one of the endpoints can take into account when selecting 
> the locator to use?
> 

I for see all these preference exhcanges only being shared between the
destination and the source.  

> 
> > Take the case where link 1 is an OC-3 and link 2 is a DS-3.  In this
> > case you would want the OC-3 to carry three times more traffic than 
> > the DS-3.  In this case, the destination may want to alter the pre-
> > existing policy (from above) such that link 1 carries 75% of the traffic
> > and link 2 carries only 25% of the traffic.  This can be accomplished
> > by weighting the round-robin.
> > 
> > (1)    -- TLV type = round-robin, Value = 0.75
> > (2)    -- TLV type = round-robin, Value = 0.25
> > (1, 2) -- TLV type = link order, Value = 0
> > (3, 4) -- TLV type = link order, Value = 1
> > (5, 6) -- TLV type = link order, Value = 2
> 
> FWIW the priority/weight combination in the SRV RFC is a bit more 
> general. First you rank things based on the priority value. Within the 
> subset with the same priority value, the weight is taken into account to 
> do a random draw of which to use. Thus in the above example, the 
> secondary locators 3 and 4 can also have weights.
> (1) priority = 0; weight = 75
> (2) priority = 0; weight = 25
> (3) priority = 1; weight = 90
> (4) priority = 1; weight = 10;
> (5) priority = 2; weight = 1;
> (6) priority = 2; weight = 1
> 
> That way, when 1 and 2 fail, there is a 90/10 split between 3 and 4.
> And when they fail, there is a 50/50 split between 5 and 6.
> 
>     Erik
> 

I think this works, but I'm not sure it will cover all cases and has
flexibility for future growth.

With the different TLV types, additional types can easily be added so long
as you can define how to treat when the new type collides with the
pre-existing types at a give set level.  

Say in the future you want to add another type to consider packet
loss.  In this case you simply add another TLV type and define its
values.  In addtion you have to clarifiy what to do when a source signals
to ues the lowest latency and the lowest packet loss for all
links.  Clearly one has to take precedence over the other.


___Jason