Earlier, Dow Street wrote: % I have also been thinking about this type of path hash % - a (compressed) record of the router interfaces the packet % has traversed. If the receiver saw the hash value change % over the course of a session, it would be a hint that the path changed: % % - restart congestion control / RTT measurements? % - off-path attacker spoofing packets? % - persistent oscillation of hash values -> load-balanced links % somewhere (watch for packet re-ordering) % % It may make sense to have the hash done per router *interface*. % If we're making host changes, something like this is probably worth % considering as a part of the information exchange between network % and endpoint.
Maybe I'm confused, but the above seems to be suggesting that: 1) a hash computation needs to be done for each packet that goes through each router interface along the path from origin to destination 2) the hash result is placed somewhere in the packet being forwarded, meaning that each packet would be modified in transit by each router If I am not confused, each of those ideas would seem to increase the per-packet cost of packet forwarding in a very significant way. Absent new custom hardware to support that function, it isn't obvious how it could be done at line-rate for interesting interface speeds (e.g. 1 Gbps or higher speed).f Did I miss something here ? Yours, Ran [EMAIL PROTECTED] -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
