Bob, >> >> - If any of this is of value, how much belongs in the >> ICCRG versus TSV working groups? > > Well, RED and particularly WRED is very widely deployed. So that implies at > least guidelines about legacy should be in TSV not ICCRG. > > We are really gunning for self-configuring AQMs. They are not yet widely > deployed so one could say that is a research subject. However, static config > AQMs have been researched to death already (and parameter sensitivity), so I > think we can say the area in general is understood enough to go straight into > the IETF, not ICCRG. > > AQM for wireless interfaces has been less researched - probably better to > have ICCRG activity in parallel, but allow anything sufficiently mature in > the IETF too. > > Joe Touch says INT or OPS. I don't agree - there isn't the expertise there. I > admit the core competence in TSV is e2e protocols, but TSV is where nearly > all the expertise in queuing sits too. We should present to INT & OPS, but > not do the work there.
I think the exception is a BCP or simply a common practice that discusses guidelines concerning deployed AQM. Something like that would seem to be more in line with OPS. I don't think it has to be all-or-nothing in terms where AQM work resides -- parts here and there could be distributed depending heavily on what is being proposed/done. And I would agree that a considerable amount of the expertise (and energy) on the topic is in TSV. A few years ago, the requirements for adding a resource priority header was initially done in IEPREP, and then when it was fleshed out (by the group most interested in the topic), it was turned over to SIP (where the expertise existed) and finalized there. I'm not saying we would need to do the exact same thing, but we have options to consider. -ken
