Subject: Re: [core] #177: Response suppression for multicast not defined

From: "core issue tracker" <[email-masked]>
Date: Mon, 12 Mar 2012 16:25:14 -0000

#177: Response suppression for multicast not defined

Changes (by cabo@…):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 Fixed in [524]:

 Fix #177

-- 
--------------------------------+-------------------------------------
 Reporter:  cabo@…              |       Owner:  draft-ietf-core-coap@…
     Type:  protocol defect     |      Status:  closed
 Priority:  major               |   Milestone:
Component:  coap                |     Version:
 Severity:  Active WG Document  |  Resolution:  fixed
 Keywords:                      |
--------------------------------+-------------------------------------

Ticket URL: </ticket/177#comment:1>
core <http://tools.ietf.org/core/>

---

From: "Rahman, Akbar" <[email-masked]>
Date: Mon, 12 Mar 2012 14:40:09 -0400

Hi Carsten,

Could you please clarify exactly what change was incorporated into http://tools.ietf.org/html/draft-ietf-core-coap-08?

When I look at the Fix #177 cited below 

http://www.ietf.org/mail-archive/web/core/current/msg02382.html

it refers to 

	"So yes, I think there should be new text in 4.4 that says the reliability
 	layer does indicate to the r/r layer that this was a multicast."

I did not see this type of text in section 4.4 however.  But maybe I a m missing something?

Thanks,

Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of core issue tracker
Sent: Monday, March 12, 2012 12:25 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [core] #177: Response suppression for multicast not defined

Changes (by cabo@…):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 Fixed in [524]:

 Fix #177

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

---

From: Zach Shelby <[email-masked]>
Date: Mon, 12 Mar 2012 21:32:58 +0200

Hi Akbar,

These changes are being checked into the SVN as they are closed, and will show up in the coap-09 submission tonight. By the way, the SVN is accessible by anyone if you are ever interested in changes as we close tickets on WG documents:

http://trac.tools.ietf.org/wg/core/trac/browser

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: "Rahman, Akbar" <[email-masked]>
Date: Mon, 12 Mar 2012 15:41:43 -0400

Thanks, Zach.  I will then make sure to read the updated I-D after you
submit it tonight.  Esko and I have some text in our Groupcomm I-D for
multicast support (on the topic of multicast response handling) that we
want to make sure is well coordinated with the coap-09 I-D.

Akbar

-----Original Message-----
From: Zach Shelby [mailto:[email-masked]] 
Sent: Monday, March 12, 2012 3:33 PM
To: Rahman, Akbar
Cc: core issue tracker; core WG
Subject: Re: [core] #177: Response suppression for multicast not defined

Hi Akbar,

These changes are being checked into the SVN as they are closed, and
will show up in the coap-09 submission tonight. By the way, the SVN is
accessible by anyone if you are ever interested in changes as we close
tickets on WG documents:

Zach

On Mar 12, 2012, at 8:40 PM, Rahman, Akbar wrote:

> Hi Carsten,
> 
> 
> Could you please clarify exactly what change was incorporated into
http://tools.ietf.org/html/draft-ietf-core-coap-08?
> Changes (by cabo@...):
> Reporter:  cabo@...              |       Owner:
draft-ietf-core-coap@...

---

From: "Rahman, Akbar" <[email-masked]>
Date: Wed, 14 Mar 2012 14:46:03 -0400

Hi Zach,

Thanks, I read coap-09 and saw the new text for multicast response
handling in section 4.5.  One follow up question:

- If the multicast message receivers (servers) do send back valid
responses (e.g. successful Response to a GET), then the original sender
(or some intermediate CoAP proxy) will receive multiple responses and
will have to some method of filtering and processing the multiple
responses.

- We show one possible use case in 

http://tools.ietf.org/html/draft-ietf-core-groupcomm-01#page-17

