Subject: [p2prg] Random Thoughts on draft-asai-cross-domain-overlay-01

From: Russ White <[email-masked]>
Date: Mon, 01 Aug 2011 14:18:15 -0400

Y'all:

My first comment is this all seems like a heuristic based on
understanding current business models and modes --if business models
change, the entire underlying structure needs to change. I'm not certain
that's a really good place to be. On the other hand, I'm not certain
there's a lot of other options in this sort of work.

But it's at least worth discussing, I think.

For more specific comments:

==
It is true that AS paths can be resolved from IP address-based paths,
which can be retrieved by network management tools (e.g., traceroute).
Hence, ASes do not have to provide AS paths because applications can
resolve AS paths without support of ASes.  However, it is an ongoing
work to assign appropriate AS numbers to routers [Huffaker10].

I wonder why you wouldn't start with just peering to the BGP peers that
you can, and pulling a database into a torrent, so you have this as a
"background reference?" Then you could consult this database first, and
if the destination is not found there, then use other techniques? You
could also use some sort of location type service to choose a table that
would provide the closest view to your current location as a base --the
table from a provider as close to where you are as possible.
This would also be "publicly available information," I think, something
like having a "private P-2-P route view?"
Or this covered in section 4.1?

==
The algorithms based on paths analysis have a difficulty in applying the
inferred AS to the cost computation because there are lots of missing
links, which have not been inferred.

It seems like another way to estimate relationships would be based on
the routes actually advertised. For instance, if an AS receives a lot of
routes at 24 bits, and then sends those out plus a shorter length prefix
that covers them, then the relationship is almost certainly transit,
rather than peer (?). This intuition could be completely wrong, though.

==

Overall, this is a good start --given the caveat above about heuristics
based on current business models. There are some places where we might
could gather more specific information.

Perhaps the only real option, long term, is something like a PSV, or
other graph overlay on BGP?

:-)

Russ

---

From: Hirochika Asai <[email-masked]>
Date: Thu, 4 Aug 2011 20:58:12 +0900

Thank you, Russ.

I agree with your point that the proposal in our draft depends on current
business models.  These kinds of underlying structures will change with adapting
application needs and the actual traffic.  Consequently, the proposed solution
approach may not be the best one, or may be poor, but discussing considerations
and problems with application-layer traffic optimization on the current
underlying business model is essential even before the ALTO architecture has
deployed.

> Or this covered in section 4.1?

Yes, retrieving BGP-level paths from BGP routers is the simplest approach.  In
S4.1, we assume that this function is included in the "AS Path Provision
Service".  S4 is one of the possible solution but there should be more
alternatives and confusing description.  Hence, we want to get started from
problem statements of "cross-domain" application-layer traffic optimization,
such as policy conflicts.  After we could brush up or get a consensus on the
problem statements, we want to extend the view to the architecture to solve
them, like S4.

> other graph overlay on BGP?
In my opinion, PSV like BGP is hard to be an option for overlay networks due to
the size of path-vector tables.  Path-vector tables are computed for each file
or stream when PSV is used.  However, I cannot say how large the tables are, at
this time.  I should show the size, the  possibility of table aggregation, etc.
We'll work on it soon!

Thank you, again.
Hirochika

On Aug 2, 2011, at 3:18 AM, Russ White wrote:

> _______________________________________________
> p2prg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/p2prg
> 

-- 
Hirochika Asai <[email-masked]>, The University of Tokyo