{"id":"e432fbd2-8579-4886-898f-5c60371db0d3","arxiv_id":"2502.00787","paper_version":1,"verdict":"REJECT","confidence":"HIGH","novelty_score":1.0,"correctness_risk":"high","formal_verification":"none","parameter_count":7,"one_line_summary":"A restatement of standard queueing theory for when a hypothetical ISP network becomes overloaded, with no real data or code.","lead":"This paper applies textbook queueing equations to a small ISP network and runs a toy simulation to estimate user counts that overload the network. It offers no new model and no validation against real traffic, so its practical value is unclear.","discovery_kind":"incremental","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The reported 30-user upgrade threshold contradicts the model's own equations: with B=100 Mbps, S=12000 bits, and 417 requests/second per user, Eq. (1) gives rho = 1 at N≈20, at which Eq. (3) makes queuing delay infinite.","rationale":"I read the paper in good faith as a queueing-theoretic modeling exercise intended to tell an ISP when to upgrade. The decisive problem is not merely that the traffic model is simplistic; it is that the headline numerical result, the 30-user threshold, is inconsistent with the model's own equations. Even granting every stated assumption, the M/M/1 traffic intensity reaches 1 at about 20 users, and Equation (3) then declares queuing delay infinite. The paper reports finite delays through 30 users, so the figures cannot have been generated by the equations as written. This is a correctness risk in the strongest sense: the central claim does not follow from the proposed model. The reader's rationale already noted the rho=1 at 20 users contradiction, but their 'weakest assumption' field emphasized the realism of constant-rate traffic rather than this internal inconsistency. I agree with the reject verdict because the threshold prediction is the paper's main contribution, and it is unsupported by both the mathematics and any external validation. The upgraded 1 Gbps scenario reduces rho, but that is trivial and does not repair the baseline threshold error. With no code, data, or formal verification, and with the internal contradiction, the contribution does not meet the bar for a research result.","tokens_in":7390,"tokens_out":3980,"duration_ms":42638,"concrete_test":"Recompute rho from Equations (1)-(2) at N=20 and N=30 with the paper's constants: rho(20) = 1.0008 and rho(30) = 1.5012. Then reimplement Equations (3)-(7) for total delay and print the values at N=20 and N=30. If the reproduced Figure 2 is finite at N=30, the simulation must be using a different queueing formula than Equation (3); if it follows Equation (3), the curve diverges at N≈20 and the reported 30-user threshold is contradicted. Either way, asking the authors to reconcile this single point settles whether the central threshold claim originates from their stated model.","verdict_should_be":"REJECT","load_bearing_attack":"The central claim is that the model identifies an upgrade threshold around 30 users. This does not follow from the model's own mathematics. Equation (1) defines traffic intensity as rho = S * lambda_total / B, with Equation (2) giving lambda_total = N * 417. Using the stated constants S=12000 bits, B=100 Mbps, and per-user rate 417 req/s, rho(N) = N * 12000 * 417 / 100,000,000 = 0.05004*N. Thus rho reaches 1 at N≈20 (at N=20, rho = 1.0008). Equation (3) explicitly sets queuing delay to rho/(1-rho) for rho < 1 and to infinity for rho >= 1. So the model predicts saturation and infinite queuing delay at about 20 users, not at 30. The reported Figure 2 curve, which shows finite delays up to 30 users and a peak of 2 seconds, cannot be the output of Equations (1)-(3). If the simulation instead used a finite queue of 1000 packets, then Equation (3) is not the model being evaluated, and any threshold obtained would need to be derived from the M/M/1/K formula, which has a different saturation criterion. This internal inconsistency is independent of whether the constant 417 req/s assumption or the M/M/1 abstraction is realistic. Since the paper's headline contribution is precisely the threshold value, the numerical conclusion is not supported by the presented model.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes an analytical, M/M/1-style queueing model for ISP network upgrades. It defines traffic intensity as rho = S*lambda_total/B, queuing delay as rho/(1-rho), and several related delay, utilization, throughput, and packet-drop formulas. Using a baseline bandwidth of 100 Mbps, a packet size of 1500 bytes, and a per-user request rate of 417 requests/second, the paper claims that simulations identify an upgrade threshold around 30 users, after which delay escalates sharply and throughput collapses, and that upgrading to 1 Gbps eliminates these bottlenecks. The paper frames its contribution as a mathematical tool that ISPs can use to predict when infrastructure upgrades are needed.","tokens_in":7722,"tokens_out":3688,"duration_ms":35712,"significance":"The topic is practically relevant, and the paper's explicit equations and parameter choices at least make the modeling assumptions checkable. If the reported threshold were a genuine, validated prediction, the approach could be useful for capacity planning. However, the paper provides no empirical validation, no fitted parameters, no comparison against measured ISP traffic, and no reproducibility artifacts such as code or data. More importantly, the reported numerical results are internally inconsistent with the model's own equations: the stated constants make rho reach 1 at about 20 users, not 30, and the reported server utilization reaches 100% at 15 users despite the stated server capacity of 50 users. These load-bearing inconsistencies mean the central claim of identifying upgrade thresholds is not supported by the presented model.","major_comments":[{"comment":"With B = 100 Mbps, S = 12000 bits, and lambda_user = 417 requests/second, Eq. (2) gives lambda_total = 417N and Eq. (1) gives rho = 0.05004N. Equation (3) then yields infinite queuing delay for N >= 20. The text of Section IV states that delay remains negligible below 30 users, rises sharply only after 30, and reaches a finite peak of 2 seconds. This is not the output of the presented equations. If the simulation instead used a finite queue of 1000 packets, then the model evaluated is M/M/1/K, not Eq. (3), and the paper does not provide the M/M/1/K delay formula or any derivation of the claimed threshold. The headline numerical result is therefore unsupported by the model as stated.","section":"Section III-D, Eqs. (1)-(3) and Section IV"},{"comment":"The paper reports that server utilization reaches 100% at around 15 users in both the original and upgraded networks, but Section III-C states that the maximum server capacity is 50 users. Equation (8) defines server utilization abstractly as a ratio of arrival-related and service-related quantities but does not connect it to the stated 50-user capacity or to N. If utilization is N/50, it reaches 100% only at N = 50; if utilization equals rho from Eq. (1), it reaches 100% near N = 20. The reported curve at N = 15 is inconsistent with both interpretations, which makes the 'server capacity' parameter non-functional and undermines the interpretation of the upgrade's effect.","section":"Section IV, Figures 5 and 9; Section III-C"},{"comment":"The claimed upgrade threshold is not predicted by the model but is forced by the choice of constants. Since rho = 0.05004N, any threshold in N corresponds directly to the chosen B, S, and lambda_user, and the upgraded scenario is simply the arithmetic of reducing rho by a factor of 10. The paper provides no measured traffic traces, no external benchmark, no sensitivity analysis, and no goodness-of-fit statistics, so there is no evidence that the threshold is meaningful for real ISP networks. This circularity, together with the internal contradiction noted above, means the central claim of predictive upgrade timing is not established.","section":"Section III-D and Section IV"}],"minor_comments":[{"comment":"The manuscript retains the IEEE template placeholder 'REPLACETHISLINEWITHYOURPAPERIDENTIFICATIONNUMBER' and the boilerplate first-footnote text, indicating that the submission was not prepared for review.","section":"Title page"},{"comment":"The in-text figure references are inconsistent with the figure captions: the text says 'Throughput, as illustrated in Figure 8' and 'Queue drops ... as evidenced in Figure 8', but Figure 8 is labeled 'Queue Drops' and the preceding figure, Figure 7, is labeled 'Throughput'. The references should be corrected to match the figure numbering.","section":"Section IV"},{"comment":"Equations (10)-(12) are typeset with broken notation, such as '??? = ??? (0, min (...))', and Eq. (8) uses undefined symbols for arrival rate and service rate. All variables should be defined consistently with Eqs. (1)-(7).","section":"Section III-D"},{"comment":"The literature review cites references [17]-[20], which concern energy harvesting, smart metering, and industrial IoT security; these do not appear relevant to network upgrade modeling and should be replaced with appropriate prior work or removed.","section":"Section II"},{"comment":"The abstract states that 'simulations prove the model's usefulness', but the paper provides no confidence intervals, goodness-of-fit measures, or comparison against alternative models; this claim should be softened or supported.","section":"Abstract"}],"recommendation":"reject","confidential_remarks":"This manuscript appears to be an incomplete draft, with the template placeholder still present and the results section contradicting the model's own equations. The mismatch between the stated constants and the reported 30-user threshold is severe enough that a revision would require redoing the modeling, simulation, and validation from scratch. I would not recommend major revision because the core numerical claims are internally inconsistent, and the paper does not currently offer a reproducible or validated methodology that could be patched locally."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nYou should know this paper's central claim—that the model pinpoints an upgrade threshold around 30 users—is contradicted by the paper's own equations. With B=100 Mbps, S=12000 bits, and 417 requests/second per user, Eqs. (1)-(2) give rho = 0.05004*N. That reaches 1 at N≈20, and Eq. (3) makes queuing delay infinite at rho≥1. The reported Figure 2 shows finite delays below 30 users and a 2-second peak, which cannot be the output of these equations. The same arithmetic puts the M/M/1 delay at roughly 3 seconds at 15 users, so \"negligible below 30\" is off by a factor of about 15 in the wrong direction.\n\nWhat the paper does well: it clearly states its assumptions, writes down standard queueing formulas, and the intent—giving ISPs a simple rule for when to upgrade—is reasonable. The literature review is broad, even if none of the ML/DTN methods are used. The Python simulation is mentioned but no code or data is provided, so the results are not independently checkable.\n\nThe soft spots are more serious. The internal inconsistency is not cosmetic; it collapses the headline result. The model itself is textbook M/M/1, and the 'upgrade threshold' is just the stability condition rho<1. Nothing new is derived. The assumed constant per-user rate of 417 requests/second is a strong simplification with no real-traffic justification. Server utilization reaching 100% at 15 users while the stated server capacity is 50 users makes no sense as written. The queue limit of 1000 packets suggests an M/M/1/K model, but the paper never gives that formula.\n\nIf the authors had used a finite-queue formula, calibrated the parameters with actual ISP data, and given their code, this could be a modest case study. As it stands, the numerical conclusions are unsupported by the presented mathematics. I don't think this deserves referee time; a desk reject is appropriate. If you send it out, the referee's first check—plug the constants into Eq. (1)—kills the paper.","headline":"The paper's central upgrade-threshold claim is contradicted by its own equations: with the stated constants, rho hits 1 at N≈20, so the reported 30-user threshold and 2-second delays cannot come from the presented model.","tokens_in":8285,"tokens_out":2987,"would_cite":false,"duration_ms":30121,"reading_group":"no","serious_thinker":"no","would_accept_peer_review":false},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A queueing model predicts an ISP link's breaking point at about 30 users, and how upgrading past it removes the collapse.","keywords":["mathematical modeling","network performance","network upgrades","bandwidth utilization","scalability analysis","queueing theory","throughput","delay prediction"],"falsifier":"Run a controlled test on a real 100 Mbps link with up to 50 users streaming Full HD video and record average delay as users are added one at a time. If the sharp delay escalation does not occur near 30 users, or if delay stays flat because bursty traffic multiplexes, the model's threshold claim fails. Directly measuring per-user request rates would also test the 417 requests/second assumption.","tokens_in":7131,"feed_emoji":"📶","tokens_out":9168,"duration_ms":84350,"temperature":0.7,"pith_summary":"The paper builds a mathematical model of a small ISP network — a web server, a router, two switches, and end users — and uses classic queueing equations to compute delay, throughput, utilization, and packet drops as the number of users grows. Its central finding is a threshold: on a 100 Mbps link, delay stays negligible below about 30 users and then jumps toward 2 seconds per user, while throughput collapses. After simulated upgrades (1 Gbps bandwidth, larger queues), delay holds near 0.02 seconds at 50 users and throughput grows past 400 Mbps. The paper offers these equations to ISPs as a way to predict when extra investment is needed instead of waiting for service to degrade.","feed_headline":"A queueing model finds an ISP link's 30-user saturation point","feed_subtitle":"The 100 Mbps link is fine until about 30 users; the paper's equations say what upgrade keeps it smooth.","key_machinery":"The load-bearing object is the classic M/M/1 single-server queueing relation — one server, memoryless arrivals and service times — expressed in the paper as traffic intensity $\\rho = S\\lambda_{\\text{total}}/B$ with queueing delay $\\rho/(1-\\rho)$ for $\\rho<1$. This single formula makes delay grow without bound as the arrival rate approaches bandwidth, so the sharp delay spike at roughly 30 users is simply the point where $\\rho$ approaches 1. The paper wraps this core in supporting equations for transmission delay $S/B$, propagation delay $L/v$, processing delay, server utilization, throughput, and packet drops, but the upgrade threshold itself comes from the $\\rho/(1-\\rho)$ blow-up.","core_discovery":"The paper's central claim is that the network's behavior is governed by traffic intensity $\\rho = S\\lambda_{\\text{total}}/B$, where $S$ is packet size, $\\lambda_{\\text{total}}$ is the arrival rate from $N$ users, and $B$ is bandwidth, with queueing delay given by $\\rho/(1-\\rho)$ when $\\rho<1$ and infinite otherwise. Simulating these equations for the assumed workload — each user sends 417 requests per second, a 5 Mbps Full HD stream — shows that as $N$ approaches 30 on a 100 Mbps link, the queue saturates, delay escalates sharply to 2 seconds per user, queue drops reach the 1000-packet limit, and throughput collapses. In the upgraded network, increasing bandwidth to 1 Gbps and scaling the queue removes packet drops and keeps delay flat at about 0.02 seconds while throughput climbs linearly past 400 Mbps at 50 users. The paper interprets these results as evidence that the model can identify upgrade thresholds and guide ISP investment decisions.","pith_inferences":["Feeding real, bursty traffic traces into the same equations would likely shift or soften the 30-user cliff, because aggregation of many streams smooths the load the queue sees.","The model could be inverted to solve for the bandwidth needed to hold delay under a given target at a target subscriber count, turning a threshold detector into a capacity planner.","The sharp threshold is tied to the constant 5 Mbps per-user assumption; with variable-rate video codecs, the saturation point would vary with content, so the 30-user number is illustrative rather than universal."],"forward_implications":["An ISP could plug its own link speed, packet size, per-user demand, and server capacity into these equations to get a numeric user limit before buying equipment.","Raising the link from 100 Mbps to 1 Gbps and scaling the queue is predicted to eliminate packet drops and keep delay near 0.02 seconds for at least 50 users.","Server utilization reaches 100% at around 15 users in both configurations, so server capacity, not link bandwidth, becomes the first bottleneck after an upgrade.","A quality target such as delay under 100 ms for real-time video can be inserted into the model to produce a concrete, application-specific upgrade trigger."],"supporting_citations":[],"fun_headline_variants":["ISP math: 30 users max on 100 Mbps, 1 Gbps fixes it","Queueing math: 100 Mbps dies at 30 users; 1 Gbps thrives","Bandwidth fix: model says 30 users max on 100 Mbps","30-user limit on 100 Mbps links, says queueing model","Upgrade trigger: 30 users on 100 Mbps, use 1 Gbps math"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The prediction rests on the assumption that every user steadily sends 417 requests per second (a fixed 5 Mbps Full HD stream), so the queue sees a constant load; if real subscriber traffic is bursty or time-varying, the 30-user boundary may not hold.","fun_headline_variants_meta":{"raw":{"variants":["ISP math: 30 users max on 100 Mbps, 1 Gbps fixes it","Queueing math: 100 Mbps dies at 30 users; 1 Gbps thrives","Bandwidth fix: model says 30 users max on 100 Mbps","30-user limit on 100 Mbps links, says queueing model","Upgrade trigger: 30 users on 100 Mbps, use 1 Gbps math"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.00073,"raw_usage":{"total_tokens":3177,"prompt_tokens":762,"completion_tokens":2415,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":378,"completion_tokens_details":{"reasoning_tokens":2308}},"tokens_in":378,"tokens_out":2415,"duration_ms":14450,"temperature":1.0,"reasoning_tokens":2308,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-09T17:42:01.734040+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run a controlled test on a real 100 Mbps link with up to 50 users streaming Full HD video and record average delay as users are added one at a time. If the sharp delay escalation does not occur near 30 users, or if delay stays flat because bursty traffic multiplexes, the model's threshold claim fails. Directly measuring per-user request rates would also test the 417 requests/second assumption.","supporting_citations":[],"review_version":1}