Subject: Re: [core] BG1 -- CoAP Ping (Re: draft-ietf-core-coap-13 WGLC - my comments)

From: Bert Greevenbosch <[email-masked]>
Date: Fri, 4 Jan 2013 03:17:39 +0000

Hi Carsten,

I agree that we should not define a separate NOOP method just for verification if the server is running.

I guess the following text is what makes the suggested method work:

   A Confirmable message
   always carries either a request or response and MUST NOT be empty.  A
   recipient MUST acknowledge such a message with an Acknowledgement
   message or, if it lacks context to process the message properly
   (including the case where the message is empty or has a message
   format error), MUST reject it; rejecting a Confirmable message is
   effected by sending a matching Reset message and otherwise ignoring
   it.

I don't feel too strong about this. It is just that the spec seems to endorse violating its own MUST NOTs. But that discussion might be more philosophical than it is technical...

Happy new year!
Bert

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: 21 December 2012 15:36
To: Bert Greevenbosch
Cc: [email-masked] WG
Subject: BG1 -- CoAP Ping (Re: [core] draft-ietf-core-coap-13 WGLC - my comments)

Hi Bert,

I'll pick some of your comments and reply with my personal view.
I'll construct a separate subject for each so we have some threading if the discussion continues.

On Dec 21, 2012, at 03:42, Bert Greevenbosch <[email-masked]> wrote:

> 1,E) p.9: "Provoking a Reset message (e.g., by sending an empty Confirmable message) is also useful as an inexpensive check of the liveness of an endpoint ("CoAP ping")."
> I am not sure if we should endorse provoking RST messages by sending empty CON messages.

We have found that it is very useful to have some lightweight "are you there" mechanism.
This is both for diagnostics, and for address selection ahead of a heavy-weight non-idempotent operation.

Now we could define a NOOP method that does nothing.  In a Confirmable message, this would elicit an empty ACK.
In total, this would look a lot like the mechanism described above, but with a "positive" ACK.
4-byte request, 4-byte ACK.

However, the empty/RST exchange has essentially the same properties, with the simple advantage that you already (should) have implemented it.
One method less, requires no additional code.
Calling it out here was motivated by noticing that not every implementation before ETSI CoAP2 caught the MUSTs that make it work.

One could argue that a ping that "works" should not end in an "error" message like RST.
However, there are other cases where a RST is somewhat "normal", so seeing a RST should not be raising red alarms anyway.

So I agree a bit with the sentiment you are expressing, but I think it is not sufficient reason to add a NOOP method.
(I also briefly thought about instead adding an ECHO method (sends back the payload) so you can run diagnostics with different packet sizes.
With a payload of 0 bytes, this becomes similar to NOOP, except that the ACK would carry a response code.
Also sounds somewhat useful, but do we really need it?  
We most likely don't want an equivalent of CHARGEN, as this would be inviting amplification attacks.)

Grüße, Carsten

---

From: Andrew McGregor <[email-masked]>
Date: Fri, 4 Jan 2013 16:45:45 +1300

Simply deleting the "and MUST NOT be empty" from the first sentence you quote would make it unambiguous that an empty message is allowed, and must be rejected.

Andrew

On 4/01/2013, at 4:17 PM, Bert Greevenbosch <[email-masked]> wrote:

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

---

From: Zach Shelby <[email-masked]>
Date: Fri, 4 Jan 2013 11:01:12 +0200

Andrew,

That would be a reasonable solution. I would suggest we create a ticket to solve Bert's comment in this way.

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: +358 40 7796297
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net

---

From: Bert Greevenbosch <[email-masked]>
Date: Mon, 7 Jan 2013 00:50:11 +0000

Hi Andrew, Zach,

Indeed this solution is OK. Let's fix it this way.

Best regards,
Bert

-----Original Message-----
From: Zach Shelby [mailto:[email-masked]] 
Sent: 04 January 2013 17:01
To: Andrew McGregor
Cc: Bert Greevenbosch; [email-masked] WG
Subject: Re: [core] BG1 -- CoAP Ping (Re: draft-ietf-core-coap-13 WGLC - my comments)

Andrew,

Zach

---

From: Bert Greevenbosch <[email-masked]>
Date: Tue, 8 Jan 2013 00:37:52 +0000

Hi Carsten,

Thank you for your explanation about NSTART.

I see the requirement of limiting the amount of outstanding interactions as a means for congestion control.

I have also reviewed the history of NSTART and PROBING_RATE. Both were added in coap-12 as a resolution to ticket #215. According to the Vancouver minutes, the value NSTART=1 was proposed for devices that cannot estimate the RTT. It was also proposed to consider a higher value for devices that can estimate the RTT.

A problem with NSTART=1 may be a server that returns piggybacked responses that need some processing time. For example, a server (or reverse proxy) may provide two different resources, both of which are independent but require one second to collect their information. With NSTART=1, this would mean that the client can only request the second resource after at least one second, even when there is no congestion.

I guess this issue also hangs together with the time threshold above which the server should refrain from piggybacking. That, however, is explicitly left out of scope of scope of the spec, see section 5.2.1.

Fortunately the draft only defines a default values for NSTART and PROBING_RATE, which can be overridden upon more extensive knowledge/experience of CoAP congestion control. But, although the default values can be overridden, the text about NSTART uses MUSTs and SHALLs, implying that each implementation has to support them, requiring code for the book keeping.

Best regards,
Bert

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: 21 December 2012 17:24
To: Bert Greevenbosch
Cc: [email-masked] WG
Subject: BG8 -- NSTART=1 (Re: [core] draft-ietf-core-coap-13 WGLC - my comments)

On Dec 21, 2012, at 03:42, Bert Greevenbosch <[email-masked]> wrote:

> 8,T) NSTART=1 implies that you cannot send a bulk of requests at once. Is this the intention,

