[core] Head of line message blocking?

[Jim Schaad]

In UDP there is a vague requirement that a client should only have one
message in transit to any given server at a time. This means that it is up
to the client, if it wants to break this rule, to ensure that a response to
message A has been received before sending message B if there is going to be
a dependency between them. This is needed because UDP does not do ordered
delivery among other things.



TCP however does have ordered delivery. Thus the question is does the same
rule still exist for a client when using a TCP channel. In theory, it would
be possible to send message A and then send message B before getting the
answer back and have an assumption that message A would complete before
message B starts. This implies that the server would need to have an
enforcement of such a rule. My server currently does parallel processing of
requests and thus would not do this unless it was enforced by the transport.
Should such enforcement be done? I see nothing about this in the document
so I assume that the UDP rules would still apply.



Jim

[Carsten Bormann]

In UDP there is a vague requirement that a client should only have one message in transit to any given server at a time. This means that it is up to the client, if it wants to break this rule, to ensure that a response to message A has been received before sending message B if there is going to be a dependency between them. This is needed because UDP does not do ordered delivery among other things.
TCP however does have ordered delivery. Thus the question is does the same rule still exist for a client when using a TCP channel.

No. Congestion control in CoAP-TCP is entirely handled by TCP.
Fire away your requests at will.

In theory, it would be possible to send message A and then send message B before getting the answer back and have an assumption that message A would complete before message B starts.

There is no implied ordering of the responses as in HTTP/1.1 pipelining.
The token provides the link between request and response, so that ordering is simply not needed.

This implies that the server would need to have an enforcement of such a rule. My server currently does parallel processing of requests and thus would not do this unless it was enforced by the transport. Should such enforcement be done? I see nothing about this in the document so I assume that the UDP rules would still apply.

Maybe the document should state explicitly why it is silent about this: It does not impose any rule on this.

Grüße, Carsten

[Hannes Tschofenig]

I agree with the response Carsten provided.

Note: We do touch on the head-of-line blocking issue in TCP, which may
occur when large payloads (such as firmware images) are transported over
TCP and if you only use one TCP connection.

See https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-10#section-6

Ciao
Hannes

Post by Carsten Bormann

In UDP there is a vague requirement that a client should only have one message in transit to any given server at a time. This means that it is up to the client, if it wants to break this rule, to ensure that a response to message A has been received before sending message B if there is going to be a dependency between them. This is needed because UDP does not do ordered delivery among other things.
TCP however does have ordered delivery. Thus the question is does the same rule still exist for a client when using a TCP channel.

No. Congestion control in CoAP-TCP is entirely handled by TCP.
Fire away your requests at will.

In theory, it would be possible to send message A and then send message B before getting the answer back and have an assumption that message A would complete before message B starts.

There is no implied ordering of the responses as in HTTP/1.1 pipelining.
The token provides the link between request and response, so that ordering is simply not needed.

This implies that the server would need to have an enforcement of such a rule. My server currently does parallel processing of requests and thus would not do this unless it was enforced by the transport. Should such enforcement be done? I see nothing about this in the document so I assume that the UDP rules would still apply.

Maybe the document should state explicitly why it is silent about this: It does not impose any rule on this.
Grüße, Carsten
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core