Summary

  • Public evidence consistently names the operator Rocket Internet Service rather than AP Rocket Internet Service. Its website, ISPAB entry, BTRC listings and APNIC registrations converge on the same people, domain, Gazipur address and network resources, supporting identity continuity rather than a separate company.
  • AS149478 was active on 10 July 2026, originating one IPv6 /48 and 512 IPv4 addresses through an aggregate /23 and two component /24s. RIPEstat saw the routes at every responding IPv4 and IPv6 collector peer, while the prefixes had valid route-origin authorizations.
  • Current route observations expose one immediate external neighbour, Summit Communications AS58717. That is strong evidence of upstream concentration in the visible routing system, but it cannot reveal private backup circuits, two physical links to the same carrier, shared ducts, inactive failover or the location of the handoff.
  • Rocket advertises service across Gacha and Gazipur, 24-hour support and a 99% uptime goal. Those are operator claims. The public material does not establish access-plant ownership, pole or duct rights, route maps, backup runtime, spare stock, crew coverage, measured uptime or restoration performance.
  • The regulatory picture needs correction rather than concealment. A December 2024 BTRC list showed a Rocket licence for Turag valid to July 2028, but the separate Gacha licence used by the company's Gazipur-facing ISPAB entry had a September 2024 validity date. A current Gacha e-licence would settle the issue; without it, the network can be described as operating but its exact authorized service-area basis remains unverified.

The public name leads to a real Gazipur network

The word "AP" in the entity label is not how the operator presents itself. The company website calls the business Rocket Internet Service, as do the Bangladesh regulator's licence list, the Internet Service Providers Association of Bangladesh and the Asia-Pacific internet-number registry. That consistency matters because "Rocket Internet" can otherwise lead to unrelated businesses in other countries. Here the domain, contact details, manager, address and autonomous system create a specific Bangladeshi identity.

APNIC's registration for AS149478 names ROCKET-AS-AP, gives Bangladesh as the country and identifies Rocket Internet Service as the registrant. The -AP suffix belongs to the registry-style network name; it is not evidence that "AP" forms part of the trading name. APNIC's contact card places the network administrator at 549 Nurjahan Villa, Choydana, Gacha, Gazipur. Rocket's about page and contact page point to the same locality and use the same domain-based addresses found in network records. ISPAB's member entry associates Rocket Internet Service with Md. Shaheen Miah, the same phone number carried in APNIC's registrant contact and the same Gacha address.

The company is not merely a web page attached to an idle allocation. APNIC registered AS149478 on 28 January 2023 and the address resources three days later. Route collectors first saw one of Rocket's prefixes on 31 January 2023. On the article date, the autonomous system was still announcing all of its registered address space, and APNIC contact validation and route-object timestamps had been refreshed in 2026. Rocket's site exposed current packages, payment instructions, coverage claims, a named team and a live service-registration form. These signals collectively support an operating network edge and a customer-facing business.

They do not establish every commercial or legal detail. The company site says it is licensed by BTRC and makes a broad claim about providing fibre, wireless and satellite-based communication across the country. The coverage page is narrower: it says Rocket is spread across Gazipur city and asks prospective customers to check availability. The home page is narrower still in its main headline, describing a high-speed provider in Gacha, Gazipur. The narrow claims align better with the public licence category than the nationwide language.

The distinction is not pedantic. An operator can hold an autonomous system and portable addresses while serving a compact set of neighbourhoods. It can lease most of the physical plant that carries those addresses. It can maintain active routes even when a portion of the retail access network is down. Identity, routing activity, licensed scope and installed customer access are four different facts. Rocket has strong evidence for the first two, conflicting evidence for the third and limited public evidence for the fourth.

This is why the appropriate operating-status conclusion is a qualified one. Rocket Internet Service appears to be a live small ISP centred on Gazipur with a routable network, customer payment channels and named operational staff. There is no defensible basis to call it global, to treat its claimed nationwide reach as built coverage, or to describe its physical access system as resilient. The most revealing public document is not a marketing page. It is the tariff that defines what happens to the monthly bill when continuity fails.