Yes.

> or would a small but higher value of NSTART still be acceptable?

According to RFC 5405, no.
However, this is qualified for a 3-second interval, so there may be some leeway here.

What happens is this:
The first request goes out.  If it is acknowledged, the counter limited by NSTART (we need a name for that) goes back to 0 and we can send the second request.
If it isn't, we retransmit the first request after 2-3 seconds, so we continue to use up the RFC 5405 limit.
If the first retransmission of the first request is acknowledged, we can send the second request.
If not, we might be able to squeeze in a second request if we only want to stick to the letter of RFC 5405.
However, the point of BEBO is to actually slow down in the face of losses, so this shouldn't be overdone.
If we have to do this, it may be a good idea to operate the second request on the BEBO schedule of the first request (i.e., stick to the maximum of the BEBO variables per peer).

Of course, the 3 seconds of RFC 5405 were picked out of thin air at a time when people weren't thinking that much about constrained networks.
Maybe it actually is too low (i.e., too high a rate) for us!

But, actually, clamping down NSTART to 1 if you know nothing about path or peer is a *feature*.  
The poor server receiving those requests has to process them.  It may only have one buffer.
If a new request comes in before it had a chance to respond to the first one, it will essentially have to drop the packet (or trash the old request).
(And similar considerations may apply to constrained routers on the way.)

Grüße, Carsten

---

From: Bert Greevenbosch <[email-masked]>
Date: Tue, 8 Jan 2013 01:10:51 +0000

Hi Carsten,

I have reviewed the NSTART and PROBING_RATE backgrounds together, but I thought it's will be best to keep the threads separated.

As mentioned in my other e-mail, I have reviewed the history of NSTART and PROBING_RATE. Both entities were added in coap-12 as a resolution to ticket #215. The ticket history indeed mentions NSTART, but I couldn't find anything about PROBING_RATE. The same holds for the minutes from the Vancouver meeting. How did PROBING_RATE come into being?

I am still not convinced about PROBING_RATE, especially its dependence on the message size. Restricting (re)transmissions based on data size makes sense for applications such as streaming, where a lot of data is transmitted in subsequent RTP packets. In that case, the amount of data per time unit (thereby the amount of packets) could be restricted in order to reduce congestion. However, for CoAP, where we normally talk about a few messages (per client/server pair) of limited size, I think it is more appropriate to put a limit on the number of messages per time unit, than making it dependent on the message size.

How about setting a RECOMMENDED minimum time between subsequent outstanding interactions, for example the 3s mentioned in RFC 5405?

Best regards,
Bert

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: 21 December 2012 17:34
To: Bert Greevenbosch
Cc: [email-masked] WG
Subject: BG7 -- PROBING_RATE (Re: [core] draft-ietf-core-coap-13 WGLC - my comments)

This may actually mainly be an editorial problem.

On Dec 21, 2012, at 03:42, Bert Greevenbosch <[email-masked]> wrote:

> 7,T) p.25: "Unless this is modified by additional congestion control optimizations, it MUST be chosen in such a way that an endpoint does not exceed an average data rate of PROBING_RATE in sending to another endpoint that does not respond."

