Subject: [core] A couple of late comments on Hop-Limit

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Oct 2019 10:13:24 +0000

Hi,

I haven’t followed the hop-limit discussions, so I apologize if the following has already been discussed. I also know that my comments come very late in the process, so sorry for that.

Adam may have an opinion regarding Q2.

Q1:

The draft talks about “CoAP messages”. But, if I understand correctly, it is only intended to be used for CoAP request messages, right?

  *   Since you use a CoAP option, the mechanism can’t be used in an empty message.
  *   I assume you don’t want to use the mechanism when sending a response, because then there is a risk that the client will not receive it.

Unless I’ve missed it, I think it should be more explicit what the applicability of the mechanism is.

Q2:

The draft says that a CoAP message with the Hop-Limit option value set to 0 bigger than 255 must be rejected with a 4.00 Bad Request response.

  *   Is 4.00 really an appropriate response code? When reading the HTTP definition for 400 Bad Request (CoAP inherits the semantics), it is about a client error (miss formed message, etc), which is not the case here.
  *   Based on my experience in SIP, it is VERY useful to have a dedicated response code for this (SIP defines ‘483 Too Many Hops’). Because, when this happens, it is often related to *network configuration and/or routing issues* – not to client implementation issues – so it is VERY useful information when trying to figure out why the message was rejected.

Regards,

Christer

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 16 Oct 2019 13:15:50 +0200

Hi Christer,

> I haven’t followed the hop-limit discussions, so I apologize if the following has already been discussed. I also know that my comments come very late in the process, so sorry for that.

Comments are always welcome — it is just less pain to process them when they are early…

> 	• Since you use a CoAP option, the mechanism can’t be used in an empty message.
> 	• I assume you don’t want to use the mechanism when sending a response, because then there is a risk that the client will not receive it.

Hop-Limit Options are indeed meant to be used in CoAP requests.
This needs to be made explicit (*), and it would be a good idea to more specifically talk about requests where the text right now talks about messages that are always requests.

(*) RFC 7252 is not a good role model here; not all descriptions of options make explicit whether the option can be used on requests, responses, or both.  This is certainly one item we can improve when we decide to generate a revision of that RFC.  We are collecting such issues in a github repository; this one now is https://github.com/core-wg/corrclar/issues/12

> The draft says that a CoAP message with the Hop-Limit option value set to 0 bigger than 255 must be rejected with a 4.00 Bad Request response.

There are two cases here: 0, and > 255.  The latter would be a syntax error for this option; the option description clearly limits the value to a single byte (Table 1).  Zero is not a syntax error, but a value that the authors chose to disallow.

> 	• Is 4.00 really an appropriate response code? When reading the HTTP definition for 400 Bad Request (CoAP inherits the semantics), it is about a client error (miss formed message, etc), which is not the case here.

A syntax error or a disallowed value in a request is a client error, no?

> 	• Based on my experience in SIP, it is VERY useful to have a dedicated response code for this (SIP defines ‘483 Too Many Hops’).

We do have one for this case: TBA1 | Hop Limit Reached
But this is different from a syntax error.

> Because, when this happens, it is often related to *network configuration and/or routing issues* – not to client implementation issues – so it is VERY useful information when trying to figure out why the message was rejected.

Specific response codes are useful if you want specific state machine transitions to happen, but causing a protocol violation is not really normal behavior, so all we need here are diagnostics.
Please see Sections 5.5.2 and 5.9.2 of RFC 7252.
Section 4 of the draft does define a diagnostic payload for TBA1 | Hop Limit Reached; it could also say something about the bad request case, but maybe the general advice in RFC 7252 is sufficient here.

Grüße, Carsten

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Oct 2019 11:26:07 +0000

