search

quicwg / multipath

In-progress version of draft-ietf-quic-multipath
Other
50 stars 18 forks source link

remove text that contradicts to the WG's effort trying to prevent ossification #203

Closed kazuho closed 1 year ago

kazuho commented 1 year ago

As a working group, we are spending efforts to prevent ossification (see QUIC v2 draft as an example).

I think it'd be inappropriate to have a statement that sounds as if we think that ossification is inevitable and that QUIC versions other than v1 is going to have lower penetration rate.

marten-seemann commented 1 year ago

Fully agree. I'd even go one step further and claim that if this was an opportunity to get middleboxes used to yet another QUIC version (other than v1 and v2), I'd see this as a feature, not a bug.

LPardue commented 1 year ago

Agree with the PR.

As a higher order point, this intro can do with a good editorial pass to make it more appropriate for a finished RFC. Some of the points in the intro are very interesting fetaures of multipath QUIC or notable in the operation of the protocol. Others, such as the part Kazuho is removing, are historical baggage that is good to leave on the editing floor.

huitema commented 1 year ago

Sure. There are plenty of good reasons to build on QUIC V1, e.g., code compatibility, tests, security analyses. But middleboxes is not one of them.

mirjak commented 1 year ago

I'm fine to remove the part about middleboxes but I think we did design the extension with a requirement to not change the header (i.e. otherwise we could have considered to add a separate path ID in the header). I think we should acknowledge that requirement still.

mirjak commented 1 year ago

I'm generally fine with this PR, however, I still think reusing path validation and not changing the header are to separate points/requirements. But I don't have a strong opinion.

kazuho commented 1 year ago

@Yanmei-Liu The problem with such text is that it contradicts with WGs efforts to prevent ossification (see RFC 8999 and QUIC v2 for example). In fact, if only middlebox interference was the reason, then we should be using a different version number for Multipath in alignment with other efforts to prevent ossification.

If we want to state the reason that can have consensus, probably we want to call out the privary concern (of middleboxes bisecting multipath and non-multipath traffic).

But maybe we can stop short of explaining really why. I've update the text with following sentence: Use the same packet header formats as QUIC version 1 to minimize the difference between multipath and non-multipath traffic being exposed on wire.

@mirjak @Yanmei-Liu WDYT?

mirjak commented 1 year ago

Yes, that works well for me! Thanks!