Re: [core] New Version Notification for draft-tcs-coap-no-response-option-12.txt

["weigengyu" <[e-mail]>]

Hi Abhijan,

In your draft, there is not other contexts about piggybacked and separate response. 
With these statements,
“Using this option with CON type of requests may not have any
      significance if piggybacked responses are triggered. But, in case
      the server responds with a separate response (which, may be, the
      client does not care about) then this option can be useful.
      Suppressing the separate response reduces one additional traffic
      in this case. “ ,

the piggybacked response may be sent back and the separate response may be suppressed. 
Why not to suppress the piggybacked response? 
Even though an ACK of CON is needed, the ACK could be with an empty response instead of a nomormal response.

And if the piggybacked response is not suppressed,  
should the sender expect the suppressed separate response? 

Regards,

Gengyu WEI
Network Technology Center
School of Computer 
Beijing University of Posts and Telecommunications

From: Abhijan Bhattacharyya 
Sent: Monday, November 02, 2015 6:28 PM
To: weigengyu 
Cc: [e-mail] ; [e-mail] ; [e-mail] ; [e-mail] 
Subject: Re: [core] New Version Notification for draft-tcs-coap-no-response-option-12.txt

Hi Gengyu,
The description you quoted tries to clarify that No-Response may not have any effect in saving network traffic (e.g. for a PUT request) when it is used in CON mode and the response is supposed to be piggybacked. Because in case of piggybacking you still have the fields for the response code in the response message even if you are not sending any response. 

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: [e-mail]
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Consulting
____________________________________________



-----"weigengyu" <[e-mail]> wrote: -----