The bill is also a resilience contract

Bangladesh's 18 February 2026 fixed-broadband tariff applies a national schedule to public and private ISPs. It sets maximum shared monthly prices of Tk400 for at least 5 Mbps, Tk500 for 10 Mbps, Tk800 for 20 Mbps and Tk1,200 for 40 Mbps, with a maximum contention ratio of 1:8. More important for infrastructure analysis, it preserves the service-grade framework and a graduated penalty for continuous loss of service on packages priced at Tk500 or more.

Under that framework, a customer whose connection remains continuously down for five days pays half the monthly bill. At ten days, the payment falls to one quarter. At fifteen days, no monthly payment is due for that month. The thresholds are severe: a short evening slowdown or a two-hour fibre cut does not trigger them. But they translate prolonged failure into a commercial consequence. Uptime is not only an engineering target; after enough continuous downtime, it changes revenue collected from the affected connection.

The same tariff describes three service grades. Grade A calls for multiple upstream redundancy, a point of presence with multiple underground NTTN paths, continuous network operations and care, 99% uptime, and a maximum four-hour restore target for an Upazila ISP when measured from logical detection and when the failure is not dependent on an IIG or NTTN. Grades B and C reduce the redundancy wording and permit lower uptime and longer restoration windows. The document does not identify which grade Rocket has contracted to deliver, so it would be wrong to convert the Grade A row into a verified four-hour Rocket guarantee.

It does show what the regulator regards as the ingredients of a stronger service: upstream choice, transport-path diversity, continuous care and repair time.

Those ingredients map directly onto the unknowns in Rocket's public profile. There is one visible upstream, not multiple observed upstream autonomous systems. PeeringDB lists several facilities, but does not list an active public exchange connection. No topology shows two independent NTTN paths to a Rocket point of presence. The company says its operations centre is staffed around the clock and promises 99% uptime, but it publishes no measurement period, availability history, fault clock, outage archive or restoration statistics. The tariff therefore supplies an assessment standard without proving Rocket's result against it.

Rocket's package page illustrates another gap between a posted offer and current regulation. On 10 July it still displayed the older price ladder associated with the operator-specific April 2022 tariff approval: Tk500 for 5 Mbps, Tk800 for 10 Mbps, Tk1,200 for 20 Mbps and Tk2,400 for 50 Mbps, among other intermediate tiers. The 2026 national order is newer and explicitly replaces an earlier national instruction. A page view cannot establish what customers are actually charged, whether a newer approval exists, or whether the site is simply stale. It does establish that a prospective customer cannot safely treat the posted package matrix as reconciled with the latest national schedule.

The payment channel looks active. Rocket's payment page offers mobile-wallet numbers and describes monthly dues, while the home page asks subscribers to pay bills on time. That is useful operating evidence but not a financial disclosure. There are no subscriber totals, revenue figures, audited accounts, churn data or bad-debt rates. The tariff nevertheless reveals the economics of interruption. A prolonged outage threatens both customer utility and the amount collectible on affected plans. At the small-ISP scale, the same incident can also impose overtime, replacement-equipment and third-party transport costs while revenue is reduced.

This creates an asymmetry. The customer buys one service and sees one bill. The operator may depend on several parties: a local cable owner, an NTTN transport provider, an upstream carrier, a building owner, an electricity supplier and field technicians. The tariff's restore-time language even recognizes dependencies on IIG and NTTN providers. Commercial accountability stays with the retail ISP, while the physical cause and repair authority may sit elsewhere. Understanding Rocket therefore requires following the customer session from the premises to AS149478 and then out through the one neighbour visible in public routing.

AS149478 proves a routed edge, not an access map

