On 6/2/16, Allen <allenpmd@gmail.com> wrote:

another alternative would be random packet sizes, ie, the packet size transmitted to the next hop would not be the same as the size received

What does this help / enable? Nodes are known to GPA's, there is no way to hide them. If GPA counting physical packets, over time period, bytes into a relay must equal bytes out, otherwise they're being dropped somewhere, which is inefficient... as opposed to temporarily reducing fill to cover wheat demand. There is up to %50 capacity loss with random sizes, requiring up to 2x higher packet / interrupt rates to compensate within the same pipe / cpu. And the code to do all the carving, queuing and reassembly of every single packet, more complex and costly than padding the last carrier packet of some layer. There is also to consider... - physical / logical paths and pathing - circuit, packet, label, or flow switching - what layers the fill is in (above, at, or below wheat), the layers managed at, and by who. Big challenge is figuring how the network self manages the fill system to dynamically make room for wheat demand wherever it is needed in the network. (That dynamic is also what makes the user apparent application performance roughly the same as non fill networks. Of course their NIC (or their configured anonymous network rate limit within that), is always saturated, but that's transparent to the application layer.) If that's all solved fill traffic might be a good defense to Global *Passive* Adversary, and even a fair one to a Global *Traffic Flow Perturbing Active* Adversary. (What evidence is there that Global Adversaries that are not partnered with Global Telecoms are able to, as opposed to simply listening, arbitrarily drop / inject / delay packets on the global backbones?) Designing something new, including fill, crypto, and anonymity... probably far harder than putting tor's basic design together was. On the other hand, there's now 15 more years of research, experience and components on hand to throw at it.