Popping up because my name was invoked ("poof!")
On Sat, Feb 12, 2022 at 1:06 PM MORTON JR., AL <[email protected]> wrote:
> Hi Mirja, Thanks for your replies.
>
> I replied below: some concerns with assumptions about operators in a doc
> for operators, and TCP-f-something (use a single term) is still
> unresolved...
>
<snip>
> > 4.5. Filtering Behavior
> >
> > [RFC4787] describes possible packet filtering behaviors that
> relate
> > to NATs but is often also used is other scenarios where packet
> > filtering is desired. Though the guidance there holds, a
> > particularly unwise behavior admits a handful of UDP packets and
> then
> > makes a decision to whether or not filter later packets in the
> same
> > connection. QUIC applications are encouraged to fail over to TCP
> if
> > [acm]
> > is "fail over" or "fallback" the preferred term?
> > (using only one will help)
> [acm]
> Still need to pick-one here, and everywhere...
>
> Spencer and others had some replies/follow-up comments here.
>
After discussion, Spencer's comment degenerated into "pick one".
I'm not speaking for others who replied/followed up on this, but I was
thinking that it would be possible to use fairly precise terms to describe
what the QUIC implementation was trying to do.
After reflecting on what other people said, I'm thinking that the precision
I was hoping for won't be helpful for passive observers, and (for extra
credit) would be even less helpful if/when we deploy
https://datatracker.ietf.org/doc/draft-ietf-quic-multipath/ and a passive
observer isn't seeing all of the paths in use. 😀
So I'm thinking that anything we agree on for this document may not survive
the use of QUIC for new applications.
Do The Right Thing, of course.
Best,
Spencer
p.s. 😈 I can't wait for the day someone uses QUIC datagrams for an
application that can rely on DCCP as its f******* protocol, and all the
network operators are still looking for TCP traffic - but let's not *even *go
there in this document! 😈