Rocket controls a small but meaningful set of internet-number resources. APNIC's IPv4 record assigns 103.77.218.0 through 103.77.219.255 to Rocket Internet Service as active portable space. A /23 contains 512 IPv4 addresses. The IPv6 record assigns the operator an active portable /48, a block large enough for extensive internal subnetting even though raw IPv6 address counts are not a useful measure of company size.

On 10 July 2026, RIPEstat's routing-status view saw three IPv4 announcements covering 512 addresses and one IPv6 /48. It reported all 327 responding IPv4 collector peers and all 321 responding IPv6 peers seeing the network. The announced-prefixes view showed the aggregate 103.77.218.0/23, both component /24s and 2001:df1:e340::/48 throughout the preceding two-week observation window. That is strong evidence of a stable, globally visible origin on the assessment date.

The arrangement of three IPv4 announcements over only 512 unique addresses needs care. Rocket announces the covering /23 and the two more-specific /24s inside it. Adding 512, 256 and 256 would double-count the same space; the unique allocation remains 512 addresses. More-specific announcements can support traffic engineering or routing policy, but their existence does not prove two physical paths. All three can travel through the same carrier and the same cable.

The prefixes also had valid route-origin authorizations. RIPEstat's RPKI check for the aggregate identifies AS149478 as the authorized origin, and separate valid authorizations cover the two /24s and the IPv6 /48. This is a positive routing-hygiene signal. Networks performing origin validation can reject an accidental or unauthorized origin that conflicts with those authorizations.

RPKI does not certify uptime, path integrity or physical ownership. A valid route can pass through one upstream. A correctly authorized prefix can still be unreachable after a power failure. Origin validation does not tell a customer whether the last drop is fibre or radio, whether a cabinet has batteries, whether an upstream invoice was paid, or whether a crew has the correct optical module. It protects one part of the control plane: who is authorized to originate the route.

The address count is similarly easy to misuse. Five hundred and twelve public IPv4 addresses do not equal 512 customers. Carrier-grade address translation can place many households behind a smaller public pool, while business services, routers, servers and point-to-point links can consume multiple addresses. IPv6 makes the mismatch even larger: a /48 represents abundant subnet space, not an astronomical subscriber base. Address resources show administrative independence and the ability to operate a distinct routing policy. They do not disclose installed access ports, active accounts or peak throughput.

Independent traffic observations add modest support. Cloudflare Radar's AS149478 page classifies the autonomous system under Rocket's network name, and IPinfo's current profile describes a Bangladesh consumer ISP with a pronounced local day-and-night usage rhythm. IPinfo also reported recent ping responses inside both the IPv4 and IPv6 blocks. These are useful signs that end-user or access-network traffic is present. They remain estimates and sampled measurements, not Rocket subscriber or service-level records.

The conclusion at the routed edge is stronger than the conclusion at the street. Rocket has current routes, portable resources, IPv6, valid origin authorizations and observed traffic. Public routing can establish that packets for Rocket's addresses are entering the global table. It cannot reveal how a household in Gacha reaches the border router. That hidden segment is where poles, building entries, splices, powered switches, wireless links and field access determine whether the route is usable.

One observed neighbour concentrates the visible exit

RIPEstat's ASN-neighbours view reported one unique adjacent autonomous system on 10 July: AS58717. APNIC's AS58717 record identifies that network as Summit Communications. BGP.tools independently classifies Rocket as an active access network and shows Summit as its upstream. Collector paths to the aggregate place AS58717 immediately before AS149478 across hundreds of observations.

This is the central resilience fact, but its wording must remain precise. Public BGP exposes one immediate external routing neighbour. It does not prove there is only one cable, one port or one commercial service. Rocket could have two circuits to Summit, protected transport, a cold standby that does not normally announce its routes, or a private backup service invisible to route collectors. It could also have multiple logical sessions that all traverse one duct, one building entrance or one powered chassis. BGP sees autonomous-system policy, not civil engineering.