>To: "Rahman, Akbar" <[e-mail]>, "Abhijan
>Bhattacharyya" <[e-mail]>,
><[e-mail]>, <[e-mail]>, <[e-mail]>
>From: "weigengyu" <[e-mail]>
>Date: 11/02/2015 09:08AM
>Subject: Re: [core] New Version Notification for
>draft-tcs-coap-no-response-option-12.txt
>
>
>
>
>
>
><!--
>/* Font Definitions */
>@font-face
> {font-family:"Cambria Math";
> panose-1:2 4 5 3 5 4 6 3 2 4;}
>@font-face
> {font-family:Calibri;
> panose-1:2 15 5 2 2 2 4 3 2 4;}
>/* Style Definitions */
>p.MsoNormal, li.MsoNormal, div.MsoNormal
> {margin:0in;
> margin-bottom:.0001pt;
> font-size:12.0pt;
> font-family:"Times New Roman",serif;}
>a:link, span.MsoHyperlink
> {mso-style-priority:99;
> color:blue;
> text-decoration:underline;}
>a:visited, span.MsoHyperlinkFollowed
> {mso-style-priority:99;
> color:purple;
> text-decoration:underline;}
>p
> {mso-style-priority:99;
> mso-margin-top-alt:auto;
> margin-right:0in;
> mso-margin-bottom-alt:auto;
> margin-left:0in;
> font-size:12.0pt;
> font-family:"Times New Roman",serif;}
>tt
> {mso-style-priority:99;
> font-family:"Courier New";}
>span.EmailStyle19
> {mso-style-type:personal-reply;
> font-family:"Calibri",sans-serif;
> color:#1F497D;}
>.MsoChpDefault
> {mso-style-type:export-only;
> font-family:"Calibri",sans-serif;}
>@page WordSection1
> {size:8.5in 11.0in;
> margin:1.0in 1.0in 1.0in 1.0in;}
>div.WordSection1
> {page:WordSection1;}
>-->
>
>
>
>
>Hi Abhijan,
> 
>one question,
> 
>> 2. Option Definition
>> Using this option with CON type of requests may not have any
>      significance if piggybacked responses are 
>triggered. But, in case
>      the server responds with a separate response 
>(which, may be, the
>      client does not care about) then this option 
>can be useful.
>      Suppressing the separate response reduces 
>one additional traffic
>      in this case.
> 
>The No-reponse option is about request and response layer semantics. 
>When No-response option works, why the piggybacked responses are
>triggered 
>unless No-response is not recognized. 
>If the 
>No-Response option works, it would stop the response whether it is
>the 
>piggybacked or the separated. 
>It is 
>uncleatr why it is different between the piggybacked and the
>separate.
> 
>When the 
>receive ignore the No-Response option, it can response by piggybacked
>or 
>separated way. 
>Why does 
>the draft suppose just to suppress the separate response?    
>
> 
>And when 
>the No-Response works, the ACK of CON may contain an empty response. 
>The 
>following process of the sender side is the same as definitions for
>suppressing 
>separate response.  
> 
>The CON/ACK 
>is about the message layer semantics. 
>It seems 
>that the No-reponse does not touch the message layer semantics. 
> 
>Regards,
> 
>Gengyu 
>WEI
>Network Technology Center
>School of Computer 
>Beijing University of 
>Posts and Telecommunications
>
>
> 
>
>From: Rahman, Akbar 
>Sent: Sunday, October 18, 2015 8:17 AM
>To: Abhijan Bhattacharyya ; [e-mail] ; [e-mail] ;
>[e-mail] 
>Subject: Re: [core] New Version Notification for 
>draft-tcs-coap-no-response-option-12.txt
> 
>
>
>>Akbar, The reverse 
>proxy consideration have been included as a new section 4.3.
> 
>Thanks, 
>Abhijan.  Looks good.
> 
> 
> 
>One 
>other question, why does the draft say “Expired” at the top  even
>though 
>the expiry date is April 2016?
> 
>https://tools.ietf.org/html/draft-tcs-coap-no-response-option-12
> 
> 
> 
>From: Abhijan 
>Bhattacharyya [mailto:[e-mail]] 
>Sent: Thursday, 
>October 15, 2015 9:23 AM
>To: [e-mail]; [e-mail]; 
>[e-mail]; Rahman, Akbar 
><[e-mail]>
>Subject: Fw: New Version 
>Notification for draft-tcs-coap-no-response-option-12.txt
> 
>Hi Carsten, Esko, Akbar 
>and all, 
>
>Based on the recent 
>inputs we have shared a new version of the No-Response draft. 
>
>
>Esko, I 
>have actually removed the 'Leisure' stuff for unicast. Thought it was
>making 
>things a bit complicated. 
>
>Akbar, The reverse 
>proxy consideration have been included as a new section 4.3. 
>
>
>Carsten, 
>requesting your suggestion regarding the next step forward. 
>
>Hoping to see you all 
>in Yokohama. 
>
>Regards
>Abhijan 
>Bhattacharyya
>Associate Consultant
>Scientist, Innovation Lab, Kolkata, 
>India
>Tata Consultancy Services
>Mailto: [e-mail]
>Website: 
>http://www.tcs.com
>____________________________________________
>Experience 
>certainty.        IT 
>Services
>                       
>Business 
>Solutions
>                       
>Consulting
>____________________________________________
>
>----- 
>Forwarded by Abhijan Bhattacharyya/KOL/TCS on 10/15/2015 06:45 PM
>----- 
>
>
>From:        
>[e-mail] 
>
>To:        
>"Soma 
>Bandyopadhyay" <[e-mail]>, 
>"Soma Bandyopadhyay" <[e-mail]>, 
>"Abhijan Bhattacharyya" <[e-mail]>, 
>"Arpan Pal" <[e-mail]>, 
>"Arpan Pal" <[e-mail]>, 
>"Tulika Bose" <[e-mail]>, "Abhijan 
>Bhattacharyya" <[e-mail]>, 
>"Tulika Bose" <[e-mail]> 
>Date:        
>10/15/2015 06:45 
>PM 
>Subject:        
>New 
>Version Notification for draft-tcs-coap-no-response-option-12.txt 
>
>
>
>
>
>
>
>
>A new version of 
>I-D, draft-tcs-coap-no-response-option-12.txt
>has been successfully 
>submitted by Tulika Bose and posted to the
>IETF 
>repository.
>
>Name:                                  
>draft-tcs-coap-no-response-option
>Revision:                 
>12
>Title:                                  
>CoAP option for no server-response
>Document 
>date:                 
>2015-10-15
>Group:                                  
>Individual 
>Submission
>Pages:                                  
>17
>URL:            
>https://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-optio
>n-12.txt
>Status:         
>https://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option/
>Htmlized:       
>https://tools.ietf.org/html/draft-tcs-coap-no-response-option-12
>Diff:           
>https://www.ietf.org/rfcdiff?url2=draft-tcs-coap-no-response-option-1
>2
>
>Abstract:
>  
>There can be M2M scenarios where responses from server 
>against
>  requests from client might be considered redundant. 
>This kind of
>  open-loop exchange (with no response path from 
>the server to the
>  client) may be desired to minimize resource 
>consumption in
>  constrained systems while simultaneously 
>updating a bulk of
>  resources or updating a resource with a 
>very high frequency. CoAP
>  already provides a non-confirmable 
>(NON) mode of message exchange
>  where the server end-point 
>does not respond with ACK. However,
>  obeying the 
>request/response semantics, the server end-point
>  responds 
>back with a status code indicating "the result of the
>  attempt 
>to understand and satisfy the request".
>
>  This draft 
>introduces a header option for CoAP called 'No-Response'.
>  
>Using this option the client explicitly tells the server to 
>suppress
>  responses against the particular request. This 
>option also provides
>  granular control to enable suppression 
>of a particular class or a
>  combination of response-classes. 
>This option may be effective for
>  both unicast and multicast 
>requests. Present draft also discusses
>  few exemplary 
>applications which benefit from this 
>option.
>
>
>            
>
>
>
>Please note that it may take a couple of minutes from the 
>time of submission
>until the htmlized version and diff are available 
>at tools.ietf.org.
>
>The IETF 
>Secretariat
>=====-----=====-----=====
>Notice: The information contained in this 
>e-mail
>message and/or attachments to it may contain 
>confidential or 
>privileged information. If you are 
>not the intended recipient, any 
>dissemination, use, 
>review, distribution, printing or copying of the 
>
>information contained in this e-mail message 
>and/or attachments to it 
>are strictly prohibited. If 
>you have received this communication in error, 
>
>please notify us by reply e-mail or telephone and 
>immediately and 
>permanently delete the message 
>and any attachments. Thank 
>you
>
>
>_______________________________________________
>core mailing 
>list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/core
>
>