Opened 6 years ago

Last modified 6 years ago

#1548 new defect

Use of Reachability flag is misleading

Reported by: DjJeshk Owned by: zzz
Priority: maintenance Milestone: undecided
Component: www/i2p Version: 0.9.19
Keywords: Cc:
Parent Tickets: Sensitive: no


I2P version: 0.9.19-9
Java version: Oracle Corporation 1.8.0_45 (Java™ SE Runtime Environment 1.8.0_45-b14)
Wrapper version: 3.5.25
Server version: 8.1.16.v20140903
Servlet version: Jasper JSP 2.1 Engine
Platform: Windows 7 x86 6.1
Processor: Core 2 (45nm) (core2)
Jbigi: Locally optimized library jbigi-windows-core2.dll loaded from file
Encoding: Cp1257
Charset: windows-1257

We should deprecate reachability flag because it negatively impacts network performance if not all transports are open for router. It blocks partial firewalled routers to participate in tunnels. One transport only enabled routers are able to participate normally. Partially firewalled routers should not be blocked to participate in tunnels.

If we remove reachable flag only if all transports are firewalled then it still does not guarantees that two reachable routers are reachable to each other if we talk about NTCP only and UDP only reachable routers. So there is no need to trust reachability at all.

Routerinfos has enough information to determine if specific transport is disabled or enabled with introducers, or enabled without firewall. So ignore reachability flag and leave it for backward compatibility.

Issue caused by this: #1458


Change History (4)

comment:1 Changed 6 years ago by zzz

Component: router/transportwww/i2p
Priority: majormaintenance

The above is more a proposed solution to #1458 and #1541 than a separate issue, and it's based on a simplistic view of how a router determines reachability.

Things have evolved over the years, but there's both the "R" and "U" flags, or neither could be there, and yes IPv6 also… so our code is a lot more complex than you're assuming in the OP. If you think we just look for "R" and that's it, then that's a misunderstanding.

I'm sure our docs have not stayed current with all the changes, so perhaps what you're getting at is we need to update our docs. Any changes to flags will have to be coordinated with i2pd also. Java isn't the only router. Removing 'R' and 'U' from the netdb may confuse i2pd or old Java routers. We still put stuff in the netdb for compatibility with 5-year-old routers, just in case.

Anyway, I see this ticket as either documentation issue, or a proposed solution to other tickets. Please clarify if I am misunderstanding. Moving to www as a minor doc issue for now, since we already have other tickets on the IPv6 issue.

comment:2 Changed 6 years ago by somewon

It seems to make more sense to me not to eliminate the R and U flags but add a greater range of flags to solve this problem. What if it were something like an octal code that could accurately represent reachable/non-reachable states for all four of: IPv6 NTCP, IPv6 SSU, IPv4 NTCP, IPv4 SSU. If I'm not mistaken, that's only four bits of information - not exactly a great challenge to represent or transmit.

comment:3 Changed 6 years ago by DjJeshk

Outdated documentation is biggest issue in I2P network. And missing search functionality in official web page is issue too. Proposed way how to deal with this: push change in documentation after each code submission and move to wikipedia like website to make possible documentation changing more easier (edit documentation directly in browser) and let users search with one click. Russian speaking wiki http://rus.i2p is good example.

Real question: why R flag is removed if some transports (not all) are firewalled? I assume that R flag will remain as boolean value to be compatible with old routers so it must be documented more clearly and not misused. Absence of R flag prevents router to participate as inbound gateway so it should be set if at least one transport is fully working.

Another question: does tunnel builder takes care to let inbound gateway to be accessible from most transports?
Issue: If we put UDP only router as inbound gateway, NTCP only routers will not reach them. This reduces availability if one transport is only available to destination.

Related question: Does router takes care of transport data which is disabled for it? I am almost sure that UDP only router prevents NTCP only routers to participate in their tunnels and same applies to ipv4 and ipv6 only routers. Ipv6 only routers might be forced to use only ipv6 enabled routers in their tunnels. Little trust to unknown should help.

Related question about reachability: Do we expect region specific reachability? If we select two routers for traffic routing which are well accessible for us, but not for each other, we run in poor performance because we do not know how each ISP or other network related services are throttling traffic for around the world.

Notable example is users behind Great Firewall of China. Lot of factors are limiting them to join to our side.
Most of them have only ipv6 connectivity so they are limited only to ipv6 peers.
We do not take care about Chinese internet connection speed and lack of trust to other peers for all around the world that might be blocked from their side play the role of limited connectivity.
They lack lastest fixes for operating system so compatibility with XP and old Java versins should be remained if we want china users.

To get more precise information, routers should leak information about ip address reachability. Site like stats.i2p might analyze it and construct real situation of network health.

comment:4 Changed 6 years ago by zzz

re: real question: being fixed in #1458

re: OBEP/IBGW compatibility, see #1188

re: region-specifc, (and also related to #1188), I2P is a "full-mesh' network, meaning it assumes that everybody can connect to everybody. When this is not true, things break. Fixing this is a huge job, and falls under the general topic of "restricted routes', see http://zzz.i2p/topics/114

Note: See TracTickets for help on using tickets.