The distinction between provider diversity and path diversity is decisive. Two links to Summit can protect against a failed optic or router port while leaving common exposure to Summit's control plane or transport network. A link to a second carrier can still share the same NTTN fibre corridor. Two routes leaving a site in opposite directions can converge at the next junction. Meaningful resilience asks at least five questions: are there separate upstream organizations, separate handoff devices, separate building entries, separate long-haul corridors and separate power domains?

The public evidence answers only the first, and its answer is one visible upstream organization.

Rocket's PeeringDB profile describes an open peering policy, mostly inbound traffic and support for IPv4 and IPv6. The profile lists two IPv4 and two IPv6 prefixes, does not disclose a traffic band, and says multiple locations are not required. It also lists presence at six Dhaka facilities and one Mumbai facility, including BDIX Main Node, BTCL IX Dhaka, ISPAB-NIX-DC, Earth Telecommunication, MetroNet Bangladesh and Bangladesh Submarine Cables in Dhaka, plus Bharti Airtel in Mumbai.

Those facility entries are self-reported presence claims. They are not the same thing as exchange ports or active sessions. PeeringDB's API returned no netixlan entry for AS149478, meaning the database disclosed no public exchange connection with an IP address and port speed. A network may use private interconnection at a facility, may omit an exchange connection from PeeringDB, or may have stale facility declarations. The correct reading is that Rocket claims a surprisingly broad set of interconnection locations but does not publish the exchange attachments needed to verify direct peering.

That discrepancy is analytically useful. The company says it wants to peer with content providers and improve streaming performance. Facility presence could make private interconnection or caches possible. But no public evidence shows a Google, Akamai, Meta or Netflix cache inside Rocket's network, no exchange port is listed, and observed external routes still present Summit as the single immediate neighbour. A facility list therefore cannot be converted into diversified transit or local-content capacity.

For a customer, upstream concentration matters in two ways. First, reachability can fail even when the local drop remains intact. A household router may synchronize and a local gateway may respond, yet the internet is unavailable because the path from AS149478 through AS58717 is down. Second, congestion can collect at the same boundary. Evening demand for video, software updates and cloud services can fill an upstream or transport segment even when the advertised access rate remains technically available on the last mile.

The evidence needed to upgrade this assessment is concrete: a second upstream ASN visible in route collectors or a documented failover test; port and circuit identifiers that demonstrate independent handoffs; route maps showing separate NTTN corridors; exchange records with current IPs and speeds; and utilization evidence that distinguishes installed ports from busy-hour headroom. Until then, Rocket's routed edge is active and well authorized, but the visible exit remains concentrated through Summit.

Gazipur service claims meet a stale licence boundary

Rocket's commercial centre of gravity is Gacha, within Gazipur. Its home page calls it a provider in Gacha, the coverage page says it is spread across Gazipur city, and APNIC places the registrant contact in Choydana near National University. The public material does not provide a neighbourhood-by-neighbourhood service map, customer count or list of active points of presence. A broad coverage sentence is not proof that access plant reaches every road in Gazipur.

The licensing evidence is more complicated. BTRC's Upazila and Thana ISP list dated 18 December 2024 contains two consecutive Rocket Internet Service entries. One is for Turag, at an Uttara West address, under licence 14.32.0000.702.46.577.19.192, with validity to 21 July 2028. The other is for Gacha, at Choydana near National University, under licence 14.32.0000.702.47.113.19.320, with validity to 28 September 2024 and the next renewal date one day later.

The Gacha licence number is the one displayed by ISPAB alongside the Gazipur address and Md. Shaheen Miah. ISPAB's page says the membership was valid only through 31 December 2024 and contains no listed point of presence. That does not prove the licence or membership was never renewed. The regulator moved toward electronic licensing in 2025, public lists can lag, and an association page can remain stale. It does mean the accessible evidence does not show a current Gacha authorization after September 2024.

