doc: documentation of SCMP source port#4901
Conversation
| +--------------+---------------------------------------------------------------+ | ||
| | Code | 0 | | ||
| +--------------+---------------------------------------------------------------+ | ||
| | Identifier | A 16-bit identifier to aid matching replies with requests | |
There was a problem hiding this comment.
I would like to know other people's opinion on renaming a protocol field, since it is a normative change that requires bigger consensus. This field mirrors the ICMP Echo Identfier field. Some implementations use PID to populate this field https://man7.org/linux/man-pages/man8/ping.8.html#ID_COLLISIONS, but the field still keeps the generic name. I understand it is useful to reflect the current implementation convention, but still I do not think we need to restrict future implementations making the field keep the source port a protocol requirement. Additionally, we have several implementations already using the "Identifier" field. My suggestion is having something like: "Implementations SHOULD set the Identifier to the source port of the sending application to enable proper demultiplexing of replies by the router." and keeping the current name
There was a problem hiding this comment.
Thanks, that's exactly the feedback I wanted to have. And yes, of course this needs proper approval, I just wanted to start small. However, in the ends this is just about aligning the doc with the implementation.
I now moved the text to a single paragraph in the SCMP Information section.
@oncilla @lukedirtwalker @romshark @FR4NK-W Thoughts? Should this go to one of the TCs?
There was a problem hiding this comment.
I think it is good to document this behavior, since this is as far as I understand implemented. This is a trick that routers use to map SCMP to the UDP/IP underlay, so perhaps this could also be mentioned in #4895 besides here.
Regarding the IETF draft, it says:
A 16-bit identifier to aid matching replies with requests
I think this wording does not conflict with the behavior that you are trying to document. So I think we can leave the draft unchanged.
There was a problem hiding this comment.
P.S. @JordiSubira what is the reason of this behavior? Couldn't end-host implementations just use 40031 as a src port too?
Then traffic could just go to that port, where they are listening for SCMP anyways. Why use dynamic source ports?
There was a problem hiding this comment.
I guess you mean 30041. Basically not, because that port is in most of the cases (although not necessarily) occupied by the scmp daemon (as it is implemented the shim dispatcher, right now). Client applications open underlay UDP/IPs when sending SCMP informational messages. One application can open multiple underlays, and more in general, many applications may open many underlays. This is the mechanism for demux the replies to the correct application that originated the SCMP request. The discussion of why exactly this solution and ruling out other ones (e.g., ab/re-using FlowID in the IP underlay) may be found here: #4280.
There was a problem hiding this comment.
Thank you for your clarification, sounds good to me that we document it.
Update documentation to explain that the former ID field of SCMP info messages now contains the source port.