Hi Mirja, thanks for your replies and PRs. please see replies below, I clipped discussions we have closed. Al > -----Original Message----- > From: Mirja Kuehlewind <mirja.kuehlewind@xxxxxxxxxxxx> > Sent: Tuesday, March 1, 2022 1:49 PM > To: MORTON JR., AL <acmorton@xxxxxxx> > Cc: last-call@xxxxxxxx; draft-ietf-quic-manageability.all@xxxxxxxx; > quic@xxxxxxxx; ops-dir@xxxxxxxx > Subject: Re: Opsdir last call review of draft-ietf-quic-manageability-14 > > Hi Al, > > thanks again! See below! > > On 27.02.22, 19:50, "MORTON JR., AL" <acmorton@xxxxxxx> wrote: > > [snip] ... > [acm] I see that there was additional editing since you wrote last Monday, > so I made a comment and suggestions on GitHub. > > [MK] Thx! Added you suggestions! > > [snip] > > > > > > > > 2.8. Version Negotiation and Greasing > > > > > > ... > > > QUIC is expected to evolve rapidly, so new versions, both > > > experimental and IETF standard versions, will be deployed > on the > > > Internet more often than with traditional Internet- and > > transport- > > > layer protocols. Using a particular version number to > recognize > > > valid QUIC traffic is likely to persistently miss a > fraction of > > QUIC > > > flows and completely fail in the near future, and is > therefore > > not > > > recommended. > > > [acm] Where "valid traffic" is the focus, I agree, let it > flow. > > > But the Operator's focus may instead be "admissible traffic", > where > > > experimental traffic is not wanted or allowed. IOW, only > traffic > > that is > > > understood to conform to <RFC list> shall pass, because > "Active > > Attacks are > > > also Pervasive", to put a different spin on 7258. [acm] See > also the > > comment in > > > 3.4.1. > > > > > > [MK] This is not about experimentation. > > [acm] > > OK, let's just say unexpected traffic. > > > > > The expectation is that QUIC versions > > > will change often, e.g. we already have a draft for a new version > > adopted in > > > the group and there might be another RFC some time this year. So > if you > > > "manually" have to allow for new versions in all your equipment > that > > will > > > delay deployment of new versions (or even hinder them because > there is > > always > > > one box that doesn't get updated). Therefore we strongly recommend > to > > not use > > > the version to filter QUIC traffic. Is that not clear enough in > the > > text? > > > > > > In addition, due to the speed of evolution of the > > > protocol, devices that attempt to distinguish QUIC traffic > from > > non- > > > QUIC traffic for purposes of network admission control > should > > admit > > > all QUIC traffic regardless of version. > > [acm] > > I think it is clear, and at the same time, it is aspirational for > many > > networks. > > This sentence informs, but then strays into policy. > > > > Maybe this will work: > > ...devices that attempt to distinguish QUIC traffic from non- > > QUIC traffic for purposes of network admission control should > not > > rely > > on the version field alone. > > > > [MK] I think your proposal is not correct because the whole point is > that you > > really should not use the version field _at all_. I know that people > will > > still do that, but I think we should at least spell it out clearly here > that > > this is problematic and hinders evolution. > [acm] > Evolution is what happens when a succeeding RFC is approved. > Experimentation is the many months between approvals. > > ...devices that attempt to distinguish QUIC traffic from non- > QUIC traffic for purposes of network admission control > *** should admit all QUIC traffic regardless of version.*** > The last phrase attempts to define operator policy. > Don't do that. > The version field exists. It's specified in a standard. > If you simply say, > "The version field will change in the future." no one will be surprised. > > [MK] Okay I got your point about policy. However, this document is meant to > provide guidance/recommendations to operators. I also see now that this in the > "background" part which is also rather to explain QUIC than give > recommendations. However, I think this is actually one of the essential > recommendations of the document, so I would like to still spell this out > clearly and as early/often as possible. I tried a slightly different wording > in a new PR on github. Is that any better? > > https://urldefense.com/v3/__https://github.com/quicwg/ops- > drafts/pull/459/files__;!!BhdT!mOHh0CyPDRUf9uvgZfIrDspADvFLupiMn- > 5czo4ercUtLNr7_gQJcuGTzI0cYadmIRktrtZrgoTKCp4DmqHssizC$ > [acm] Not yet. Maybe we can compose your message to operators *without* making it sound like you are trying to set policy. I suggested text in the PR like this: Developers would prefer admission of all QUIC traffic regardless of version in order to support continuous version-based evolution. However, all parties understand the value of versions with a corresponding, fully-approved standard. > > > > > > > > > [acm] I was hoping to see a description of fallback to TCP (I > see > > that fallback > > > is mentioned briefly at the end of section 4.2., and later, > fail > > over and > > > failover. pick one...) > > > > > > How can Network Operators observe when a QUIC setup has > failed, and > > the > > > corresponding TCP fallback connection(s) succeeded? > > > > > > [MK] There is no unified way how and if fallback is implemented. > > However, why > > > do you think a network operator would need that information? > > [acm] > > To affirm that their admission policy is working properly, for one > reason. > > > > [MK] However, there is really no guarantee that all QUIC will have a > fallback. > > Without further knowledge about what higher layer service the QUIC > transport > > carries, I don't think you can make any assumption about fallback. If > you want > > to support evolution, you need to support QUIC and not rely on any > potentially > > fallbacks. > [acm] > I chose example carefully: the operator wants to support QUIC, but has > reports that QUIC setup is failing and needs to make measurements to gather > symptoms & info. Experience will indicate the circumstances where QUIC setup > failure is accompanied by fallback, and other possibilities. Repeated > experiences become heuristics for passive observation. > No assumptions necessary. > Has QUIC setup failed if the exchanges in Figure 1 are incomplete? > I think there might be a yes or no answer... > If no, then the passive observation procedure will mostly be governed by > heuristics. > > [MK] I think I lost the point now. If QUIC fails even if there is a fallback, > that's still not great because the original intention was obviously to use > QUIC. Is there anything we need to say in the draft that is missing? [acm] Without getting into fallback in any way, Help the operator determine when a QUIC setup has failed by providing a little more info. It would be useful to know: What QUIC messages would accompany a QUIC setup failure? (other than those in Figure 1) OR A statement like: If the exchange in Figure 1 is incomplete, then the QUIC setup has failed. (IF that is true) > > > > > > > > > Is there a reference available with this info, to save effort > here? > > > > > > [MK] As I said this is rather implementation specific, so I would > say > > no. > > > > > > ... > > > > > > 3.4.1. Extracting Server Name Indication (SNI) Information > > > > > > ... > > > > > > Note that proprietary QUIC versions, that have been > deployed > > before > > > standardization, might not set the first bit in a QUIC long > > header > > > packet to 1. However, it is expected that these versions > will > > > gradually disappear over time. > > > [acm] > > > And some networks may prefer not to admit experimental > traffic. The > > goal of the > > > experiment may be problematic for the network operator and/or > their > > > subscribers. I think this is legitimate operator behavior, and > worth > > a few more > > > words in the draft. > > > > > > [MK] To be honest I don't understand this point. How would an > operator > > even > > > know if an experiment would be problematic or no? QUIC is fully > > encrypted. > > > Versioning is only one extension mechanism. So basically even if > you see > > the > > > same version number, the QUIC behind that could behave very > differently > > > depending on which extensions are used and because of the > encryption, > > there is > > > no chance for the operator to know about this. Is this not clear > in the > > > document? Do we need to state this more clearly? > > [acm] > > First, let's say s/experimental/unexpected/ or > s/experimental/proprietary/ > > Then, I'm responding to your reply more than the paragraph in the > draft > > now: > > Network operators are also end users, and often act on their > subscriber's > > behalf. Observations are not strictly limited to mid-points, where > encryption > > is present. > > Harboring old notions of what operators cannot do will not sit well > with > > your audience... > > > > So, (in the paragraph above) you've informed operators that some > > proprietary QUIC versions remain in use as of this writing. > > But traffic that doesn't conform *might* be considered nefarious. > That's > > all. It's a message for everyone involved. > > > > [MK] I think the point is actually rather that we want to say here: if > you > > don't support these old versions that will not be a problem in the near > > future. > [acm] > Ok, say that in the draft, please. > > [MK] Okay started a PR on github. Is that more clear now? > > https://urldefense.com/v3/__https://github.com/quicwg/ops- > drafts/pull/460/files__;!!BhdT!mOHh0CyPDRUf9uvgZfIrDspADvFLupiMn- > 5czo4ercUtLNr7_gQJcuGTzI0cYadmIRktrtZrgoTKCp4DmqkDVmpL$ > > [acm] I'm ok with this one, thanks. > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
