Wrt to charter exclusion of QoS:
I gave that example of selecting LEDBAT over TCP when the applications
QoS requirement is scavenger. Poeple would want to do that in TAPS but
didn't feel this was "QoS". Fine. I won't argue for word smithing.
"No QoS" seemingly was meant to be "No DiffServ/Intserv/new-similar-
technologies". But what seems to be the root reason behind this was
the desire to foremost make TAPS work and be useful for Internet
paths, where you do not have any of this. If the charter would simply
say that, it would be much less confusing.
And if folks come into TAPS and say they are going to commit writing
eg: DiffServ in TAPS draft - why not. DiffServ and other QoS netork
technologies are not entitlement technologies: Instead, if somebody proposes
to include them, somebody owns the work to make that happen in the drafts.
Having said this: It seems the charter discussion has been going on
for way too long now, and there seems to be diminishing RoI in further
refinements. I am happy to hum for a WG nonwithstanding Charter refinement.
I think the area TAPS plans to tackle is under-explored/documented by the
IETF (RFC wise). I think its better to create RFCs of the different
approaches and document also their downsides instead of using the charter
to push back on work into potentially alternative/complementary approaches.
Cheers
Toerless
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
