Re: [core] Ben Campbell's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)

[Adam Roach <[e-mail]>]

On 5/12/17 04:48, Carsten Bormann wrote:
> Hi Adam,
>
> thank you for this design sketch.
>
> I fully support your quest to find a solution that avoids resource siloing.

To be clear, while that's a goal here, it's far from the primary goal. 
The high-order bit in my book is correctly dealing with what URI schemes 
actually mean, since that has implications well beyond CoAP.

> I’ll call the approach of trying out several transports at once “happy bearing balls” for now :-)
> (We don’t have eyeballs in the IoT :-)
>
> I’m still a bit nauseous from all that probing and caching (and negative caching).

The caching is an optimization with obvious trade-offs, and I'm more 
than happy to leave it to implementations as to whether they think it's 
something they need.

>    It sounds like a big deployment headache, and a way to add indeterminism and inexplicable delays into something that could have been very simple.

As you correctly point out above, there are no eyeballs involved. I 
doubt that Things care about the occasional 15-second delay. In any 
case, the configuration I propose is intended to shortcut these delays 
if NATs are known to be a problem a priori.

>    Having a transport *hint* in the URI still sounds like a way to reduce this when the determination can already be made at the server side ([1]).
>
> In the IoT space we typically have information from configuration and from places such as the Resource Directory that could enhance a URI with information about the best transport type to use for it (DNS is not always in use, by the way).  Baking this into the way transports are selected goes further down the road that a URI is not by itself all you need to make the request, but to a certain extent that has always been the case by including a DNS name (which may be one reason why DNS is not as much in use with CoAP).

I really don't follow this paragraph.

> What doesn’t work at all for me is deduplication across transports:
>
>> [3] The operation on the TCP connection would need to use the same Message ID as the UDP attempts did, to ensure idempotency -- it's possible that one or more of the transmitted UDP packets did make it to the remote node, but the ACKs did not arrive back at the originator. This does necessitate un-removing the Message ID field from TCP, but I think that's a Good Thing anyway.
> How is a server supposed to find out two messages that reach it over different transports are actually the same?
> Sure, including message-IDs would be one thing (which are otherwise of no use in TCP).
> But what about two clients happening to use the same message-ID?  The server would need to associate the copies of the request it got to the same client.  This would require that the client uses matching ephemeral ports for UDP and TCP, and I don’t know how to get this through NATs (which are one of the big use cases we are addressing).
>
> So I would like to de-emphasize the happy bearing balls for non-idempotent requests — there is usually something that a client wants to do with a server anyway before getting to those.

It sounds like we can come up with something here, then -- perhaps 
UDP&TCP clients would be required to make first contact using a request 
that is inherently idempotent. (I mean, I have some other ideas about 
how we could perform deduplication, but I'm sure you'd find them 
distasteful for constrained implementations.)

> In summary: I like being able to do happy bearing balls.  I’d also like to be able to not use it, based on transport hints.

I'm fine with that in principle, but your transport hints can't be part 
of your URI scheme. That's just not what schemes mean.

/a