i'm constructing a pipenet application and one of the biggest headaches is traffic padding. end-to-end traffic padding is too costly, so its outta the question. another similar problem to traffic padding is connection establishment and tear-down. w/o significant enough traffic, you can't really do it in mixmaster style. my idea for link padding (between adjacent nodes/switches) started w/ the idea of a bi-di 14400 bps, to make hosting an anonnet server (my pipenet implementation) palatable to the person who cuts the checks for bandwidth (such as myself). 14400 connections would force people to open many connections for, say, looking at a website (multiple connections for the page, images, etc). this would help w/ the mixmaster connection requests, and allow hosters to better control bandwidth. then i thought about allowing multiple "virtual links" to be connected at the end node/receiver, so that traffic could be spread across them. aside from latancy and ordering issues, this could really up the through-put. just recently (after reading an attack from wei dai on the freedom network), i was thinking how these multiple "channels" could be used to guard against the active attacks that are exposed absent end-to-end padding. if the traffic did not fill all the channels, and traffic was randomly distributed across the channels, wouldn't/couldn't this make attacks on the system much more difficult. especially if different nodes randomly sent null packets to the receiver, and vice-versa (to reduce possible collusion between the end node and a middle node). assuming the end node is trustworthy (more so than the set of nodes used), then an attack on any link between the beginning and end gives far less information to be used in tracing a route, because its is unknown what the distributiuon of traffic is. it makes things more hairy, having to deal w/ out of order packets (each single channel is still mac'd and sequenced properly). but, it widens the security margins, no? this design seems to me to be a win-win. it makes high[er]-throughput, beneficial link padding possible, while (per the low per-channel bandwidth cost) giving the host of a pipenet/anonnet node more control (finer granularity) over traffic usage thus making hosting less costly. any comments, suggestions? i'm really looking for somebody to tell me whether allowing multiple channels like this exposts the design to more attacks than have been pointer out w/ link padding schemes. otherwise, at the very least it makes the application more practical.