The separate Turag licence should not be used as an automatic substitute. The BTRC ISP licensing guideline defines an Upazila or Thana licence around service in the named administrative area. Turag and Gacha are different named areas. A valid Turag row confirms that a business with Rocket's name had a current licence in the 2024 regulator list; it does not by itself authorize every Gazipur location marketed by the website.

Nor should the stale Gacha row be inflated into an accusation. Company identity across the two rows is not fully resolved in the list, which provides names and addresses but no ownership linkage. Public route activity and current web operations show that the network continued to function after the listed date. The responsible conclusion is an evidence gap: a current e-licence for Gacha, or a regulator record showing how the Turag licence relates to the Gazipur service, is required before the authorized footprint can be stated confidently.

This gap changes the metadata. "Global" is plainly unsupported. BTRC records, APNIC resources, traffic observations and the company site all point to Bangladesh. The correct broad category is an Asia-Pacific regional ISP, with Bangladesh as the region and Gacha/Gazipur as the advertised local focus. The word regional should describe scale, not confer proof of every location within a region.

The operating downgrade is therefore narrow rather than absolute. Rocket has a live autonomous system, routed addresses, a working site, payment instructions, active contacts and a named technical team. It can reasonably be described as operating. Its exact licence basis for the Gacha-facing offer, number of active customer areas and physical extent cannot be verified from current public material. That uncertainty belongs in the article because service-area authority and access reach determine who can be affected by a failure.

The physical network begins where public routing ends

A Rocket customer does not connect directly to AS149478 as an abstract number. The session begins with powered equipment in a home, shop, office or institution. It crosses a drop cable or wireless hop, reaches neighbourhood distribution, passes through aggregation equipment and transport, and only then reaches the border where Rocket exchanges routes with Summit. Any one of those layers can remove usable service while the global BGP announcement remains visible.

Rocket's about page says it offers broadband and private data communication over fibre-optic, wireless and satellite technologies. That language describes a capability set, not an installed topology. The package page looks like a shared fixed-broadband offer, and third-party network classifications call AS149478 a cable, DSL or fixed-line ISP. None identifies whether a particular Gacha customer uses passive optical fibre, active Ethernet, fixed wireless or a reseller's cable. The article therefore cannot responsibly depict Rocket as a pure fibre operator or claim ownership of a tower network.

Each access technology creates a different failure chain. In a passive optical network, unpowered splitters can reduce field power requirements, but the customer's optical terminal and the operator's optical line terminal still need electricity. An active Ethernet design may place powered switches in buildings or street cabinets. Fixed wireless avoids some trenching and pole routes but adds line-of-sight, radio alignment, mast access and power at both ends. Satellite service introduces terminal visibility and satellite capacity but the website provides no evidence of active satellite customer links.

Ownership may be divided at every layer. Rocket may own the customer drop and electronics while leasing poles, ducts, dark fibre, a wavelength or managed transport. A local cable operator may handle the final connection. An NTTN may control the long-haul route. Summit may deliver upstream service at a shared facility. The customer's support call reaches Rocket, but a repair can require another owner's permission, dispatch and spare equipment. The BTRC tariff's explicit reference to IIG and NTTN dependencies recognizes this operational boundary.

The absence of a route map prevents claims about ring topology. A fibre ring can restore service after one cut if traffic can reverse around an intact alternate segment and if switching, power and capacity are ready. A diagram shaped like a ring is not enough: both sides can share a bridge, road crossing or duct. Rocket publishes no ring, no protected route, no pole inventory and no tower list. Its PeeringDB facility declarations describe possible interconnection locations, not the access path from Gazipur.

Power is similarly opaque. The company claims continuous support and a redundant backbone but gives no battery duration, generator coverage, fuel plan, maintenance schedule or site list. A customer's own router and optical terminal can fail during a household outage even when Rocket's network is powered. A neighbourhood switch can fail while the border router remains online. A long outage can exhaust batteries at multiple sites at different times, producing a rolling loss of customers rather than one clean network-wide event.

