Demo Data from EDBT 2026 / reviewers in the wild / expert
Asaf Baron
dblp:28/7891
· DBLP profile ↗
1ranked-venue papers
1as first author
0since 2021 · last 2009
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Computer networks · 1 · 1 first-author
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Computer networks
1 paper |
Network performance modeling · 77% Routing and switching · 23% |
Topics — the 2 heaviest of 2, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Network performance modeling
stability analysis |
0.1 | 1 | 2009 | The Capacity Allocation Paradox · INFOCOM 2009 |
Routing and switching
scheduling algorithms |
0.0 | 1 | 2009 | The Capacity Allocation Paradox · INFOCOM 2009 |
Methods — techniques the papers use, named apart from their topics
stability analysis · 0.1fluid and packet-switched network modeling · 0.1
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2009 | The Capacity Allocation ParadoxabstractThe Capacity Allocation Paradox (CAP) destabilizes a stable small-buffer network when a link capacity is increased. CAP is demonstrated in a basic 2 times 1 network topology. We show that it applies to fluid, wormhole and packet-switched networks, and prove that it applies to various scheduling algorithms such as fixed-priority, round-robin and exhaustive round-robin. Their capacity regions are modeled and surprising phenomena are described. For instance, once increasing a link capacity destabilizes a stable network, increasing it further to infinity might never restore stability. Further, we exhibit networks with arbitrarily tight link-capacity stability regions, in which any small deviation from an optimal link capacity might make the network unstable. Finally, we suggest ways to mitigate CAP, e.g. by using GPS scheduling. Asaf Baron, Ran Ginosar, Isaac Keslassy |
INFOCOM | 1 |