Re: Netrom: Quality issue

[Cathryn Mataga <cathryn@junglevision.com>]

On 7/8/2013 12:48 AM, Thomas Osterried wrote:
>
> Nice idea, this outgoing filter.
>
> But I see problems with worst_qual filters being different for each interface. Even more, if we'll have two (in and outbound).
>
> Example:
>
>
> A <-> B <-> INET-Host <-> C-in-inet
>
>                            ^ learned: INET-HOST, A, B
>   ^    ^
> learned:
> only INET-Host
>
>
> User on C-inet tries to connect A.
> But A has not learned C-inet by B's broadcast and thus has no route to answer.


Yeah, I see what you're saying.  Really we do have this problem anyway, 
though.  I suppose.  If a TNC sets its worst_quality to be high and 
someone from that node connects in, there's no way to reply.    When 
worst_quality on a TNC is set high, the internet machine sends a giant 
list of nodes over 1200 baud, and then the TNC would throw them all 
away.  If we could match these then the IP connected machine could avoid 
putting all this extra stuff on the 1200 baud RF channel.

Maybe could be fixed with some kind of scheme that could set quality 
based on traffic going through -- but the node broadcast would be too 
late for a connect, so at least the first connect wouldn't get through.


> => In the inet cloud there would be many nodes which are not reachable.
>     Where's the benefit?
>

Just that the massive node list on 1200 baud TNC is a poor user experience.


> Even worse, if you like to make IP:
> you cannot manually connect from node to node; you depend on a working bi-directional l3 route.
>