search

ircv3 / ircv3-ideas

46 stars 3 forks source link

IRC over QUIC as a standard #28

Open TaaviE opened 5 years ago

TaaviE commented 5 years ago

I think it's worth starting to think about providing IRC over QUIC for these reasons:

What do you think? Should it maybe even be called IRCv4 :P?

grawity commented 5 years ago

Could in theory provide smooth connection migration when an IRC server goes down

IRC connections are somewhat stateful, so I'm not sure how this could help, or be any different from making a new TCP connection to the new server and asking it to "resume".

TaaviE commented 5 years ago

Could in theory provide smooth connection migration when an IRC server goes down

IRC connections are somewhat stateful, so I'm not sure how this could help, or be any different from making a new TCP connection to the new server and asking it to "resume".

Well, in theory that state could be migrated and then clients don't have to massively reconnect.

progval commented 5 years ago

Well, in theory that state could be migrated and then clients don't have to massively reconnect.

The same can be said of TCP.

TaaviE commented 5 years ago

Well, in theory that state could be migrated and then clients don't have to massively reconnect.

The same can be said of TCP.

Maybe with just TCP but with TCP+TLS it's way more complex than what QUIC offers though?

Herringway commented 5 years ago

IRC doesn't specify any transport. Second paragraph of RFC1459: The IRC protocol has been developed on systems using the TCP/IP network protocol, although there is no requirement that this remain the only sphere in which it operates.

So it already supports QUIC in theory.

grawity commented 5 years ago

Maybe with just TCP but with TCP+TLS it's way more complex than what QUIC offers though?

As far as I know, the transport is nearly irrelevant to the problem – most of the complexity is on the application layer anyway (getting the new server to recognize you, rebuild state, update routing for the nickname across the network). But do you have a specific mechanism in mind already? That is, what precisely does QUIC offer for this feature?

For everything else, QUIC would do the job, but it doesn't sound like it needs a specific "IRC over QUIC" profile, just a generic "QUIC as TLS substitute", same as SMTP or IMAP...

Has a lot of development power behind it from big corporations

Do any of them care about non-HTTP applications?

TaaviE commented 5 years ago

So it already supports QUIC in theory.

It does not forbid QUIC, supporting it is a whole another topic.

Do any of them care about non-HTTP applications?

There's an expired RFC draft for DNS-over-QUIC, so there's some interest, but QUIC is still really new so making a definite decision if they care or not is rather hard to say.

But do you have a specific mechanism in mind already? That is, what precisely does QUIC offer for this feature?

You can read more about what QUIC inherently tries to provide for migration in the RFC: https://tools.ietf.org/html/draft-ietf-quic-transport-17#section-9

grawity commented 5 years ago

You can read more about what QUIC inherently tries to provide for migration in the RFC:

It is all about migrating to new addresses for the same endpoint (or at least an endpoint that can exactly replicate the state at both QUIC and IRC levels), and currently seems to be limited by spec to clients only.

This would be very useful for roaming clients without having to use a bouncer, in place of the work-in-progress "RESUME" extension that's necessary for TCP. But I still don't see it helping with moving to a completely new endpoint – especially when the original one goes down unexpectedly and its state is lost (and I even suspect it would be simpler for the client to just reconnect and try resuming at IRC level.)

I think there should be documents about IRC's usage of e.g. transport layer roaming features (how they interact with bans and I:lines, whether the host change should be announced as a CHGHOST, etc.) or 0RTT usage and so on. But I feel like this should be a generic document and only using QUIC as an example, since many of those features aren't exclusive to it either.

SadieCat commented 5 years ago

I would be interested in seeing an experimental implementation of this once the IETF publish the QUIC RFC.

jwheare commented 5 years ago

Moved to the ideas repo.

nyovaya commented 5 years ago

Id rather go for SCTP instead of QUIC.

TaaviE commented 5 years ago

SCTP gets mangled by middleboxes and will not have such a good support as QUIC/HTTP3 does in various (standard)libraries.

GIJack commented 4 years ago

I don't think it should be mandatory. Perhaps a feature where is mandatory for being labeled IRCv3, but also consider that unencrypted IRC may be used for networks that are already private/encrypted and is both redundant and hard to implement a Key Infrastructure.

VPNs, and darknets like TOR and I2P come to mind.

bortzmeyer commented 4 years ago

SCTP gets mangled by middleboxes

Then, SCTP-over-UDP (RFC 6951), for the same reason QUIC uses UDP.

SadieCat commented 4 years ago

The main reason i'm personally uninterested in SCTP is that there's no support in either Windows or macOS (which has it IPPROTO_SCTP in the headers but creating a socket using it results in an error) which makes it not very useful for the average user.

nyovaya commented 4 years ago

We should then not blame SCTP but Microsoft and Apple for that.

SadieCat commented 4 years ago

You can blame whoever you want but that doesn't change the reality that features which 90% of potential users can't use are useless.

If Google couldn't get OS vendors to care about SCTP then we won't be able to.

nyovaya commented 4 years ago

There is a proper driver which can be installed for OSX and one for windows, but I heard its not in a good state. Maybe we should get more SCTP applications first and then demand OS vendors to add SCTP drivers.

TaaviE commented 4 years ago

IMO SCTP talk should be left to some other issue.

justjanne commented 4 years ago

Please move SCTP discussion over here: https://github.com/ircv3/ircv3-ideas/issues/62

justjanne commented 4 years ago

The current QUIC interop situation is this: https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk0l4JtvTVg/edit#gid=117825384

The current draft for IETF QUIC is still moving relatively quickly, so it makes sense to be cautious and wait for consensus before standardising this, but IMO it'd be interesting to experiment with the current 14th draft against which implementations are currently slowly converging.

TheDecryptor commented 2 years ago

QUICv1 has been finished for a while at this point (A small v2 is currently being worked on), support should be good enough that devs shouldn't expect to run into issues with functionality or compatibility