Subject: [core] UDP 'overflow'

From: Erik Guttman <[email-masked]>
Date: Mon, 29 Mar 2010 13:48:59 +0200

Hi,

I wanted to share some thoughts on UDP requests that may result in 
responses that cannot fit in an UDP response.

In DNS, the response is truncated. A 'TC' flag indicates this trucation 
to the client. The client may resend the request using TCP.

In SLPv2 [rfc2608], the response is truncated also, and an 'O' indicates 
overflow to the 'user agent.' The UA may resend the request using TCP.

One advantage of this approach is that a query may be sent using 
multicast and several responses may be returned. Where overflow occurs, 
the client may obtain the overflowed information using unicast from 
specific responders.

Henning observed during the WG session the /stateful/ nature of this 
overflow-caused retransmitted request. The responder must either (a) 
return something potentially completely different upon the subsequent 
request or (b) /cache /the response from the first request as the state 
of the responder may change between the initial and subsequent request 
from the client.

Perhaps the semantics of (a) suffice? For DNS this is fine. In SLPv2, 
the UA may issue a request subsequently to an overflow with /the same 
XID/. There is no explicit requirement that the response to the 
retransmitted query is identical to the first response. The XID is 
included so as to allow the responder (service agent or directory agent) 
to cache the reply and thereby optimize processing time. So arguably, 
SLPv2 tolerates semantics (a) also.

One consideration I had regarding UDP transport for CoAP for payloads 
exceeding a single datagram: a lockstep approach was mentioned. I wonder 
if for such transfers one could simply use TFTP (RFC 1350) which is well 
worked out and has minimal implementation requirements. For example, 
CoAP could provide a URL to a TFTP accessible resource exceeding the 
datagram MTU. Of course TFTP assumes a 512 byte block size - this would 
have to be adjusted for constrained links. If CoAP relies upon transport 
security, this could also secure TFTP.

Best regards,

Erik

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 29 Mar 2010 14:05:34 +0200

Hi Erik,

> Henning observed during the WG session the stateful nature of this overflow-caused retransmitted request. The responder must either (a) return something potentially completely different upon the subsequent request or (b) cache the response from the first request as the state of the responder may change between the initial and subsequent request from the client.
> 
> Perhaps the semantics of (a) suffice? For DNS this is fine. In SLPv2, the UA may issue a request subsequently to an overflow with the same XID. There is no explicit requirement that the response to the retransmitted query is identical to the first response. The XID is included so as to allow the responder (service agent or directory agent) to cache the reply and thereby optimize processing time. So arguably, SLPv2 tolerates semantics (a) also.

Indeed, (a) is what I had in mind when suggesting this at the microphone.

When do long (> reasonable MSS) resource representations potentially occur in CoRE?

1) for discovery and resource description documents.  These change rarely enough that (a) is not a problem.
2) for long frequently changing representations.  E.g., a JPEG image from a Webcam.  This would be a candidate for TCP, IMO, if not HTTP outright (webcams are generally available with HTTP access, today).

CoAP might have something like (but not necessarily equal to) strong ETags in order to reliably find out when/prevent that subsequent range requests return parts of a different representation.  A truncated representation might also include a URI to a frozen resource (~ Location:) or be an outright redirect, facilitating (b). 

> One consideration I had regarding UDP transport for CoAP for payloads exceeding a single datagram: a lockstep approach was mentioned. I wonder if for such transfers one could simply use TFTP (RFC 1350) which is well worked out and has minimal implementation requirements.

Actually, range requests are close enough in protocol workings to TFTP (actually, simpler) that I don't think it is necessary to introduce another protocol here.

> For example, CoAP could provide a URL to a TFTP accessible resource exceeding the datagram MTU. Of course TFTP assumes a 512 byte block size - this would have to be adjusted for constrained links. If CoAP relies upon transport security, this could also secure TFTP. 

Two reasons to do this in CoAP itself.

Gruesse, Carsten

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 29 Mar 2010 08:48:02 -0400

What's the MSS assumption for CoRE?

If we have object signing (about the only way to get e2e security if you have a protocol translator), even the smallest object quickly exceeds 200 bytes.

I think there are other cases where you are likely to get larger objects:

- sensors that capture measurement traces and get polled periodically (more efficient than polling for every single measurement)
- non-trivial devices that have more extensive state (e.g., more complex machinery)

The problem with the etag mechanism is that it simply tells you that you failed - but there may be no way to succeed if the cache duration happens to be smaller than the delay from first to last request. This seems like a recipe for rather unpleasant failures. Since we assume small memory devices (otherwise, we wouldn't be having this whole discussion...), caching objects for larger intervals seems like a rather dubious assumption. After all, if you buffer 500 bytes, you can implement a complete TCP/IP stack instead - twice (see http://www.ietf.org/mail-archive/web/ietf/current/msg10705.html after random googling: "TCP/IP code itself fits in about 256 bytes"). 

Henning

On Mar 29, 2010, at 8:05 AM, Carsten Bormann wrote:

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>