Comment by tptacek | Hacker News Reader

Comment by tptacek | Hacker News Reader

I think TCP SYN segments have always been able to carry payloads; they're not delivered until the 3WH completes.

A fun set of trivia questions involves inconsistent retransmission: in out-of-order delivery, with some data buffered --- IP fragments or TCP segments --- what happens when the packet that allows reassembly to proceed (a) overlaps data already sent and (b) that overlapping data isn't the same as what was already buffered? (When we wrote the IDS paper, Vern Paxson told us he'd been observing this happening in the wild, which blows my mind).

Another fun set of interview questions pertains to how you'd design the fastest possible "traceroute" program. You can do better than parallelizing/pipelining. :)

I used to like asking people what the utility of discard, chargen, and echo were.

My first reaction to the "fastest traceroute" question would be, is this a trick question? This is because many routers rate-limit the number of ICMP packets they forward. Causing a lot of ICMP replies could easily exceed this limit and result in missing hops. This requires being deliberately slow. A lot of the early Internet measurement studies had to deal with these problems, though ideally a single traceroute is less likely to trigger this behavior.

However, your hint indicates that there's something other than inducing a number of TTL exceeded packets. Can't verify as I'm on mobile, but are you thinking of the TCP Record Route option?

I'd think sending multiple packets (parallelism) with varying TTLs (1,2,3..n) without waiting for responses from each hops to increment the TTL, would probably give us faster traceroute. n being the number of hops you "expect" the destination subnet to be.

TTL's given by the Fibonacci sequence?

Not really. You'd want every routers in the path to reply to see all the hops in between. This would be unreliable though, since the ICMP TTL exceeded message might come in out-of-order to the sender, who is sending these probes(with varying TTLs) simultaneously. But assuming, you could somehow figure out the hop-order, this IMO is faster than current traceroute implementation.

Reply on news.ycombinator.com