You are quoting this out of context.

The context is:

   In order not to cause congestion, Clients (including proxies) MUST
   strictly limit the number of simultaneous outstanding interactions
   that they maintain to a given server (including proxies) to NSTART.
   An outstanding interaction is either a CON for which an ACK has not
   yet been received but is still expected (message layer) or a request
   for which neither a response nor an Acknowledgment message has yet
   been received but is still expected (which may both occur at the same
   time, counting as one outstanding interaction).  The default value of
   NSTART for this specification is 1.

Now this is the text that explains how to handle non-responding peers:

   A client stops expecting a response to a Confirmable request for
   which no acknowledgment message was received, after
   EXCHANGE_LIFETIME.  The specific algorithm by which a client stops to
   "expect" a response to a Confirmable request that was acknowledged,
   or to a Non-confirmable request, is not defined.  Unless this is
   modified by additional congestion control optimizations, it MUST be
   chosen in such a way that an endpoint does not exceed an average data
   rate of PROBING_RATE in sending to another endpoint that does not
   respond.

So:

1) If a Confirmable request times out, you reset the NSTART counter (for which we still need a name) to 0 after EXCHANGE_LIFETIME.
2) For Non-confirmables, we don't have a timeout.  So we use PROBING_RATE to decay the NSTART counter.

> p.26, in the table: "PROBING_RATE = 1 Byte/second".

Yes, that is quite conservative.  I had 7 bytes/second, but there was some transport input that this might be too much.

> p.21: "Retransmission is controlled by two things that a CoAP endpoint MUST keep track of for each Confirmable message it sends while waiting for an acknowledgement (or reset): a timeout and a retransmission counter. For a new Confirmable message, the initial timeout is set to a random counter between ACK_TIMEOUT and (ACK_TIMEOUT*ACK_RANDOM_FACTOR) (see Section 4.8), and the retransmission counter is set to 0. When the timeout is triggered and the retransmission counter is less than MAX_RETRANSMIT, the message is retransmitted, the retransmission counter is incremented, and the timeout is doubled. If the retransmission counter reaches MAX_RETRANSMIT on a timeout, or if the endpoint receives a Reset message, then the attempt to transmit the message is canceled and the application process informed of failure."

Well, this is unrelated; none of this is controlled by PROBING_RATE.

> It seems that PROBING_RATE is another constraint on top of what is defined on p.21, since the algorithm of p.21 alone would already violate the probing rate, especially at the beginning of the retransmissions.

This is the editorial issue: We need to make clear that these two don't interact.

> Is 1 Byte/second reasonable? Does it mean that a 16 byte CoAP message needs at least 16 seconds between two subsequent retransmissions? Over which time frame is the PROBING_RATE calculated?

Actually, there is a need for another clarification: The usage of PROBING_RATE needs to account for overhead.  So, for a 16 byte CoAP message, you would account 16+8+40 = 64 bytes (IPv6), so, the next one goes out only after 64 seconds or when the response is received, whatever comes earlier.

> Suggestion: remove PROBING_RATE.

PROBING_RATE is needed to keep some control over Non-confirmables.  I don't think we can take that away.
If you never send a Non-confirmable, you can ignore PROBING_RATE.

Grüße, Carsten

---

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 8 Jan 2013 08:18:06 +0000

Hi Bert, Carsten,

> I have reviewed the history of NSTART and PROBING_RATE. Both entities were added in coap-12 as a resolution to ticket #215.
> The ticket history indeed mentions NSTART, but I couldn't find anything about PROBING_RATE. The same holds for the minutes
> from the Vancouver meeting. How did PROBING_RATE come into being?
same question from me. I did not see PROBING_RATE mentioned in the ticket comments or elsewhere. Based on Ticket #215 alone it would not be needed, or do I miss something...?

Three more comments on PROBING_RATE:
1. the PROBING_RATE mechanism text is currently written with unicast in mind.
We should perhaps also indicate how CoAP multicast should handle it, e.g. clarify that a client can resend a multicast NON request (resending meaning the same Message ID) after receiving the first response from any server.

2. agree with Bert that the dependency on IPv6/6LoWPAN packet size seems unfortunate, because the CoAP stack typically wouldn't be able to compute that size. How would that work? I can imagine that doing this computation based on expected average or 'worst case' IPv6 header sizes for the given system configuration is more feasible then.

