Stream Control Transmission Protocol (SCTP) is a transport-layer protocol, serving in a similar role to the popular protocols TCP and UDP. It is standardized by IETF in RFC 4960.
SCTP provides some of the same service features of both: it is message-oriented like UDP and ensures reliable, in-sequence transport of messages with congestion control like TCP; it differs from these in providing multi-homing and redundant paths to increase resilience and reliability.
https://en.m.wikipedia.org/wiki/Stream_Control_Transmission_...
Edit: fix typo
Obviously, there are exceptions and you can have both streams and known-length content served over HTTP, but I still think streams over SCTP would have been a better choice than datagrams over TCP.
Edit: Also firewalls that filter out anything but TCP (or TCP + UDP, or TCP + UDP + ICMP) can die a fiery death. The fact that basically any new protocol has to tunnel over UDP instead of properly over IP is heresy and bullshit.
1) There is a field MTU in the IP header.
2) The sending host sets MTU := <MTU of the outgoing link>.
3) Any router on the path sets MTU := min(MTU, <MTU of outgoing link>).
4) The receiving host instantly knows the MTU of the path (the MTU field).
This seems like a much simpler, more reliable and more efficient system than PMTU discovery: no problems with firewalls blocking ICMP, no additional delay due to too large packets.
All at the cost of a single minimization operation at the router. The IP header checksum would need to be recalculated, but, due to the simplicity of the IP checksum, fixing it up changing one word is trivial (AFAIK).
I can imagine a potential issue with adding that to IPv6 when it was designed, that IPv6 should be tunnelable over IPv4 which doesn't have this, but still surely there are ways to deal with that.
Also, dedicating even two bytes in each and every IP packet just for MTU would be quite an overhead, especially since IP already has a mechanism (fragmentation) to deal with this.
This is true but I don't see how that is relevant here. My proposal does not change this. It's just about a field in the header and logic required at routers for updating it.
> Each subsequent packet sent between same endpoint can take different path with different PMTU.
That is true for the existing Internet as is, and is also an issue for PMTU discovery. It's not a new issue caused by this proposed design. It can be addressed in the similar way as it is now (I don't know exactly how it is...).
I don't buy the "quite an overhead" argument - it wasn't a problem to extend the IP header from 20 to 40 bytes going from IPv4 to IPv6. For this you'd need just 2 bytes.
There may also be a different but similar approach: have routers truncate (not drop) too large packets but leave the "packet length" field intact. Upon seeign a truncated packet the receiver would know that the packet is too large, and what the path MTU is (the size of the packet).
IPv6 packet header is significantly simplified when compared to IPv4. Although it is twice as large, almost all non-essential fields have been moved to extension headers. I guess it wouldn't hurt too much if there was an optional header with PMTU updated by all supporting routers along the path, especially when there is no checksum field in IPv6 packet.
In v6 there is no fragmentation anymore if I remember correctly, it would just get dropped (or maybe trigger an ICMP error, I don't know).
You could use options, but you still have to deal with broken firewall hardware.
You don't need this in every packet, you only need it in one packet (or once every few minutes). Instead of putting a field in every packet that only <1% of them need, we could create an out of band message to notify when the MTU has been exceeded. And the endpoint that needs to know that is the sender, so that's who you would send it to. Which is what they did.
That works perfectly well, the problem is that many misconfigured firewalls drop the ICMP messages. No one predicted that level of incompetence when the protocols were being designed.
I'm sure there are details that would have to be ironed out. Like what happens if the MTU of the path is then reduced (does this result in dropped packets and leads to a stall? - possible fix is to say the packets are truncated instead allowing the MTU to be propagated).
EDIT: Well, if the MTU in the other direction also decreased, we might have an issue, as the stack might decline to interpret the transport layer payload. Don't know how to solve that right now, but probably there are ways. Maybe some mechanism to allow the protocol layer (TCP) to still successfully validate the TCP checksum knowing that the packet was truncated.
I don't know how v6 was designed exactly, but if it's open, did you search back to see if someone proposed this and why it was rejected (if ever proposed)?
[0] http://conferences.sigcomm.org/imc/2011/docs/p181.pdf
[1] https://www2.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-...
https://wiki.freebsd.org/SummerOfCode2016/TCP-IP-RegressionT...
So to me it sounds like you just want to write a UDP protocol with some extra reliability. Most applications built on top of UDP do this already, but maybe there would be some value in a general library for UDP protocols.
I don't think so. On the receiver's side, the application doesn't need to know packets at all -- it just deals with a stream of bytes where some portions may be dropped or come out of order. The packet nature would be abstracted away. On the sender's side, packets only become relevant if the application wants to get optimal behavior with respect to the packet size (in which case it would be already doing its own manual UDP). If it just wants "good enough" generic behavior (which is what TCP has always been providing for everyone) then it can again ignore the packet nature and just treat the connection as a stream where some portions may be dropped and/or reordered.
Think about how useful this could be in so many common situations: when you're trying to download some file, for example, you don't need TCP -- because it doesn't matter if the data comes out of order. You just need to make sure you get everything eventually and that the data isn't corrupted. You don't want UDP either, which would require you to implement your own feedback/congestion control/etc. mechanisms from scratch. There's a nice sweet spot in the middle waiting to be hit. And it baffles me that it still doesn't seem to have been done.
It's used for WebRTC data channels:
https://www.html5rocks.com/en/tutorials/webrtc/datachannels/
Also worth checking out enet:
By not being designed to handle streams, UDP can sidestep a ton of issues.
So, the adjustable parameters in your protocol should be a lot, methinks.
There's three different retry strategies in TCP I know of. Like 7 or 8 popular congestion control algorithms, many types of queuing disciplines.
Some fundamental differences like the SYN/ACK handshake, SYN cookies, state table conntrack, packet sequencing stuff. Tcp slow start and windows. Tons of optional features.
The TCP stack of any newer OS is monstrous. A lot of kernel devs would cringe at the thought of adding more to that :)
I don't think that's the same kind of retry as the one I'm talking about. In TCP, no matter what the retry algorithm is, TCP has to deliver data in order. Whereas I'm talking about being able to tune how much you're willing to retry receiving the data until you give up and return it to the caller out of order. It's not about the algorithm so much as the resulting semantics.
My fear here is that you lose those guarantees once you allow configuration of the connection using your one protocol. ...And while sure, you can have that negotiated when the connection is set up, there would be nothing from preventing one side of the connection from fudging/cheating/outright lying. I wouldn't put that past people at all -- especially networking hardware vendors.
Any attempt you would implement to mitigate this just adds unnecessary data transmission overhead.
Huh? With UDP, the thing missing is a guarantee about how the connection is going to behave (assuming you call it a "connection" in the first place). I'm just talking about interpolating between guarantees and no guarantees.
Not so - with UDP I know that the endpoint won't discard packets that arrive out of order, and won't bother me with retrans requests for stale packets that didn't arrive... different priorities, different kinds of 'guarantees'
http://www.bth.se/com/mscee.nsf/attachments/mukb08_Thesis_Re...
building a protocol on top of UDP has historically been a good compromise. The base protocol is simple enough that it doesn't add much overhead to just build whatever you want on top of it. The ubiquitous support for UDP leaves little reason to roll your own.
The only bad downside to both UDP and TCP is that support for unsolicited connections is usually completely broken for end users since the 90s because of the vast adoption of NAT.
If they are doing NAT, they need to understand the transport layer protocol too.
And this is why we need IPv6.
/s
One of the interesting ones is to have every socket call to bind() without an explicit address allocate a random new IPv6 address. Then there is nothing to correlate the address with because every other socket on that machine has a different address.
You do need to define some "trustworthy" machines which get to see a constant (and known) address - or troubleshooting and debugging the network will be horrible. Also, I suspect some protocols (pop-before-smtp, stun) won't like it. They are unneeded in IPv6, but I suspect there exist ones that will fail horribly with this scheme.
In enterprise environments you could get the addresses from a DHCPv6 server which would then be able to map them back to machines. Or register them in the internal reverse DNS.
> Also, I suspect some protocols (pop-before-smtp, stun) won't like it. They are unneeded in IPv6, but I suspect there exist ones that will fail horribly with this scheme.
It would be less trouble to make addresses per-process rather than per-socket, but also somewhat less effective. A good middle ground might be to default to per-process and have a socket option to make it per-socket. That way e.g. Firefox could still have different addresses for connections to different servers.
A process could then choose which sockets use the same address as one another by calling getsockname() on an existing socket and then using that address to bind() another one.
Firewalls do, but it's possible to put the firewall in the endpoint.
Generally speaking, security devices need to support a lot more than just raw IP to do their jobs these days. At this point the installed base of firewalls alone would make implementing a new protocol like this across the internet effectively impossible.
Add in devices that do NAT, ALGs, load balancers, and other intelligent network devices and you can see why everyone that needs something like this on a real network uses UDP with stuff built on top.
It's too bad but at the same time running custom protocols on UDP really isn't too bad as far as CPU/Space overhead. It's pretty much become a universal encapsulation protocol for everything else
That's why those should get scrapped and replaced by dumb pipes. They only cause pain. I thought this lesson had been learned decades ago already.
I agree with you; though, I do wonder what will start happening at the routingnlayer of the internet to start dealing with these massive DDOS attacks that have been going on.
The biggest reason is that traditional NAT requires a separate conntrack state table. The big players (looking at you google, cloudflare) have solved this by using consistent hashing to load balance traffic but they're not sharing the code.
Google made a show of good faith recently by releasing a comprehensive paper on how their load balancer works, hoping the open source movement will pull a mapreduce/hbase and built a replica off of it but this far it isn't happening.
I think google gave up considering that they've seen how much money cloudflare makes selling the software as a service and now offer their own servers as DDoS protection.
I've been looking deeply into the matter. The truth is that open load balancers relying on the kernel are not going to work. Someone needs to get started on this, and I've considered doing so myself but it's a big undertaking for a single dev
[1] https://static.googleusercontent.com/media/research.google.c...
It's something that absolutely should be picked up and run with
I haven't looked at the code, but I imagine this would be relatively trivial to change if it is written at all sanely, right? Hardly sounds like a big thing to focus on.
Look at all the foot dragging with IPV6, and that's just an updated version of an existing protocol with massive support behind it
int listen_sock = socket(AF_INET, SOCK_DCCP, IPPROTO_DCCP);
If the OS doesn't support DCCP, then, tough luck...
If you remove "DCCP", "socket", and "type" from this headline, you are left with the universal format of a clickbait headline. If DCCP is truly a networking protocol worthy of the attention of the readers of Hacker News, just imagine how much more convincing of an argument there is to be made, based on its true underlying merits. I am perfectly willing to admit that this protocol may in fact be the best networking protocol by every objective measure available. But the fact that someone who knows more than I do about it, believes that their best opening bid in the negotiation that is convincing me of its merits, is a logical fallacy, inevitably leads me to question their entire premise.
If we can all agree that we don't like clickbait headlines in the general sense, then lets be even more vigilant against clickbait headlines that we are the least able to resist.
Edit: added a couple of missing words that were lost on the way from my brain to my fingers.
While I will admit that I did choose the title to be alluring, I do not think it is provocative, sensationalising or misleading in any way to be called clickbait.
Causation is like a perfect happy path through a software application, whereas any single correlation is a singular path through the application. Out of all possible paths through a software application, vast amounts of those paths result in failure, whereas far fewer paths result in success. We can all agree that performing tests on the happy path is important, but inferior to 100% code coverage, if our eventual goal is to harden our software against failure, both malicious and accidental.
The point I'm driving at is not that we should all become perfectly logical at every moment of our life, because the logical, bitter end of that is a world of sociopaths, completely devoid of any humanity, emotion, love, and all of the other things we can all agree are just as important as logic and reason.
My point is that if we are in complete consensus about clickbait titles, with respect to subjects that we don't find interesting, yet are willing and able to defend clickbait titles when they happen to bait us in to clicking them, that is the perfect marriage of our ignorance and arrogance. If we can point out to less informed management that their desire to reduce friction along the happy path of software is _precisely_ what increases attack surfaces, why can't we see that same flaw in ourselves? The answer is not to rush to one extreme to prevent the other. The answer is to strike balance.
I don't mean to call you out as the most extreme example of my point, nor do I mean to show that this is the first time I am seeing this. But I see this optimization toward 8 lane highways we construct from content creators towards our brains, for the purposes of being entertained while exerting the least amount of effort necessary, as a giant imbalance toward the content creators, at the expense of the content consumers.
My central point is that clickbait titles beat people over the head with what they were already predisposed to hear, which is bad. But my continued explanation in and of itself is the same insidious tactic.
Thanks for your patience with me, and with all of us.
Leaving aside the merits of your claim concerning the title containing a logical fallacy, HN's 80-character limit on the length of a submission's title can, at times, make this approach a bit difficult in practice.