Re: [p2pi] Information in an ALTO protocol

[John Leslie <[e-mail]>]

Vijay K. Gurbani <[e-mail]> wrote:
> John Leslie wrote:
>> Vijay K. Gurbani <[e-mail]> wrote:
> 
>>> At present, we have the following discrete pieces of information
>>> mentioned in the post-BoF charter:
>>>
>>>  (1) Routing preferences
>>>  (2) Priority values
>>
>>   These are a bit amorphous...
> 
> Fair enough.  Folks have suggested that preferences and priorities
> along the lines of:
> 
>   <local 1> _is_better_than_
>    <external ASN 2> _is_better_than_
>     <local 2>
> 
> How do you see that we can make these a bit more concrete?

   I get nervous when I see sorting by priority -- all it takes is one
item changing and your whole sorting is invalidated. I'd like to gather
information with very little tendency to change and report that.

   When we talk "local", we risk confusing different categories of
"local". Are we talking a neighborhood, a geographic area where
concentration is done, a routing domain, an Autonomous System, an
island, a continent, or what? Also, if "local is better", better for
what?

   I claim that what we really care about is congestion choke points.
And obviously, we care the most about choke points which will actually
be congested during our p2p transfer.

   So I'd prefer information such as

- the uplink from this CIDR block is congested part of most days;
  when its latency exceeds 10 milliseconds, assume it's congested.

- the downlink to this CIDR block is congested part of some days;
  when its latency exceeds 20 milliseconds, assume it's congested.

- the up & down link from this CIDR block to our nearest peering
  point is seldom congested; it's minimum latency is 11 milliseconds.

- our peering for CIDR blocks (a, b, c...) to AS #### is seldom
  congested.

- our peering for these CIDR block to AS #### is occasionally
  congested; packets start dropping at a latency of 1.4 milliseconds.

- peering for AS #### usually flows through AS ####

   These are all things that a NOC is aware of -- though admittedly
management _may_ believe that admitting to these would somehow
benefit their competiton.

   What the application wants to know, of course, is the above for
its local ISP plus the corresponding info for the destination ISP's
CIDR block. Being a simple-minded fellow, I thing it would be nice
to be able to query both ISPs. (The query to the remote ISP, of
course, could be done more efficiently by the tracker.)

>>>  (3) AS numbers
>>
>> Sometimes very useful; sometimes not...
> 
> But arguably a low-hanging fruit that does indeed provide some
> information that is helpful in the absence of any other guidance.

   AS numbers are very useful if we're trying to model the behavior
of routers; but this is not always the case: rather often we're
overwhelmed by local congestion.

>>>  (4) Geographic location
>>
>> Often wildly inaccurate, and even more often quite unrelated to
>> network topology. Would be _very_ useful in an alternate universe where
>> routing found next-hops _physically_ closer to the destination...
> 
> Probably needs a bit more discussion on whether or not this is
> valuable before discarding it.

   I don't mean to discard it; but I hesitate to put much weight on
it.

>>> 6 can be provided by the network operator or approximated using
>>> synthetic coordinate systems and the like.
>>
>> Actual topology is likely to change without warning; so you should
>> be prepared for it to prove wildly inaccurate. More often than not,
>> it turns out to be only roughly approximated or hopelessly optimistic.
> 
> Sure; synthetic coordinate systems have been designed with
> approximations and opportunistic optimism in mind.  While the
> active guidance of an ISP in imparting topological information
> is best, we should not preclude third-party services from
> approximating the same to the best of their abilities.

   Actually, most of the stuff I listed at the beginning of this
email can be reasonably well approximated by trackers cooperating
with peers. IMHO, they'd be better advised to gather those data
than chase synthetic coordinates. (YMMV)

>>> Information that has been deemed out of scope based on list
>>> discussion is:
>>>
>>>  (1) Last hop bandwidth
>>
>> The most useful number yet listed, _if_ folks will give it to us
>> and we interpret it correctly...
> 
> Hmmm ... so I suspect that it is premature to say that last-hop
> bandwidth is out of scope?  What do others think?

   For myself, I think we'd be silly to rule it out-of-scope because
we don't believe ISPs would agree to provide it. _Any_ question we
ask an ISP may well receive a "none-of-your-business" reply.

>>> What other sort of information should be a focus of ALTO?
>>
>> It would be rather useful to have "characteristics that indicate
>> congestion" on a path. The applications are going to have to judge
>> instantaneous congestion anyway, and basing that judgment on
>> known characteristics rather than guesswork should speed progress
>> towards an optimal mix.
>>
>> Jitter in the latency will be of interest to certain applications.
> 
> I believe that these will fall squarely in TANA, if not some other
> TSV WG.

   I don't mean to infringe on any other WG's charter: I just mean
that jitter information would sometimes be helpful in choosing a
peer. I venture no opinion on who should provide it.

--
John Leslie <[e-mail]>
_______________________________________________
p2pi mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/p2pi