Re: delay as a metric, aggregation

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 6-okt-2005, at 16:15, Jari Arkko wrote:

> I liked your idea of comparing the nominal delay to
> actual delay.

Thanks.

Although this is not an intrinsic quality, in practice delay is  
almost completely dependent on the full path between two endpoints,  
while bandwidth and packet loss are respectively so high and so low  
in the core that they're almost completely dependent on the part of  
the network local to either endpoint.

> The synthetic coordinates idea from Cedric was a very interesting
> one as well. I'd like to play with that if it became available. But  
> I fear
> that DNS storage etc. is a deployment barrier.

Well, if it is (might be, might not be, dynamic DNS is your not very  
secure friend), my earlier idea of having delay measuring beacons may  
be useful. If we assume that ISPs will typically have one or more of  
these beacons, and the beacons communicate, it should be possible to  
ask the local beacon for the estimated delay towards a certain  
prefix. The local beacon would have to to which remote beacon this  
prefix maps, and then sends back the nominal delay for that prefix.

This can be combined with Cedric's work by having the ultimate  
destination publish its distance to one or more close by beacons in  
the DNS. Or if this is a problem have the destination register its  
distance with the beacon, but then inter-beacon communication would  
end up being a shadow DNS...

> Anyway, I see two bigger issue here. The first one is the division
> of work between IP and transports. If we are sure that we
> can develop a simple scheme that works well, it would make sense
> adding to that to the IP layer. But if we find out later that
> we need to take into account variations in congestion level,
> packet loss, etc., we may find ourselves adding a lot of
> functionality to try to mimic what transports are already
> doing.

Well, transports aren't doing all that much currently...

But your point that we should be wary of feature creep is well taken.  
I think we need to have a priority mechanism similar to what SRV  
records have and a generic TLV mechanism for future extension, but  
that should be enough as a mandatory part of the shim.

> An approach that does not have this drawback would
> be providing feedback from transports and ULPs to the
> shim6 so that when they say "unacceptable", Shim6 would
> attempt to find another path.

Hm, this only works well if you need a certain service level and  
nothing more than that. Many applications like to take as much as  
they can get. For these, there is no "unacceptable".

> This would still leave the
> problem of the exploration process finding the right
> alternative with a high probability of success. I'm not sure
> we know how to do that.

Right. The only thing we know is that this is going to involve:

- communicating values and capabilities between the correspondents
- sending probe packets
- rehoming sessions

As long as the shim can accommodate all of these, the actual  
implementation of the exploration process can be left TBD.