[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: addition of TLV to locator ID or locator ID set
Erik,
I think we are in complete agreemnt here.
I want to try and clarify the latancy idea.
> Sure.
> But they might not need to be passed around. When A and B communicate,
> then A can determine the rtt to B (and the ULP such as TCP already does
> this).
> So there might not be much added benefit for A to tell B which latency
> it has observed.
I was thinking that source A could measure rtt to destination B who has
specified that use lowest latency as the locator sorting method.
The destination B would not send any rtt measurement information to A.
The source A would not send any rtt measurement information to B.
However, if one of the links to destination B is getting over loaded, then
destination B will want to migrate some traffic away from what most people
are seeing as the lowest latency link.
The idea is to posion the over utilized link by sending an additive value
that the source should use when determining the over all locator
sorting. So the source will measure rtt and add (and/or subtract
depending on how the value for this TLV type is defined) a bias
value. In this case a TLV type of "lowest latency" and a value of the
bias will be the only information sent from destination b to source a.
The default bias value for TLV type lowest latency should be 0.
(I think I may have mis-understood an eariler question TLVs being passed
around. Some how I was thining this question was asking if latency
information would be flooded across the forwarding path something like
the way IS-IS TLVs sent. Sorry if this created some confusion.)
> I think in either case we can leave the door open for additional
> information. But we need to think a bit about the criteria for what
> information makes sense passing from A to B.
I completely agree. I guess my first goal is to see if this approach
seems acceptable. Then we can try to figure out what types of
functionality is needed and what types of information will support them
initially.
Some hard thinking needs to be done on what information should be shared
between A and B, and I was not committed to doing it if the general
approach is not accepted. At the same time I felt like I needed to give
some sort of example to illustrate the concept.
I'm not married to the concept of using a TLV if there is a better
approach that is equally flexible. I proposed TLV as it seems very
flexible, can be used to carry multiple sets of values that can allows for
a complex nested sorting, and doesn't seem like a re-invention of the
wheel.
I think the biggest problem is doing something analogous to current IPv4
BGP "best" path. Since hosts lack routing state, this will need to be
done in the forwarding plane. At a glance this seems to have all of the
same problems that path failure detection has, with some additional
problems thrown in because you may have to test multiple paths to make a
compairson instead of only one.
The question here is what are the solution spaces for path failure
detection, and do any of them fit nicely with trying to determin some sort
of forwarding plane measured "best" path.
___Jason
==========================================================================
Jason Schiller (703)886.6648
Senior Internet Network Engineer fax:(703)886.0512
Americas' Network Engineering schiller@uu.net
UUNET, an MCI brand jason.schiller@mci.com
On Wed, 21 Sep 2005, Erik Nordmark wrote:
> Date: Wed, 21 Sep 2005 17:55:09 -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:
>
> > Also depends on the pain involved in changing DNS (I don't have any
> > insight into this)
>
> Getting wide-spread SRV records would take some time.
> First of all, the significant applications must try to look them up (so
> that when the web browser looks for www.example.com, it looks for SRV
> records at _http._tcp.www.example.com first, and if none found, it looks
> for AAAA/A records for www.example.com).
> I don't know if there are already applications/systems that look for SRV
> records.
>
> When we have that, then the DNS admins for the sites need to put the SRV
> records in their DNS servers.
>
> But there isn't any protocol change needed to the DNS.
>
>
>
> >>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.
>
> Sure.
> But they might not need to be passed around. When A and B communicate,
> then A can determine the rtt to B (and the ULP such as TCP already does
> this).
> So there might not be much added benefit for A to tell B which latency
> it has observed.
>
> > I think this works, but I'm not sure it will cover all cases and has
> > flexibility for future growth.
>
> I think in either case we can leave the door open for additional
> information. But we need to think a bit about the criteria for what
> information makes sense passing from A to B.
>
> > 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.
>
> I don't see a problem with the principle of having this type of
> extensibility. But I don't yet understand, as for latency, whether a
> packet loss metric would be something that A can measure and keep track
> of for its own purpose only, vs. A also being able to pass that metric
> to its peer B.
>
> Erik
>