3. the 1Byte/second default limit seems on the low side? (suitable for 20th century technology ;) )
some discussion or clarification/justification for this value would help. E.g. why is CON allowed to send much more bytes per second than NON.

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bert Greevenbosch
Sent: Tuesday 8 January 2013 2:11
To: Carsten Bormann
Cc: [email-masked] WG
Subject: Re: [core] BG7 -- PROBING_RATE (Re: draft-ietf-core-coap-13 WGLC - my comments)

Hi Carsten,

Best regards,
Bert

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: 21 December 2012 17:34
To: Bert Greevenbosch
Cc: [email-masked] WG
Subject: BG7 -- PROBING_RATE (Re: [core] draft-ietf-core-coap-13 WGLC - my comments)

The context is:

So:

Grüße, Carsten

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 8 Jan 2013 08:23:32 +0000

Hi Bert,

> So only a new message (with a new message ID) needs to observe the probing rate?
I would say no, particularly a resent NON message needs to heed the probing rate.

> ...for which no ACK or response is received...
You probably mean 'response' here, as ACKs are only used with CON?

> ... However, resending *the same* message (as part of the CON resend mechanism)...
Also with NON, messages can be resent. E.g. useful for multicast requests for additional reliability. The CON resend mechanism is probably not relevant for this discussion based on Carsten's last remark ("... you can ignore PROBING_RATE.").

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bert Greevenbosch
Sent: Thursday 27 December 2012 10:28
To: Carsten Bormann
Cc: [email-masked] WG
Subject: Re: [core] BG7 -- PROBING_RATE (Re: draft-ietf-core-coap-13 WGLC - my comments)

Hi Carsten,

Thank you for your many answers to my comments.

I believe to understand that you mean, that the probing rate does not apply to messages that are resent as part as the CON resend mechanism. So only a new message (with a new message ID) needs to observe the probing rate?

What I mean is, when we send a 64 byte message, we need at least 64*PROBING_RATE = 64 seconds between sending two messages *with different message ids*, for which no ACK or response is received? However, resending *the same* message (as part of the CON resend mechanism) within this time is OK?

Why is the probing rate dependent on the message size? Can't we just set a fixed value for all messages?

Best regards,
Bert

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: 21 December 2012 17:34
To: Bert Greevenbosch
Cc: [email-masked] WG
Subject: BG7 -- PROBING_RATE (Re: [core] draft-ietf-core-coap-13 WGLC - my comments)

The context is:

So:

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 8 Jan 2013 23:01:21 +0100

Hi Bert,

I'm sorry for being so behind in my E-Mail.
Let me try to respond to the messages in this thread separately.

> I believe to understand that you mean, that the probing rate does not apply to messages that are resent as part as the CON resend mechanism. So only a new message (with a new message ID) needs to o…

Actually, PROBING_RATE was intended entirely about striking from the books those messages that are not benefitting from any ACK or response.
Without PROBING_RATE, you would never be able to send, e.g., another NON request if the first one gets lost.
It seems that the current text is not expressing this area of application very well.
It says "The specific algorithm by which a client stops to
  "expect" a response to a Confirmable request that was acknowledged,
  or to a Non-confirmable request, is not defined."
PROBING_RATE doesn't govern anything else, including Confirmable requests that weren't acknowledged at all!

> What I mean is, when we send a 64 byte message, we need at least 64*PROBING_RATE = 64 seconds between sending two messages *with different message ids*, for which no ACK or response is received? Ho…

