Re: [core] Mirja Kühlewind's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS)

[Carsten Bormann <[e-mail]>]

On May 10, 2017, at 18:24, Adam Roach <[e-mail]> wrote:
> 
> You state this like the complexity of adapting two different state machines to each other is unavoidably inherent to a proxy that performs these kinds of transport conversions; but it's not.
> 
> The only reason this complexity arises for CoAP is because the design in this document requires it. If you simply encapsulated UDP over TCP with simple framing, and left handing of reordering and deduplication identical to what currently exists for CoAP over UDP, then the proxy could shuttle messages from one side to the other, with the only needed state being that directly related to the TCP connection. (And if you left in the fields that you find unnecessary in TCP, it would be able to do it with far fewer memory copies, which would make for significantly better scalability; and, as a bonus, you wouldn't need multiple sets of parsing and marshalling code in endpoints that support both UDP and TCP).
> 
> Proxies between different transports don't *have* to be complicated.

There are indeed simple cases where UDP-to-UDP proxies can be implemented as UDP payload forwarders.
Unfortunately, things become a bit more complex as soon as the proxy has some fan-in (more than one client), or actually wants to provide some function such as caching.

For TCP, the WG decided we wanted to use TCP's reliability features instead of re-using our own on top of using TCP just as a datagram forwarding mechanism.  This favors the simplicity of an end-system over that of certain simple cases of a proxy.  (Which is in line with other design decisions we have made about allotting complexity to different places in the architecture.)

Grüße, Carsten