Comments on draft-polk-tsvwg-rfc4594-update-00.txt

James,

in general I appreaciate the idea to standardise some DiffServ
classes and the assigned codepoints and do this within IETF.

The general aim should be to enable end-to-end QoS accross network boundaries.
This requires a low number of well defined QoS classes and codepoints, but
also guidance how to match and map QoS classes on network boundaries or
betweeen network layers.

The approach on QoS class/codepoint standardisation I favour should follow these lines:

- follow the network provider demand
- respect the results of other standards bodies and liaise with them.
- allow reserves for future use in DiffServ codepoint space.
- re-think codepoint assignments which didn't
  see widespread deployment yet.
- allow for smooth interoperation with 8 class
  QoS schemes like MPLS or Ethernet.
- allow reserves for future use in MPLS TC / Ethernet P-Bit
  codepoint space.
- as one could assume, I'd appreciate standards guidance on
  8 class schemes in a revised document on QoS.

I'm less concerned whether a resulting RFC is on standards track or informational. What
matters to me is explicit support from network providers while the draft is written. And
I'd appreciate giving other standards bodies a chance to get involved (I don't say let
them steer it - they should be aware of the activity, that's it).

Draft-polk-tsvwg-rfc4594-update-00 is controversial to me. Some approaches are allrigh.
In general, the document standardises far to many codepoints and isn't always clear
about the usage. If this isn't changed, I object it beeing put on standards track. A
lack of explicit network provider support would be another reason why to make it
an informational RFC.

One example of the "keep it simple" approach I favour is your drafts High-Throughput
Data Service Class. The draft doesn't explain well, why to assign three codepoints
AF11, AF12 and AF13 to applications. RFC2597 is a smart document, but it provided
too many codepoints and too many classes. Reducing options is part of what should
be done here, not fixing them in a standard. On AF1, my personal favorite is to
discourage usage. On others, discouraging use of the AFn3 codepoint may be useful.
Should these be required by future services, let's work on that. When there's
demand.

That isn't all which I'd like to see improved by a standard on QoS
classes/codepoints. But it's sufficient to start a discussion.


Regards,

Ruediger