Installed equipment is not the same as usable resilience. A spare fibre pair has no value if both ends are not connected and tested. A backup router does not restore a cut cable. A generator does not help if the technician cannot reach the site or fuel is unavailable. A second upstream contract does not protect against a shared corridor. Public evidence verifies none of these protections for Rocket. That does not mean they are absent; it means the reader should not pay an evidentiary premium for them.

Capacity is constrained by the busiest shared layer

Rocket's retail offers are shared services. Both the old operator-specific approval and the current national tariff use a maximum contention ratio of 1:8. Contention is not automatically a defect: consumer broadband is priced on the expectation that customers do not all use their maximum rate continuously. The economic question is whether aggregate demand, especially at busy hours, stays below usable capacity at each shared layer.

The public data do not disclose Rocket's port speeds or traffic volume. PeeringDB leaves the traffic field blank. The two IPv4 prefixes and two IPv6 prefixes reported there are routing quantities, not capacity. A 100 Gbps port can carry a nearly empty network, while a 1 Gbps handoff can constrain many plans whose advertised speeds sum to far more than 1 Gbps. There is no utilization graph, peak-hour percentile, subscriber count or split ratio from which to calculate headroom.

The national market gives scale but not a Rocket denominator. BTRC's internet subscriber series reported 14.77 million ISP and PSTN subscriptions in February 2026. The regulator's penetration table put fixed-broadband penetration at 8.48% in April 2026. Neither table breaks out Rocket, and national subscription growth says nothing about congestion on one Gazipur aggregation link.

At Rocket's scale, public IPv4 scarcity may encourage address sharing. That can stretch a 512-address pool across many customers, but it introduces stateful translation equipment and can complicate inbound connections, logging and troubleshooting. Rocket's active IPv6 /48 is therefore a positive sign: it gives the operator room to assign globally unique IPv6 subnets. The route's visibility proves that the IPv6 block is announced, not that every retail plan, home router or application receives working IPv6.

Local content can change upstream economics. If popular video or software content is exchanged locally or served from an on-net cache, fewer bits cross paid transit and latency may improve. Rocket's PeeringDB note expresses a desire to peer with content providers and mentions major content platforms. Desire is not deployment. With no listed exchange connection, cache inventory or traffic split, the analysis cannot assume that popular content bypasses Summit.

This makes congestion one of the plausible failure modes even when nothing is physically broken. A customer may receive acceptable speed in the morning and degraded performance in the evening because the access splitter, wireless sector, aggregation link or upstream handoff is busy. Route collectors will continue to show the prefixes as healthy. The company can still claim the network is up. Only time-based speed, latency, loss and utilization measurements can locate the bottleneck.

Retail price regulation tightens the economics. Lower maximum prices can improve affordability, but an ISP still has to fund upstream capacity, transport leases, customer equipment, support staff, spares, power and repairs. A small operator has fewer customers over which to spread a second route or a fully staffed night shift. That is the core of regional-ISP economics here: local service can be socially important while redundancy remains expensive relative to the revenue base.

The answer is not to infer poor performance from small scale. Small operators can know their streets, dispatch quickly and build strong local relationships. Nor should a blank traffic field be treated as congestion evidence. The correct test is whether Rocket can show busy-hour headroom, separate capacity on a failover route, measured packet loss and latency, and a plan for growth. Until such evidence appears, installed route visibility should not be mistaken for usable customer capacity.

Six failure paths define who loses service

The first failure path is the customer premises. A failed router, power adapter, optical terminal or indoor cable can disconnect one account while the rest of Rocket remains healthy. Remote support may diagnose the problem, but replacement still requires a compatible spare and a visit or customer pickup. The company advertises 24-hour phone and online support; it does not publish equipment models, replacement terms or first-visit resolution rates.

