> On 9 Dec 2016, at 22:12, Joe Touch <to...@isi.edu> wrote: > > > > On 12/9/2016 12:28 PM, Michael Tuexen wrote: >>> ... >>>> In the API description in https://tools.ietf.org/html/rfc6458 the MTU >>>> exposed to the application >>>> via the API is "the number of bytes available in an SCTP packet for >>>> chunks." I think this is the best >>>> we can do at that interface... >>> AFAICT, that's 1) in my list, e.g., the largest chunk that SCTP can send >>> without having SCTP coordinate frag/reassembly. That doesn't itself >> You need to take the DATA or I-DATA chunk header into account... >> It is "the number of bytes in the packet for chunks", not "the number >> of bytes for the chunk value for DATA (or I-DATA) chunks". > Yes, but (see below). > >> >>> indicate whether it's SCTP doing the rest or the network layer. >> As I said, that is what is exposed to the upper layer via the API. >> SCTP itself has procedures to detect the PMTU (of each path). >> It does PMTU discovery by interacting with the IP layer... > > Yes, but it's possible that the chunksize the app sees from SCTP is > related to SCTP's reassembly limit, not IP's and not the PMTU. > > At least that's how I read SCTP_MAXSEG. Not sure what the reassembly limit is... SCTP handled arbitrary sized user messages a the receiver side by using partial delivery.
The SCTP_MAXSEG allows a user to limit the size of DATA chunks without reducing the pmtu. Please note that this only affects DATA chunks, not the whole packet. So that is why I was not referring to this option. The socket options I was referring to are: * SCTP_GET_PEER_ADDR_INFO defined in https://tools.ietf.org/html/rfc6458#section-8.2.2 * SCTP_PEER_ADDR_PARAMS defined in https://tools.ietf.org/html/rfc6458#section-8.1.12 Best regards Michael > > Joe _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