- Should we have some text in coap-09 to cover this multiple response
processing as well?

Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rahman, Akbar
Sent: Monday, March 12, 2012 3:42 PM
To: Zach Shelby
Cc: core issue tracker; core WG
Subject: Re: [core] #177: Response suppression for multicast not defined

Akbar

-----Original Message-----
From: Zach Shelby [mailto:[email-masked]] 
Sent: Monday, March 12, 2012 3:33 PM
To: Rahman, Akbar
Cc: core issue tracker; core WG
Subject: Re: [core] #177: Response suppression for multicast not defined

Hi Akbar,

Zach

draft-ietf-core-coap@...

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 14 Mar 2012 20:07:05 +0100

> will have to some method of filtering and processing the multiple

That is the nature of multicast, so I would expect the need for that to be obvious.
We do not specify local processing, so what exactly the client does with the information is up to the implementer.

> http://tools.ietf.org/html/draft-ietf-core-groupcomm-01#page-17

Indeed, but generally the core-coap draft is very sparse on use cases.

> - Should we have some text in coap-09 to cover this multiple response

So, in summary, I do not see a need for additions to core-coap.

Grüße, Carsten

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 15 Mar 2012 09:53:33 +0000

What is not explicit in core-coap is how a CoAP proxy sends multicast responses back to a client (that used the Proxy-URI option), and hence what a client should expect to get back from the proxy. Maybe the general idea is obvious: proxy does not perform any processing/filtering/aggregation but sends back the individual responses to the client.

One remaining question; what if a client sends a unicast CON request to a CoAP proxy containing the Proxy-URI option, and then receives from the proxy multiple responses resulting from the CoAP multicast. Would it get NON responses from the proxy, or CON, or is that up to the implementation? NON would be preferable for congestion control reasons but this is not explicitly mandated by core-coap. CON would be logical if the aim of the proxy is to reply CON to a CON proxy-request following section 5.2.3. It could also be left as an implementation decision. (Without any extra guiding text, my guess would be that it becomes implementation-specific behaviour.)

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Wednesday 14 March 2012 20:07
To: Rahman, Akbar
Cc: core issue tracker; core WG
Subject: Re: [core] #177: Response suppression for multicast not defined

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: Carsten Bormann <[email-masked]>
Date: Thu, 15 Mar 2012 10:57:49 +0100

> What is not explicit in core-coap is how a CoAP proxy sends multicast responses back to a client (that used the Proxy-URI option), and hence what a client should expect to get back from the proxy.…

I don't think we want to constrain what intermediaries do here before gaining more experience with this.

> One remaining question; what if a client sends a unicast CON request to a CoAP proxy containing the Proxy-URI option, and then receives from the proxy multiple responses resulting from the CoAP multicast. Would it get NON responses from the proxy, or CON, or is that up to the implementation?

Right.  Again, we have not constrained it, and I think that is the right decision.

> NON would be preferable for congestion control reasons

Actually, (at least partially using) CON would enable getting some congestion control feedback.  With NON, you send into thin air.

> but this is not explicitly mandated by core-coap. CON would be logical if the aim of the proxy is to reply CON to a CON proxy-request following section 5.2.3. It could also be left as an implementation decision. (Without any extra guiding text, my guess would be that it becomes implementation-specific behavior.)

Yes, and I think at this stage that is fine.

Grüße, Carsten

---

From: "Rahman, Akbar" <[email-masked]>
Date: Thu, 15 Mar 2012 15:50:10 -0400

Carsten,

Can you clarify what you mean by "We do not specify local processing ..."? 

I do not follow your logic.  For example, in coap-09 there is clearly specification language for local caching (http://tools.ietf.org/html/draft-ietf-core-coap-09#section-5.6).  So what did you really mean?

Akbar

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Wednesday, March 14, 2012 3:07 PM
To: Rahman, Akbar
Cc: Zach Shelby; core issue tracker; core WG
Subject: Re: [core] #177: Response suppression for multicast not defined

Grüße, Carsten