The second is the local access plant. An aerial drop can be damaged, a splice can admit water, a pole route can be disturbed and a building switch can lose power. A fibre cut may affect one customer, one building, a neighbourhood or an entire aggregation branch depending on where it occurs. Without an access map, the size of Rocket's shared failure domains is unknown. A small number of upstream routes says nothing about how many homes share the same local segment.

The third is powered aggregation. Optical line terminals, Ethernet switches, wireless radios and routers need reliable power and environmental control. Battery backup can bridge a short interruption, but runtime falls with age, temperature and load. A generator can extend service but adds fuel, maintenance and safe-operating requirements. Rocket claims a redundant backbone and 99% uptime; no public inventory shows which sites have batteries or generation, how long they last or whether customer equipment is covered.

The fourth is transport between Gazipur and the upstream handoff. Even if Rocket has access equipment in Gacha and facility presence in Dhaka, the connecting NTTN path can fail. A leased service may be protected inside the provider's network, or two circuits may share the same fibre. The PeeringDB facility list does not reveal the route from Gacha, and BGP does not expose it. This is the physical gap most likely to be hidden behind a single logical adjacency.

The fifth is upstream loss. The public routing view shows Summit immediately outside Rocket. If the Rocket-Summit session, handoff or relevant Summit path fails and there is no effective backup, customers can lose wider reachability while local equipment remains powered. A cold backup might exist without appearing in normal observations, but no failover record demonstrates one. This is why a second visible upstream would materially improve confidence even though it would not, by itself, prove path diversity.

The sixth is congestion. Capacity exhaustion can affect all customers behind a shared link without withdrawing a route. Video buffers, interactive calls degrade and cloud applications time out, while simple pings may continue. Congestion can occur at the radio sector, optical uplink, aggregation switch, long-haul transport, upstream port or content path. Rocket publishes no measurements that distinguish them.

Who is affected depends on where the fault sits. A premises failure affects one account. A local branch failure affects customers behind that branch. An aggregation or power failure can remove a larger service area. A transport or upstream failure can affect most users whose traffic relies on that exit. A configuration error at the border can affect both IPv4 and IPv6, while an address-family-specific problem may leave one working. The fully visible routes suggest the border was healthy on 10 July, not that every customer path was.

Impact also depends on customer mix, which Rocket does not disclose. The site markets home broadband and private data communication. A household may lose work, education, payments and communication. A small shop may lose cloud applications or digital transactions. A business private-data customer may have contractual backup. No public customer list supports claims about hospitals, government agencies or other critical users, so those should not be invented.

The bill penalty addresses only unusually long continuous outages. It does not compensate every interruption, measure repeated shorter failures or guarantee that a complaint clock was opened correctly. The 2026 tariff requires ISPs to resolve complaints quickly and retain complaint and resolution information for at least six months. For customers, a ticket number and exact start time are therefore practical evidence. For the operator, disciplined incident records are the basis for seeing whether the same splice, power site or upstream boundary repeatedly fails.

Field repair is the hidden capacity

Rocket's team page names a managing director, a senior network engineer, two senior technicians and several sales and marketing managers. This is stronger evidence of local human presence than a generic support promise. It is still a website roster, not a current staffing return. The page provides no shift pattern, employment dates, certification, vehicle count, contractor arrangements or geographic coverage.

Two named technicians can be enough for routine work in a compact network and limited public evidence during simultaneous incidents. The relevant number is not total names but concurrent repair capacity: how many qualified people are on call, how quickly they can travel, whether they can access third-party facilities, and whether one person can remain at the operations desk while another works in the field. A 24-hour phone line does not necessarily mean a fibre splicer is available at every hour.

Spare stock is another form of repair capacity. Different failures require different items: optical transceivers, patch leads, splitters, customer terminals, power supplies, batteries, wireless radios, routers and lengths of suitable cable. A spare held at the Gazipur office may shorten restoration; a part sourced after failure can extend it. Public material lists no spares policy or maintenance depot. The tariff's restore targets make this omission important, because detection is only the beginning of repair.

