Bill,
Before diving in here, a few people mentioned that I
should have put the following in front of my last post
(to Robin) instead of at the end:
Based on your comments, it seems to me that you didn't
understand that the purpose of the draft was to more
deeply understand the architectural implications of
Loc/ID split, not to advocate for or against any
particular proposal.
That said:
> What I proposed in TRRP, and I *think* what Robin proposed in Ivip, is
> that the choice to switch between locators should be driven by a
> heuristic system external to the protocol itself.
>
> The destination system uses this external heuristic to choose its
> locators, and the source system blindly follows the destination
> system's instruction. If the path between the source and destination
> locators is dead, it's up to the destination to figure this out (using
> the external heuristic system) and alter its locator to one that
> works.
>
> Examples of such a heuristic include:
>
> 1. I think my Internet link is bunged up, so I press the "switch
> locators" button and that alters my map entry.
What does "alters my map entry" mean? Who does it, on
what time scale, who has visibility into data and when,
what bits get sent where, etc. You get the picture.
What we need to see detail, precisely because that is
where the problems arise. From that perspective, "alters
my map entry" is almost (if not completely) content free.
> 2. A monitoring system at my network border polls external public
> probe sites and watches for retransmission in the TCP sessions which
> pass by it. If the failure rate exceeds the programmed threshold, it
> decides my Internet link is bunged up and alters my map entry to favor
> a different locator.
Really? You want to put the dependency that routers (or
something) must snoop the data plane for TCP state to
make connectivity work? Notwithstanding the wisdom of
introducing that dependency, what if traffic is
unidirectional (or otherwise asymmetric), UDP, or ...
And what if its multiple 10GE fire hoses blasting data at
you?
I won't even start down the security/privacy path with
that one.
> 3. A globe-spanning Akamai-like system of testpoints builds a complex
> map of Internet path states. Combined with some basic information
> about the state of my connections to my ISPs, it can compute what will
> usually be a good current locator selection for me. I subscribe to
> this service.
If you can't reach the endpoints (good or bad), none of 3.
matters; not I think that making the network layer depend
on this kind infrastructure, and not to mention the
circular dependency that could arise.
But again, these high level descriptions of how something
that is largely unspecified (notably the "heuristic system
external to the protocol itself") doesn't help me
understand (i). what mechanism you are proposing,
(ii). what its properties are, and (iii). if it even
works.
OTOH, what would be helpful would be for you and/or Robin
to describe *the mechanism and how it works, in detail*
that you are proposing, then show how it solves the
simple example problem in Section 3 (Figure 1) for the
draft.
> This approach addresses the locator liveness problem by substituting a
> heuristic for an algorithm. It accepts that while the result will
> usually be good enough it won't always be perfect and may rarely
> require intervention.
I guess I'm not understanding, primarily it seems since
you haven't given any detail about how this would
actually work.
My point is that statements like "substituting a
heuristic for an algorithm" don't really enighten us as
to the solutions (or their properties) that you are
proposing.
Please give details so we can understand.
Dave
signature.asc
Description: Digital signature
_______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
