i've decided that the current level of abstraction in the anonymous network demands user-defined message lengths (there is a lower level that achieves the anonymity guarantees which does actual pouzin datagrams i.e. fixed-size) but i now have to determine how chunks of a message are linked across the given route (it uses source routing)
Discussion
Loading...
torrents offer an interesting model but i'm still not entirely sure how to navigate this. i would like to say no SIR you must send standard-size datagrams but the establishment of a route (onion routed but Worse) is heavy enough that i would prefer not to do this.
i believe what i would like to do here actually is not terribly difficult it's to associate a tag (non-sequential—the network does not know how to arrange your slices together) to a datagram and then to use the tag to distinguish fragments of a message. it's very important that it not be sequential (ideally random) so that the network is not able to force a replay attack (in fact the protocol involves a mechanism to determine which component of the network is failing to propagate datagrams so that it can be routed around—the way everyone pretends the internet works)
that's slightly more complex than the beautiful architecture i had before but it is not unreasonable at all (in fact it's correct) to assume the network failing to propagate an item is an exceptional event and it can't really lie and just tell you it didn't get it because of the state machine at each hop
totally just realized this is exactly the right thing to do because the bidirectional notifications can be more efficiently merged if they belong to the same variable-size message
funny name https://en.wikipedia.org/wiki/Bufferbloat it is intended to explain the nondeterminism in the internet so it needs to be a meme to distract from the poor design of the internet
POUZIN WOULD NEVER https://en.wikipedia.org/wiki/Packet_loss
To avoid all of these problems, the Internet Protocol allows for routers to simply drop packets if the router or a network segment is too busy to deliver the data in a timely fashion.
~28 more replies (not shown)
i need to not start raging about how fucked this is. those are my packets i deserve to know where they went
Reliable protocols react to packet loss automatically, so when a person, such as a network administrator, needs to detect and diagnose packet loss, they typically use status information from network equipment or purpose-built tools.
this is incredibly misleading. the network is in the best position to know why the hell a packet was dropped. the application cannot make decisions without this information
They are in the best position to decide whether retransmission is necessary because the application sending the data should know whether a message is best retransmitted in whole or in part, whether or not the need to send the message has passed, and how to control the amount of bandwidth consumed to account for any congestion.
see this is not the kind of system i will allow to be built
In cases where quality of service is rate limiting a connection, e.g., using a leaky bucket algorithm, packets may be intentionally dropped in order to slow down specific services to ensure available bandwidth for other services marked with higher importance. For this reason, packet loss is not necessarily an indication of poor connection reliability or signs of a bandwidth bottleneck.
i have an answer for this which does not suck
this is actually kind of interesting https://en.wikipedia.org/wiki/Packet_loss_concealment i do think there is value to streaming applications where packet loss is acceptable. i'm not at all handling those yet though because latency guarantees are actively opposed to anonymity (think about why!)
this has a lot of similarities to what i'm doing. the utility of explicit reservation for anonymity is of course not considered but it's a pretty obvious extension https://en.wikipedia.org/wiki/Resource_Reservation_Protocol
i say "obvious" if only because it's mentioned out loud in the page on "QoS" (a particularly impressive example of IETF doubletalk) https://en.wikipedia.org/wiki/Quality_of_service#Limitations
Strong cryptography network protocols such as Secure Sockets Layer, I2P, and virtual private networks obscure the data transferred using them. As all electronic commerce on the Internet requires the use of such strong cryptography protocols, unilaterally downgrading the performance of encrypted traffic creates an unacceptable hazard for customers. Yet, encrypted traffic is otherwise unable to undergo deep packet inspection for QoS.
emphasis mine lmao
@hipsterelectron simply avoid IP and use ATM instead
@Lunaphied oh my GOD i am ABSOLUTELY not using IP lmao. i am thinking of something like ATM except with particularly strong guarantees on mixing of individual messages. it is a lot like onion routing except with explicit specification of intermediaries and allocation of resources when the virtual circuit is set up. this embedding of non-network trust makes it significantly more resistant to ddos as the creation of a circuit is a privileged action
@hipsterelectron isn't that MPLS
@Lunaphied the important part is that none of this relies upon the internet for routing
@Lunaphied oh. looked it up. yes i think MPLS would likely be more efficient than what i was doing
@Lunaphied i'm not sure yet how the ratcheting crypto i would like to perform at each hop would intersect with the label mechanism but this would definitely be the answer to OP in a nutshell. or at least one answer but it's good
@Lunaphied i'm very suspicious of every protocol provided to users of the internet but the ones used between different packet switching networks seem markedly higher quality
@Lunaphied MPLS has a great deal of similarity to this work thanks so much for the recommendation
@Lunaphied i do like the idea of laser communications between fixed points as an alternative to radio just because pew pew lasers but the first several useful versions of this are likely to be over some """reliable""" transport much like signal
@Lunaphied it is hard to describe how much QUIC is literally just the signal double ratchet it even has trevor perrin's name at the bottom. my concern about replay attacks was causing me to hesitate at supporting unreliable transport but i believe the mixing process may be able to improve this
@Lunaphied ok i think i can resolve the difficulty with unreliable transport now that you've pointed me to MPLS. the goal is to stop an active adversary from being able to reliably replay any atomic packet. my concern was that if the adversary induces enough noise, i can't get a packet over the first hop (or next, etc), and i can't determine any way around that but to replay.
the solution here is to recognize that if a hop states that a packet was dropped, it will (for reasons) have a sequence number assigned to it. that sequence number will be unique for each hop in the path, and only the final destination will know the "true" sequence number. the original source maintains a mapping of each per-hop sequence number translation, and upon a dropped notification will simply generate a new sequence number for the hop that dropped it, and reschedule the packet within the sequence to send (the "sequence" being some arbitrary set of chunks of the overall message).
it is understood when a drop is identified that the prior sequence number will be immediately invalidated. perhaps this requires a separate drop epoch per hop.
this notification mechanism (there's actually no "dropped" notif but rather a "hop" notif and a "dropped" query) is when in-order reliable delivery is necessary and intermediate nodes can't be allowed to introduce replay or other attacks (this is the guarantee the signal server provides for example)
this does lose one very nice quality: the intended recipient can now introduce replay attacks. but the hop protocol would clearly indicate this was occurring