Skip to content
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

Closed
theri opened this issue Jan 18, 2020 · 10 comments
Closed

Arch: service class influences protocol selection? #476

theri opened this issue Jan 18, 2020 · 10 comments

Comments

@theri
Copy link
Contributor

theri commented Jan 18, 2020

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?

@gorryfair
Copy link
Contributor

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.

@tfpauly
Copy link
Contributor

tfpauly commented Jan 18, 2020

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.

@britram
Copy link
Contributor

britram commented Jan 21, 2020

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...

@gorryfair
Copy link
Contributor

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.
The LE PHB is a little odd in this respect, in that it call for "less" than Default treatment - upgrading to Default is likely less desirable than choosing a path that does support LE, so it could be an example, although I'd really prefer not.

@britram
Copy link
Contributor

britram commented Jan 22, 2020

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?

@tfpauly
Copy link
Contributor

tfpauly commented Jan 22, 2020

I wouldn't want to prevent it!

@gorryfair
Copy link
Contributor

If that automates DSCP selection, I think this is the wrong thing to say in this document.
If the example were PvD-based, then that would be the correct thing.

@tfpauly tfpauly self-assigned this Jan 24, 2020
@tfpauly
Copy link
Contributor

tfpauly commented Jan 24, 2020

We'll just remove the words "service class"

@gorryfair
Copy link
Contributor

OK, and Issue #494 suggests to remove recommending EF in favour of explaining EF can be used.

tfpauly added a commit that referenced this issue Feb 21, 2020
@theri
Copy link
Contributor Author

theri commented Feb 24, 2020

Thanks!

@theri theri closed this as completed Feb 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants