Cellular API: purpose of get_max_packet_size()

[RobMeades]

Description

The new cellular API, in its AT_CellularStack class, includes the method get_max_packet_size(). What is the purpose of this method? I ask because, in the u-blox modem implementation, the answer is different for UDP versus TCP:

1. A UDP packet passed into the sendto() call by the user can be up to 1024 bytes in size, after which it will be broken into multiple UDP packets.
2. TCP, as a streamed protocol, has no size limit that is visible to the user, hence the maximum packet size is arbitrary.

I realise that the current AT_CellularStack is UDP-only but it is our intention to submit our AT_CellularStack implementation shortly and that will support both UDP and TCP, hence the request for clarification. If the purpose of the get_max_packet_size() call is to tell the user the maximum size that a UDP packet can be without being fragmented then could the Doxygen comment be update to that effect? If it is something else, please clarify.

Issue request type

[x] Question
[ ] Enhancement
[ ] Bug

[ciarmcom]

ARM Internal Ref: MBOTRIAGE-650

[AriParkkila]

AT_CellularStack::get_max_packet_size() is intended to return maximum length that can be written to modem, which would typically be RX buffer size on modem. It's not related to protocol MTU.

[RobMeades]

Understood, but let me put it another way: why would a user be interested in this and what would you expect them to do differently as a result of knowing it (for the UDP and TCP cases)? What I would like them to think is that, if they are using TCP, then it is irrelevant (i.e. they can put as much or as little data into one packet as they like, it is up to them) while, for UDP, any data packets larger than AT_CellularStack::get_max_packet_size() will be split into multiple UDP packets by the socket. Is this what you intend them to think and, if so, can we clarify the comment so that they do the right thing?

[AriParkkila]

@kjbracey-arm could you comment on this issue:

1. Is it good that modem will split one sendto() message to multiple UDP packets?
2. It seems that get_max_packet_size() is not needed at all, and it should be removed?

[kjbracey]

The modem must not split sendto() into multiple UDP packets. One send must correspond to exactly one receive at the other end, which is achieved by sending exactly one UDP datagram. There may be IP fragmentation underneath, but that's transparent to the UDP datagram layer.

Scrubbed the next bit of this comment as confused myself and wasn't making sense. Will try again...

[kjbracey]

Not sure if you're giving any useful info to user with get_max_packet_size. It might be useful for apps to have some idea what they can send with UDP sendto, but the answer to that is a combination of link MTU, IP fragmentation ability and available buffer space. A bit too complex to get a good answer in many cases, and on top of that you need to know what the receiver can handle.

Probably simplest for apps to be conservative unless manually configured. Default to 512 byte payload for UDP/IPv4 and ~1200 for UDP/IPv6

[AriParkkila]

Thank you @kjbracey-arm @RobMeades

We will remove get_max_packet_size().

[RobMeades]

Sounds good to me, one question to Kevin: if the user submits a buffer to the socket to be sent over UDP which cannot be encoded into a single UDP datagram, what is the correct action for the socket to take? We chose to transmit anyway, segmenting, since that's what the network might, in any case, do, and our UDP packet size limitation is 1024 bytes, which is already bigger then anyone would expect (plus we tr_warn() the user, if they have that switched on).

Should we instead return some form of error and not transmit the buffer at all?

[kjbracey]

If you can transmit it as a single UDP datagram by fragmenting at the IP level, not the UDP level, then accepting any size is fine. Nanostack has a theoretical upper limit on UDP transmission of just under 64K - you'll be limited by memory, generally.

Whether the receiver can reassemble the IP packets and fit the resulting UDP datagram into its reception buffer is another question, but if the app wants to try the transmission, then that's up to the app.

If you can't send it as a single UDP datagram, then the correct behaviour is to return an error. POSIX would have you return EMSGSIZE, but we don't seem to have an exact nsapi equivalent. It would have to be either PARAMETER, I guess.

Breaking a 1200-byte UDP datagram into two 1000+200 byte UDP datagrams achieves nothing for standard protocols, as there's no way for the receiving application to figure out where the missing 200 bytes from the first datagram are, or what to do with the 200 byte tail when it arrives.

[kjbracey]

We chose to transmit anyway, segmenting, since that's what the network might, in any case, do,

An IPv4 network might fragment into multiple IPv4 packets, and the local IPv6 stack might fragment into multiple IPv6 packets, but they will all be reassembled at the receiver into a single UDP datagram, so come out as a single 1200-byte receive call.

[RobMeades]

That's clear, thanks. We will use NSAPI_ERROR_PARAMETER for this UDP case.