Hi,

    > There are two cases here: 0, and > 255.  The latter would be a syntax error for this option; the option description clearly limits the value to 
    > a single byte (Table 1).  Zero is not a syntax error, but a value that the authors chose to disallow.
    >
    >> 	• Is 4.00 really an appropriate response code? When reading the HTTP definition for 400 Bad Request (CoAP inherits the semantics), it 
    >>       is about a client error (miss formed message, etc), which is not the case here.
    >

    The client may have included a valid value, but due to too many hops it reached 0. That is not a client error in my opinion.

    Sure, if the value is larger than 255 I guess 4.00 would be ok, because that is a protocol violation.

    > But this is different from a syntax error.

    Yes, I noticed that (and just sent a reply about it).

    But, again, if the value reaches 0, shouldn't TBA1 be used instead of 4.00? 

    >> Because, when this happens, it is often related to *network configuration and/or routing issues* – not to client implementation
    >> issues – so it is VERY useful information when trying to figure out why the message was rejected.
    >
    > Specific response codes are useful if you want specific state machine transitions to happen

    Specific response codes are also very useful for debugging - especially in this case where one probably should start by looking at the network/routing configurations instead of the endpoint implementations.

Regards,

Christer

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 16 Oct 2019 13:37:16 +0200

(Responding just to that specific item now:)

> On Oct 16, 2019, at 13:26, Christer Holmberg <[email-masked]> wrote:
> 

When designing CoAP, we made a very conscious decision to separate protocol elements such as response codes from diagnostic information.  Creating a new response code just for better diagnostics would be out of character for CoAP.

(Frugality in assigning response codes is a prerequisite to getting by with a small code space, e.g., only 32 possible codes for client errors.  Moreover, the design guideline pointed out above is generally a good idea, as it keeps the state machine clean and also allows permissionless innovation in diagnostic information.)

Grüße, Carsten

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Oct 2019 11:42:57 +0000

Hi,

 >>  Specific response codes are also very useful for debugging - especially in this case where one probably 
 >> should start by looking at the network/routing configurations instead of the endpoint implementations.
 >   
 >   When designing CoAP, we made a very conscious decision to separate protocol elements such as response
 >   codes from diagnostic information.  Creating a new response code just for better diagnostics would be out of character for CoAP.
 
  Then one could question the presence of the existing response codes too. But, that would be a waste of time, so let's skip that :)

  Anyway, Q2 has been clarified, so I withdraw the comment. Sorry for the confusion.

  Regards,

  Christer

---

From: <[email-masked]>
Date: Wed, 16 Oct 2019 11:44:56 +0000

Hi Christer, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : core [mailto:[email-masked]] De la part de Christer Holmberg
> Envoyé : mercredi 16 octobre 2019 13:26
> À : Carsten Bormann
> Cc : [email-masked]
> Objet : Re: [core] A couple of late comments on Hop-Limit
> 
> Hi,
> 
>     >> Q2:
>     >>
>     >> The draft says that a CoAP message with the Hop-Limit option value
> set to 0 bigger than 255 must be rejected with a 4.00 Bad Request response.
>     >
>     > There are two cases here: 0, and > 255.  The latter would be a syntax
> error for this option; the option description clearly limits the value to
>     >> 	• Is 4.00 really an appropriate response code? When reading the
> HTTP definition for 400 Bad Request (CoAP inherits the semantics), it
>     The client may have included a valid value, but due to too many hops it
> reached 0. That is not a client error in my opinion.

[Med] Even in that case, this is still a client error (not the original client, but the client component of the proxy that violated the following):

   MUST NOT be forwarded if the Hop-Limit option is set to
   '0' after decrement.

The node that receives such message does not know (necessarily) that the request is coming from the original client or whether it is relayed by a proxy. 

>     >> 	• Based on my experience in SIP, it is VERY useful to have a
> dedicated response code for this (SIP defines ‘483 Too Many Hops’).
>     >

[Med] Yes, TBA1 will be issued by the proxy which exhausted the hop-limit. In the meantime, the message with exhausted hop-limit must not forwarded upstream. 

> 
>     >> Because, when this happens, it is often related to *network
> configuration and/or routing issues* – not to client implementation
>     Specific response codes are also very useful for debugging - especially
> in this case where one probably should start by looking at the
> network/routing configurations instead of the endpoint implementations.
> 
> Regards,
> 
> Christer
> 
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Oct 2019 11:47:07 +0000

