Figure 1 shows a TCPLS record having a sandwich of TCPLS DATA/CONTROL/DATA frames. This should be avoided, as this design is the reason why QUIC cannot easily be zero-copy on the receiver side. It either leads implementer to make a contiguous buffer with an additional copy, or to offer fragmented application payloads.
1) Why would we want to have those sandwiches?
2) As long as CONTROL frames are after DATA in the same record, we're fine. So we may want to only allow CONTROL frames to be appended in a record already containing DATA if space permits (i.e., if it does not go over max payload size).
A believe also that Google QUIC avoids to make those sandwiches in their fully controlled environment, and that's one of the reasons their perf announcement were looking good.
Figure 1 shows a TCPLS record having a sandwich of TCPLS DATA/CONTROL/DATA frames. This should be avoided, as this design is the reason why QUIC cannot easily be zero-copy on the receiver side. It either leads implementer to make a contiguous buffer with an additional copy, or to offer fragmented application payloads.
1) Why would we want to have those sandwiches?
2) As long as CONTROL frames are after DATA in the same record, we're fine. So we may want to only allow CONTROL frames to be appended in a record already containing DATA if space permits (i.e., if it does not go over max payload size).