undefined | Better HN

0 pointsEvanAnderson9mo ago0 comments

> What are you imagining as the implementation?

I haven't thought about it hard enough to be doing anything besides spouting bullshit. It's one of those lazy "I don't like what we've got but I can't say what we should have" kind of complaints.

The way SCTP handles multi-homing and failover with the verification tag is what I guess I'm thinking of. I'm a little enamored with SCTP, admittedly, and I'd rather we were using it than TCP.

If I were going back in time, without the 20+ years of real-world experience that went into SCTP, I'd propose something simple like having the initiator and receiver each put a (32-bit?) identifier into a couple of session tracking header fields (initiator on SYN, receiver on SYN/ACK). When an endpoint roamed to a new IP address they'd send a zero-byte ACK from the new IP address to the opposing end. The opposing end would provisionally update their IP binding and ACK back to the new IP address. They would continue to send to both IP addresses until they received an ACK from the new IP address, at which point the old IP address would be discarded.

I can already see, doing "improvisational piano" state machine design here, that there are issues with this design. Like I said, spouting bullshit... >smile<

0 comments

mindslight9mo ago

Ah, I got you. I hear session layer and think something a bit more ingrained in the core network, but I can see how that would work. Relying on a secret 32 bit nonce chaffs me a bit, but there is a similar problem with guessing sequence numbers (modulo source IP spoofing, which has been greatly clamped down on). And there could always have been some extensions adding cryptographic security, timeout the roaming functionality if lots of wrong packets trying to guess session identifiers were received, etc.

Developing on that last bit I threw out, especially since you're lamenting the non-adoption of SCTP. With the retrospective from NAT, it feels like it would have been good to factor out the "port" part of TCP/UDP and put it in the IP header instead ("flow ID" or something). Then define (saddr, daddr, protocol#, flowID) as a "flow tuple" for middle boxes to operate on. TCP/UDP/SCTP could then define and present those bits as port numbers.

This could even be size-negative if you threw out that whole fragmentation thing in favor of completely punting it to a higher layer instead.

(I realize this goes against the end to end principle and strict layer separation, but the fact is that despite the goal, middle boxes are mucking with packets, and when that mechanism cannot be prevented, facilitating it would be better for maintaining flexibility)

j / k navigate · click thread line to collapse