Hi,

...

    >   MUST NOT be forwarded if the Hop-Limit option is set to '0' after decrement.
    > 

    Correct. My mistake.

    Regards,

    Christer

---

From: <[email-masked]>
Date: Wed, 16 Oct 2019 11:50:37 +0000

Re-,

Great. 

FWIW, I take the point to double check the usage of "messages" to make it explicit it is about "requests". 

Thank you for the comments.

Cheers,
Med

> De : Christer Holmberg [mailto:[email-masked]]
> Envoyé : mercredi 16 octobre 2019 13:47
> À : BOUCADAIR Mohamed TGI/OLN; Carsten Bormann
> Cc : [email-masked]
>     > [Med] Even in that case, this is still a client error (not the
> original client, but the client component of the proxy that violated the
> following):
>     >
>     > The node that receives such message does not know (necessarily) that
> the request is coming from the original client or whether it is relayed by
> a proxy.
> 
>     Correct. My mistake.
> 
>     Regards,
> 
>     Christer
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 16 Oct 2019 10:54:35 -0500

On 10/16/19 5:13 AM, Christer Holmberg wrote:
>
> Hi,
>
> I haven’t followed the hop-limit discussions, so I apologize if the 
> following has already been discussed. I also know that my comments 
> come very late in the process, so sorry for that.
>

I do!

> Q2:
>
> The draft says that a CoAP message with the Hop-Limit option value set 
> to 0 bigger than 255 must be rejected with a 4.00 Bad Request response.
>
>   * Is 4.00 really an appropriate response code? When reading the HTTP
>     definition for 400 Bad Request (CoAP inherits the semantics), it
>   * Based on my experience in SIP, it is VERY useful to have a
>     dedicated response code for this (SIP defines ‘483 Too Many
>     Hops’). Because, when this happens, it is often related to
>     **network configuration and/or routing issues** – not to client
>     implementation issues – so it is VERY useful information when
>     trying to figure out why the message was rejected.
>

So, keep in mind that properly-implemented instances of this 
specification will never try to put a zero on the wire: an 
implementation that receives a message with a Hop-Count of 1 that would 
otherwise forward it are required to forego such forwarding by the final 
paragraph of section 3. (The notion of "greater than 255" doesn't exist, 
since you can't communicate a value greater than 255 in an 8-bit 
unsigned field). This is generally going to trigger a TBA1 (probably 
5.08) response.

That means that a "Hop-Count" of zero is semantically nonsense, and 
arguably a malformed message. This is analogous to an HTTP proxy 
corrupting a message on the way to its destination such that it cannot 
be interpreted by the recipient, a situation that would also trigger a 
400 response.

All of which is to say that I think the 4.00 response to a Hop-Count of 
0 is the correct behavior.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Oct 2019 16:12:31 +0000

Hi Adam,

You are correct. I thought one would send the response when receiving 0, but then realized that one is not supposed to receive a 0. It would be a protocol error, so a Bad Request response is fine.

So Q2 withdrawn.

Regards,

Christer

From: "[email-masked]" <[email-masked]>
Date: Wednesday, 16 October 2019 at 18.54
To: Christer Holmberg <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: A couple of late comments on Hop-Limit

I do!

Q2:

So, keep in mind that properly-implemented instances of this specification will never try to put a zero on the wire: an implementation that receives a message with a Hop-Count of 1 that would otherwise forward it are required to forego such forwarding by the final paragraph of section 3. (The notion of "greater than 255" doesn't exist, since you can't communicate a value greater than 255 in an 8-bit unsigned field). This is generally going to trigger a TBA1 (probably 5.08) response.

That means that a "Hop-Count" of zero is semantically nonsense, and arguably a malformed message. This is analogous to an HTTP proxy corrupting a message on the way to its destination such that it cannot be interpreted by the recipient, a situation that would also trigger a 400 response.

All of which is to say that I think the 4.00 response to a Hop-Count of 0 is the correct behavior.

/a