[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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?
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?
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?
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