[rrg] Fundamental objections to a host-based scalable routing solution

[Luigi Iannone]

William,

I got the misunderstanding. You where using the term _link_ as synonym 
of _path_ (at least at the end of the mail you talk about best working 
paths). For paths, you are right.

Thanks

Luigi




William Herrin wrote:
> On Tue, Nov 25, 2008 at 3:06 PM, William Herrin <bill at herrin.us> wrote:
>> Lets look at it a little more concretely:
>>
>> Machine 1 has locators A, B and C.
>> Machine 2 has locators D, E.
>>
>> The path from E to B is broken and delivers no packets. The others are
>> working normally.
>>
>> So, machine 1 sends a sequence of packets. They travel: A->D, B->E,
>> C->F, A->E, B->F, C->D and so on. The acks and any payload from
>> machine 2 come back D->A, E->B (dropped), D->C, E->A, D->B, etc.
> 
> That would be A->D, B->E, C->D, A->E, B->D, C->E and so on. I
> originally gave machine 2 three locators but figured it would make a
> better example if the locators were mismatched.
> 
> 
>> Over time, machine 1 sees a roughly even spread of lost packets
>> because because the acks don't come back when sent on the E->B path.
>> Since the spread is even, no path gets a preference over the other.
>>
>> At the same time, machine 2 notices that packets sent E->B never come
>> back and it notices that packets acked with the E->B link are
>> retransmitted by the source. It depreferences the EB pair so that
>> they're used less often until they reach some threshold and are cut
>> entirely due to being non-operable.
>>
>> Granted the system has a mildly stochastic nature, but it should
>> converge on the "best" working paths for any given communication
>> session.
>>
>> Of course if E->B is less broken and actually returns an unreachable
>> message the algorithm can shortcut and eliminate that path from use
>> immediately.
> 
>