Hi Thomas,
> Now, it turns out in the specific situation (and whenever the data
> framing is provided by a higher layer protocol - CoAP, SCTP, DNS) one
> might as well buffer and coalesce all the application stuff into one
> single record, making the need for CID compression moot.
I'm not sure, how CoAP (RFC 7252) offers framing. AFAIK it uses the size
of the UDP message (or that of the DTLS "application_data" part). Only
for TCP the size is explicitly encoded in the CoAP messages (but that's
not RFC7252). If I miss something about that, it would be great, if you
share some details to help me out.
In my opinion, introducing a new TLS Content Type
"multi_application_data" would help in a more general way. Even without
the "implicit CIDs" discussion it may help in some cases, where a couple
of "very small" "application_data"-messages are sent at once.
best regards
Achim
Am 27.05.20 um 12:03 schrieb Thomas Fossati:
On 24/05/2020, 20:45, "Eric Rescorla" <e...@rtfm.com> wrote:
In what context do you have a use for implicit CIDs?
The specific use case I had in mind is that of an endpoint sending small
and frequent application data units to the same peer - e.g., sensor
readings through CoAP observe. In this (and similar) situation(s) where
the payload / header ratio is low one wants to have as little transport
overhead as possible.
Now, it turns out in the specific situation (and whenever the data
framing is provided by a higher layer protocol - CoAP, SCTP, DNS) one
might as well buffer and coalesce all the application stuff into one
single record, making the need for CID compression moot.
So, I am now convinced I don't have a compelling case to bring to the
table and might as well move into Martin's "vanishingly small use cases"
camp, therefore subscribing the gist of PR#148.
PS A note about the more general argument of a pure pseudo-header
approach: it'd enable compression boxes at ingress into a constrained
network, which would be really useful. Without a thorough analysis wrt
header malleability this is unfortunately out of reach.
--
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