Yes to the latter.  No to the former if this is about CON -- the waiting for ACKs is supposed to take care of the rate-limiting.
(It still doesn't hurt to slow down probing if nothing is coming back at all.  But the intention was not to govern that case by PROBING_RATE.)

> Why is the probing rate dependent on the message size? Can't we just set a fixed value for all messages?

We could, but then we'd have to assume large messages and would have a very low message rate.
Since messages in CoAP are more likely to be small, that would limit us more than necessary.
(An implementation might still want to choose that behavior, if that is convenient.)

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 8 Jan 2013 23:08:44 +0100

> As mentioned in my other e-mail, I have reviewed the history of NSTART and PROBING_RATE. Both entities were added in coap-12 as a resolution to ticket #215. The ticket history indeed mentions NSTAR…

There must be something slowing down unresponded NONs.  PROBING_RATE was meant for this.
I seem to remember proposing a PROBING_RATE of 7 B/s in Vancouver, only to be bid down to 1 B/s by people in the room.

> I am still not convinced about PROBING_RATE, especially its dependence on the message size. Restricting (re)transmissions based on data size makes sense for applications such as streaming, where a…

If you know your maximum message size, you can easily implement it this way by translating 1 B/s to, say, 0.01 message/s for 100-byte-max messages.

> How about setting a RECOMMENDED minimum time between subsequent outstanding interactions, for example the 3s mentioned in RFC 5405?

Well, RFC 5405 mentions

   | SHOULD measure RTT and transmit max. 1 datagram/RTT     |         |
   | else, SHOULD send at most 1 datagram every 3 seconds    |         |
   | SHOULD back-off retransmission timers following loss    |         |

which I take to mean stubbornly sending a packet every 3 s is not within the spirit of RFC 5405.

More importantly, a room full of sensors that all stubbornly send a packet every 3 s is a recipe for congestion collapse, independent of what RFC 5405 suggests or not (this brings up Lars' scenario of having to chisel the sensors out of the wall to end the congestion collapse).  So we need to find a way to slow down in case of no response, much beyond the 3 s default.  The current text tries to keep a lot of leeway for how to implement this.  1 B/s is a reasonably conservative way to approach this

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 8 Jan 2013 23:22:07 +0100

> same question from me. I did not see PROBING_RATE mentioned in the ticket comments or elsewhere. Based on Ticket #215 alone it would not be needed, or do I miss something...?

I hope I motivated this in the previous message.

> We should perhaps also indicate how CoAP multicast should handle it, e.g. clarify that a client can resend a multicast NON request (resending meaning the same Message ID) after receiving the first…

Those messages don't fall under the case of PROBING_RATE, right?

> 2. agree with Bert that the dependency on IPv6/6LoWPAN packet size seems unfortunate, because the CoAP stack typically wouldn't be able to compute that size. How would that work? I can imagine that…

If you can't compute (or guesstimate) it, use an overhead of 64 B.  This is going to be close enough.
If you know better, you can send faster.
Should we add this approach to the text?  I think we are moving into implementation approaches here...

> some discussion or clarification/justification for this value would help. E.g. why is CON allowed to send much more bytes per second than NON.

Good question.  I came into this with a proposal for 7 B/s...
CON can send 5 messages in TRANSMIT_WAIT, i.e. 62 to 93 s -- let's assume the randomness mostly works here.
Yes, these could be ~ 1280 bytes (for PUT, POST, or on the way back for a large GET response that consistently gets lost), so if you persistently retry right after the final timeout, the max average rate is about 1280*5/77.5 ~ 80 B/s.  Don't do that!
(We could extend PROBING_RATE to cover this case, but this would go into the wrong direction complexity-wise.)

But the complexity of PROBING_RATE doesn't change by giving it a different value.

Grüße, Carsten

---

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 9 Jan 2013 08:53:57 +0000

> I hope I motivated this in the previous message.
Yes, thanks.

> Those messages don't fall under the case of PROBING_RATE, right?
Do you mean multicast in general, or resent multicast requests (i.e. with the same Message ID) ?
The motivation "There must be something slowing down unresponded NONs" can be made a bit more precise then: e.g. it applies only to unicast NONs for which response is always expected to come. (Assuming multicast is excluded)

> If you can't compute (or guesstimate) it, use an overhead of 64 B.  This is going to be close enough.
Ok, the MUST requirement can be met by using an upper bound for the header overhead. If guesstimates (of expected avg header overhead) can also be used, perhaps the text should indicate this.

> CON can send 5 messages in TRANSMIT_WAIT, ...
> ... these could be ~ 1280 bytes
So an upper bound for PROBING_RATE would be 80 B/s to be equal to the CON case on 'unconstrained' networks.
Then for 6LoWPAN 802.15.4 networks, assuming an IPv6 packet size of about 80-120B, PROBING_RATE would be 5-8 B/s. So the value 8 would seem more logical to me; but I missed the discussion details from the meeting.

Agree that adjusting PROBING_RATE is the least complex solution to improve/optimize throughput.

Esko

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Tuesday 8 January 2013 23:22
To: Dijk, Esko
Cc: Bert Greevenbosch; [email-masked] WG
Subject: Re: [core] BG7 -- PROBING_RATE (Re: draft-ietf-core-coap-13 WGLC - my comments)

On Jan 8, 2013, at 09:18, "Dijk, Esko" <[email-masked]> wrote:

>> The ticket history indeed mentions NSTART, but I couldn't find
>> anything about PROBING_RATE. The same holds for the minutes from the Vancouver meeting. How did PROBING_RATE come into being?

> 3. the 1Byte/second default limit seems on the low side? (suitable for
> 20th century technology ;) ) some discussion or clarification/justification for this value would help. E.g. why is CON allowed to send much more bytes per second than NON.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 9 Jan 2013 21:43:22 +0100

> Simply deleting the "and MUST NOT be empty" from the first sentence you quote would make it unambiguous that an empty message is allowed, and must be rejected.

In [1152], I'm proposing a slightly different approach:
Since the "always carries either a request or response" also is not true in the CoAP ping case, it is probably better to qualify the whole sentence:

         message as Confirmable in the CoAP header. A Confirmable message
-        always carries either a request or response and MUST NOT be empty. A
+        always carries either a request or response and MUST NOT be
+        empty, unless it is used only to elicit a Reset message. A
         recipient MUST acknowledge such a message with an Acknowledgement
         message or, if it lacks context to process the message
         properly (including the case where the message is empty or has

I hope this completely resolves this.

Grüße, Carsten

---

From: "Rahman, Akbar" <[email-masked]>
Date: Wed, 9 Jan 2013 16:44:49 -0500

Hi Carsten/Zach,

I have a clarification question on Appendix B (URI Examples) of coap-13:

- For examples 2-4, what is the purpose of listing the "Destination IP
Address" and "Destination UDP Port"?

- That is, for these examples, the URI is constructed without any
reference to the IP Address and UDP Port.  So it is confusing.  

- Of course, for the 1st and 5th examples having the IP Address and UDP
Port makes perfect sense as they are used in the example URI
construction.

Or did I somehow misunderstand the examples?

Akbar

---

From: Klaus Hartke <[email-masked]>
Date: Thu, 10 Jan 2013 00:06:32 +0200

Hi Akbar,

> Port makes perfect sense as they are used in the example URI

Appendix B shows examples for the algorithm specified in Section 6.5.
Section 6.5 refers to the destination IP address and port in step 2
and 4 respectively. But not all paths of the algorithm cause the
destination IP address and port to be included in the URI result.

   2.  ... If
        the request does not include a Uri-Host Option, let /host/ be
        the IP-literal (making use of the conventions of [RFC5952]) or
        IPv4address representing the request's destination IP address.

   4.   If the request includes a Uri-Port Option, let /port/ be that
        option's value.  Otherwise, let /port/ be the request's
        destination UDP port.

Although the intro of Appendix B says that the examples are for
constructing an URI from options, the examples also work for Section
6.4 + DNS resolution. Then the input is the URI and the outputs are
the options and the destination IP address and port for the request.

Best regards,
Klaus

---

From: "Rahman, Akbar" <[email-masked]>
Date: Wed, 9 Jan 2013 17:12:41 -0500

Hi Klaus,

Thanks for the explanation, and it makes sense now.  But also I think
you have to add a better intro for Appendix B or the next reader (not
subscribed to this list) will have the same issue as I did.  Do you
agree?

/Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Klaus Hartke
Sent: Wednesday, January 09, 2013 5:07 PM
To: [email-masked]
Subject: Re: [core] Question on Appendix B (Re: draft-ietf-core-coap-13
WGLC)

Hi Akbar,

   2.  ... If

Best regards,
Klaus

---

From: Klaus Hartke <[email-masked]>
Date: Thu, 10 Jan 2013 00:19:40 +0200

> subscribed to this list) will have the same issue as I did.  Do you

Yes, the current text (or lack thereof) has already confused a few
people. Text suggestions to improve the appendix are highly welcome.

Best regards,
Klaus

---

From: Bert Greevenbosch <[email-masked]>
Date: Thu, 10 Jan 2013 00:14:25 +0000

Hi Carsten,

Yes, indeed the empty message does not qualify as a request or response. The new text is better.

Best regards,
Bert

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: 10 January 2013 04:43
To: Andrew McGregor
Cc: Bert Greevenbosch; [email-masked] WG
Subject: Re: [core] BG1 -- CoAP Ping (Re: draft-ietf-core-coap-13 WGLC - my comments)

Grüße, Carsten

---

From: Bert Greevenbosch <[email-masked]>
Date: Thu, 10 Jan 2013 05:49:53 +0000

Hi Carsten,

Thank you for your feedback.

I have listened to the recordings of the Friday meeting in Vancouver. Indeed there has been an extensive discussion on congestion control; however there was not much decided. The main thread in the discussion was, that you need at least an RTT estimator to do something clever. People were suggesting various ways, including mixing CONs and NONs and using the RTT of CONs to evaluate the network condition.

The outcome of the discussion was, that we need more knowledge/work to create suitable congestion control guidelines. A task force was setup, which was to provide a separate document with guidelines for congestion control.

A 7 B/s limit was briefly mentioned as "NSTART decay" (slide 98) and as a conservative limit for unidirectional (slide 100). The former was briefly discussed, whereas the latter only mentioned. From the recordings, I cannot conclude there was group consensus on PROBING_RATE.

The dependence on size of the PROBING_RATE leads to different time-outs for different messages, unless messages have a fixed size. This implies that the client needs to maintain separate timing information for each request. One can indeed use a fixed estimate for the maximum message size, and in this way convert PROBING_RATE from B/s to messages/s. It will lead to an even lower rate than would have been possible without the conversion.

After conversion, the PROBING_RATE mechanism is essentially a linear scheme. It is similar to the 3s resend mechanism mentioned below, though with a much lower (yet arbitrary!) default value. Unlike with the exponential back-off scheme, if the connection is congested while all clients are sending at PROBING_RATE, there is nothing the clients will do to reduce the congestion.

I truly think that defining the PROBING_RATE mechanism in the base CoAP spec is premature. Neither the default value nor de unit "B/s" has a solid quantitative background. In fact, during the Vancouver discussion most people talked naturally about messages/second. I think it is better to do something more clever in the separate document mentioned above.

Best regards,
Bert

Slides: http://www.ietf.org/proceedings/84/slides/slides-84-core-0.pdf
Recordings: http://www.ietf.org/audio/ietf84/ietf84-regencyf-20120803-0900-am1.mp3

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: 09 January 2013 06:09
To: Bert Greevenbosch
Cc: [email-masked] WG
Subject: Re: BG7 -- PROBING_RATE (Re: [core] draft-ietf-core-coap-13 WGLC - my comments)

Well, RFC 5405 mentions

Grüße, Carsten

---

From: Maciej Wasilak <[email-masked]>
Date: Mon, 28 Jan 2013 20:42:51 +0100

Hello,

I think we should add text that server MUST echo the token from the last
client request in every separate response block. Without it it's hard to
tell apart two incoming blockwise responses (even for different resources).

Best Regards
Maciej Wasilak

2012/12/27 Bert Greevenbosch <[email-masked]>

> Hi Carsten,
>
> <quote>
> We had a long discussion of this in Sophia-Antipolis (ETSI CoAP2).
> This needs to be fixed in -block.
> ...
> The conclusion from this discussion was that it is a good thing to keep
> empty ACKs empty so they can be left out when running CoAP over alternate
> transports that have their own reliability mechanisms, such as SMS or TCP.
> </quote>
>
> Yes, that makes a lot of sense. Then indeed it is best to fix it in the
> Block draft.
>
> B.T.W. The below sequence could also make sense when the client sent a
> PUT/POST request without Block, but the server needs to use Block in its
> response. Would it then would be something like below?
>
> CLIENT                                                SERVER
>   |                                                     |
>   | CON [MID=1234], POST, /soap                 ------> |
>   |                                                     |
>   | <------   ACK [MID=1236], 0                         |
>   |                                                     |
>   | <------   CON [MID=4712], 2.01 Created, 2/0/1/128   |
>   |                                                     |
>   | ACK [MID=4712], 0                           ------> |
>   |                                                     |
>   | <------   CON [MID=4713], 2.01 Created, 2/1/1/128   |
>   |                                                     |
>   | ACK [MID=4713], 0                           ------> |
>   |                                                     |
>   | <------   CON [MID=4714], 2.01 Created, 2/2/1/128   |
>   |                                                     |
>   | ACK [MID=4714], 0                           ------> |
>   |                                                     |
>   | <------   CON [MID=4715], 2.01 Created, 2/3/0/128   |
>   |                                                     |
>   | ACK [MID=4715], 0                           ------> |
>
> Best regards,
> Bert
>
> Sent: 21 December 2012 15:47
> To: Bert Greevenbosch
> Cc: [email-masked] WG
> Subject: BG4 -- empty ACKs (Re: [core] draft-ietf-core-coap-13 WGLC - my
> comments)
>
> > 4,T) p.21: "An empty message has a Code field set to 0. The Token Length
> field MUST be set to 0 and no bytes MUST be present after the Message ID
> field. If there are any bytes, they MUST be processed as a message format
> error."
> > p.32: "The Acknowledgement to the Confirmable response MUST also be an
> empty message, i.e. one that carries neither a request nor a response."
> > This is violated by figure 10 in the block-10 draft, where a block
> option is included in the ACK from a CON response. Change here or in block?
>
> We had a long discussion of this in Sophia-Antipolis (ETSI CoAP2).
> This needs to be fixed in -block.
> (See my notes below.)
>
> > Maybe there will be future options that may need inclusion in ACKs to
> CON responses too?
>
> The conclusion from this discussion was that it is a good thing to keep
> empty ACKs empty so they can be left out when running CoAP over alternate
> transports that have their own reliability mechanisms, such as SMS or TCP.
>
> Grüße, Carsten
>
>
> Fixed examples for Block1-Block2 interaction:
> (Needs to add discussion of "Initiative".)
>
>
> Block options may be used in both directions of a single exchange.
> The following example demonstrates a blockwise POST request, resulting
> in a separate blockwise response.
>
> ~~~~~~~~~~~
> CLIENT                                                     SERVER
>   |                                                              |
>   | CON [MID=1234], POST, /soap, 1/0/1/128      ------>          |
>   |                                                              |
>   | <------   ACK [MID=1234], 2.01 Created, 1/0/1/128            |
>   |                                                              |
>   | CON [MID=1235], POST, /soap, 1/1/1/128      ------>          |
>   |                                                              |
>   | <------   ACK [MID=1235], 2.01 Created, 1/1/1/128            |
>   |                                                              |
>   | CON [MID=1236], POST, /soap, 1/2/0/128      ------>          |
>   |                                                              |
>   | <------   ACK [MID=1236], 0                                  |
>   |                                                              |
>   | <------   CON [MID=4712], 2.01 Created, 2/0/1/128, 1/2/0/128 |
>   |                                                              |
>   | ACK [MID=4712], 0                           ------>          |
>   |                                                              |
>   | <------   CON [MID=4713], 2.01 Created, 2/1/1/128            |
>   |                                                              |
>   | ACK [MID=4713], 0                           ------>          |
>   |                                                              |
>   | <------   CON [MID=4714], 2.01 Created, 2/2/1/128            |
>   |                                                              |
>   | ACK [MID=4714], 0                           ------>          |
>   |                                                              |
>   | <------   CON [MID=4715], 2.01 Created, 2/3/0/128            |
>   |                                                              |
>   | ACK [MID=4715], 0                           ------>          |
> ~~~~~~~~~~~
> {: #post-response title="Atomic blockwise POST with separate blockwise
> response" }
>
> This model does provide for early negotiation input to the
>
> ~~~~~~~~~~~
> CLIENT                                                     SERVER
>   |                                                             |
>   | CON [MID=1234], POST, /soap, 1/0/1/128 ------>              |
>   |                                                             |
>   | <------   ACK [MID=1234], 2.01 Created, 1/0/1/128           |
>   |                                                             |
>   | CON [MID=1235], POST, /soap, 1/1/1/128 ------>              |
>   |                                                             |
>   | <------   ACK [MID=1235], 2.01 Created, 1/1/1/128           |
>   |                                                             |
>   | CON [MID=1236], POST, /soap, 1/2/0/128, 2/0/0/64 ------>    |
>   |                                                             |
>   | <------   ACK [MID=1236], 0                                 |
>   |                                                             |
>   | <------   CON [MID=4712], 2.01 Created, 1/2/0/128, 2/0/1/64 |
>   |                                                             |
>   | ACK [MID=4712], 0                           ------>         |
>   |                                                             |
>   | <------   CON [MID=4713], 2.01 Created, 2/1/1/64            |
>   |                                                             |
>   | ACK [MID=4713], 0                           ------>         |
>   |                                                             |
>   | <------   CON [MID=4714], 2.01 Created, 2/2/1/64            |
>   |                                                             |
>   | ACK [MID=4714], 0                           ------>         |
>   |                                                             |
>   | <------   CON [MID=4715], 2.01 Created, 2/3/0/64            |
>   |                                                             |
>   | ACK [MID=4715], 0                           ------>         |
> ~~~~~~~~~~~
> {: #post-response-e title="Atomic blockwise POST with separate blockwise
> response, early negotiation" }
>
> THERE IS NO LATE NEGOTIATION...
>
>