Restoration also crosses ownership boundaries. Rocket staff may detect loss at an upstream or NTTN handoff but lack authority to repair the underlying fibre. They can open a ticket, provide measurements and escalate. The third party controls dispatch and priority. A credible resilience plan therefore needs named escalation paths, agreed response times and evidence that failover works while the physical fault is repaired. The tariff explicitly excludes external IIG or NTTN dependency from its stated logical restore-time calculation, highlighting the difference between diagnosis and control.

The company's claim of a round-the-clock network operations centre is plausible but unmeasured. A useful public service report would disclose incidents by cause, median and high-percentile restore times, the share resolved remotely, repeat faults and whether bill adjustments were applied. Even a small operator can publish this without exposing sensitive topology. In its absence, the 99% uptime statement should be treated as a target or marketing claim, not an independently demonstrated result.

Local support labour can nevertheless be a genuine advantage. A team based in the service area may recognize streets, customers and recurring cable routes faster than a national call centre. The website's shared contacts across management, support and network records suggest a closely held operation with short communication paths. The trade-off is key-person risk: if a small number of people hold configuration knowledge, supplier contacts and field access, absence or overload can slow recovery.

Evidence that would settle the labour question is operational rather than promotional. Rocket could show staffed hours by function, on-call coverage, average acknowledgement and restore times, spare locations, escalation agreements and post-incident summaries. Customers can contribute verifiable ticket histories and outage timestamps, but isolated reviews cannot establish network-wide performance. Until a consistent record exists, field repair should be treated as necessary and locally present, with depth unproven.

What a stronger resilience case would show

The first upgrade would be a current, service-area-specific licence record. A Gacha e-licence or a regulator explanation linking the valid Turag authorization to the advertised Gazipur service would resolve the most important legal-scope uncertainty. An updated ISPAB record would help but would not replace the regulator. Coverage should then be shown as active service areas, not a nationwide capability statement.

The second would be verifiable route diversity. A second upstream appearing in normal observations or a documented failover announcement would reduce visible dependence on Summit. It should be accompanied by physical-path evidence: different building entries, transport providers or corridors, separate border equipment and independent power. A second BGP session over the same fibre would not meet that test.

The third would be a current interconnection disclosure. PeeringDB facility entries should be reconciled with actual exchange or private-network connections. Port speeds, operational status and dates would make the difference between aspirational presence and usable interconnection. Content caches should be named only where the operator or content provider confirms deployment.

The fourth would be service measurement. Busy-hour throughput, latency, loss and jitter by access area would reveal usable capacity. Uptime and restoration statistics would test the 99% claim. Separate IPv4 and IPv6 measurements would show whether the announced IPv6 block reaches customers. Incident causes would reveal whether the binding constraint is access cuts, power, transport, upstream service, configuration or congestion.

The fifth would be a recovery inventory. Backup runtime at aggregation and border sites, generator coverage, spare optics and customer devices, technician availability and third-party escalation targets determine how quickly service returns. These details need not expose exact sensitive locations. Aggregated evidence can show preparedness without publishing a map that creates security risk.

Until those disclosures exist, the most defensible assessment is medium-strength network evidence with weak physical-resilience evidence. Rocket is not a hypothetical provider: AS149478 is active, its routes are broadly visible, its origin authorizations are valid, its contacts have been maintained, and its customer-facing surfaces remain live. But public records show only one immediate upstream, no verified exchange port, no access topology and no measured repair performance. The Gacha licence trail also needs a current confirmation.

That conclusion explains why Rocket's bill is an infrastructure document. Bangladesh's tariff fixes prices, names redundancy expectations and reduces payment after prolonged continuous failure. Every number on that bill depends on equipment and labour the customer cannot see: the powered terminal, the local cable or radio, the aggregation site, the NTTN route, the Summit handoff and the people who restore them. Rocket can demonstrate a live routed edge. The unanswered question is whether the physical and human chain behind it can prevent a fault from lasting long enough to change what the customer owes.