New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Arch: service class influences protocol selection? #476
Comments
If service class maps to offered PvD then it would be a valid example ... Although I also expect it would map to DSCP ... the two are not exclusive. |
I'm not sure we want to go into examples, but service class of traffic can certainly influence path selection. If I know I have a path that's well optimized for VoIP traffic (perhaps its a dedicated PvD, or perhaps it just has properties that work well), and another that's well optimized for bulk throughput, I may prefer paths differently. |
Also: if the endpoint knows that one network is org-private and will actually honor DSCP markings, and that another traverses unknown-topology Internet paths and will probably strip them, then setting AF4 is a hint that maybe the app wants to use the org-private network... |
Interesting thought, but I think the IETF should actively discourage that sort of forwarding treatment. I'd hope we wouldn't have an example of this one. |
Let me flip this around: is there a compelling reason that the architecture should forbid an implementation to use service class in protocol stack and path selection? |
I wouldn't want to prevent it! |
If that automates DSCP selection, I think this is the wrong thing to say in this document. |
We'll just remove the words "service class" |
OK, and Issue #494 suggests to remove recommending EF in favour of explaining EF can be used. |
Thanks! |
In the architecture document, in Section 4.1.2 under "Selection Properties", we have text saying:
"Examples of options that influence protocol selection and configuration of transport protocol features include reliability, service class […]"
Why service class?
For me service class sounds like setting DSCP code points, and that does not sound like something that would influence protocol selection or path selection.
Maybe we should remove this example or, if there's a specific case in which service class influences selection, reference it?
The text was updated successfully, but these errors were encountered: