QUIC Server Support (R2)

[hlandau]

### Tasks
- [ ] https://github.com/openssl/project/issues/110
- [ ] https://github.com/openssl/project/issues/180
- [ ] https://github.com/openssl/project/issues/265
- [ ] https://github.com/openssl/project/issues/293
- [ ] https://github.com/openssl/project/issues/294
- [ ] https://github.com/openssl/project/issues/295
- [ ] https://github.com/openssl/project/issues/300
- [ ] https://github.com/openssl/project/issues/296
- [ ] https://github.com/openssl/project/issues/365
- [ ] https://github.com/openssl/project/issues/299
- [ ] https://github.com/openssl/project/issues/527
- [ ] https://github.com/openssl/project/issues/301
- [ ] https://github.com/openssl/project/issues/302
- [ ] https://github.com/openssl/project/issues/448
- [ ] https://github.com/openssl/project/issues/179
- [ ] https://github.com/openssl/project/issues/523
- [ ] https://github.com/openssl/project/issues/305
- [ ] https://github.com/openssl/project/issues/304
- [ ] https://github.com/openssl/project/issues/383
- [ ] https://github.com/openssl/project/issues/381
- [ ] https://github.com/openssl/project/issues/382
- [ ] https://github.com/openssl/project/issues/533
- [ ] https://github.com/openssl/project/issues/532
- [ ] https://github.com/openssl/project/issues/386
- [ ] https://github.com/openssl/project/issues/385
- [ ] https://github.com/openssl/project/issues/384
- [ ] https://github.com/openssl/project/issues/364
- [ ] https://github.com/openssl/project/issues/363
- [ ] https://github.com/openssl/project/issues/141
- [ ] https://github.com/openssl/project/issues/561
- [ ] https://github.com/openssl/project/issues/562

[hlandau]

I have added the following tasks to this epic:

• API Design - Polling
• Implementation - Polling

The API design is basically done but I need to brood on it a little.

[hlandau]

I have added the following task to this epic:

• Design/Implementation - Internal Netmatic BIO

[hlandau]

The following:

• [ ] Implementation - Full CID Management

has been broken down into

• [ ] Implementation - CID Management - LCIDM Implementation
• [ ] Implementation - CID Management - RCIDM Implementation
• [ ] Implementation - CID Management - SRTM Implementation
• [ ] Implementation - CID Management - SRT GEN Implementation
• [ ] Implementation - CID Management - Wiring & Integration

[hlandau]

Added dependency references to some tasks.

Suddenly I find myself wondering if anyone's written a tool to generate graphviz from dependency relationships between GitHub issues.

[hlandau]

#!/usr/bin/env python3
import json, re, sys, os

re_dep = re.compile(r'''Depends on #([0-9]+)''')

def run():
    os.system('gh issue list -S is:open --json id,title,body,closed,state,url,number --limit 999 > issues.json')

    with open('issues.json', 'r') as fi:
        issues = json.load(fi)

    with open('dep.dot', 'w') as fo:
        issuesNeedingNode = {}

        fo.write("digraph G {\n")
        for issue in issues:
            ms = re_dep.findall(issue['body'])
            for m in ms:
                fo.write(f"  issue_{issue['number']} -> issue_{m};\n")
                issuesNeedingNode[int(m)] = True

            if len(ms) > 0:
                issuesNeedingNode[issue['number']] = True

        for issue in issues:
            if issuesNeedingNode.get(issue['number']):
                fo.write(f"  issue_{issue['number']} [label=\"{issue['title']}\"];\n")

        fo.write("}\n")

    os.system("dot -Tpng -o dep.png dep.dot")
    return 0

if __name__ == '__main__':
    sys.exit(run())

[hlandau]

Everything is gated on #296, which is gated on #265 (pending review), which is gated on #293 (pending review), #295 (pending second review). #294 has completed review and will merge after the repository is unfrozen. #300 is done and a PR can go up anytime, so its future scheduling == time taken to review it.

Conformance review and updates should be estimated pessimistically. It takes time.

We could start having people work on interop testing and on performance testing infrastructure for this now. These are not blocked on #296 (design documents can start being produced, or actually implemented for client-side QUIC).

304 can be worked on as soon as our API design is validated, so likely soon after the DDD demos are done.

[hlandau]

I have split #296 into #296 and #365. Note that only #296 is a blocker for a lot of other issues. This should help optimise the critical path.

[hlandau]

Plan:

Feature Development:

• 265 must be merged first,

• then I complete the DDD-server work (WIP),
• then #296 (assignee me)

The following can then be executed in parallel:

• 299 (assignee me)

• 365 (me or possibly another contractor)

• 302 (This could theoretically be started by another contractor after #265 is done already, or by basing off of #265 before it is reviewed. i.e., theoretically we could try giving it someone now.)

To be dropped, not strictly an MVP feature:

• 303

Test writing can definitely be farmed out to other contractors as much as possible. It helps them learn the codebase/QUIC, improves QA and coverage, while not being a disaster if something falters.

[hlandau]

Added new 'good first issue' label to things other contractors might be able to handle.

[hlandau]

https://github.com/orgs/openssl/projects/2/views/42

This shows my idea of how the work is serialized/the critical path. It shows what we could conceivably get others to start working on now.

Assume durations of tasks are highly optimistic. The roadmap view doesn't really let you span an item over multiple iterations.

If I have assigned something to me it means it's essential I do it. If I have assigned something 'good first issue' I think we should at least try and see if someone else can do it. If I have done neither it means I'm undecided either way.

[arapov]

Thank you, @hlandau!

[microhardsmith]

Will quic server support get delivered at OPENSSL 3.4?

[t8m]

Will quic server support get delivered at OPENSSL 3.4?

No, unfortunately not. It is now scheduled for OpenSSL 3.5.