New proposed issues 7/21 - 7/27

id

  
  
  
owner

  
  
  
title

  
  
  
target

  
  
  
type

  
  
  
 

  
  
  
 

  
 

 

  
  
proposed-01
  

  
  
  
 

  
  
  
Semantics of "At
  most once" Delivery assurance 

  
  
  
all 

  
  
  
design 

  
  
  
* 

  
  
  
 

  
 

 

  
  
proposed-02
  

  
  
  
 

  
  
  
An RM Policy applies
  two-way 

  
  
  
policy 

  
  
  
design 

  
  
  
* 

  
  
  
 

  
 

 

  
  
proposed-03
  

  
  
  
 

  
  
  
RM Policy Assertion
  Model's Base Retransmission Interval Clarification Needed 

  
  
  
policy 

  
  
  
design 

  
  
  
* 

  
  
  
 

  
 

 

  
  
proposed-04
  

  
  
  
 

  
  
  
Robust recovery from
  low-resource conditions 

  
  
  
core 

  
  
  
design 

  
  
  
* 

  
  
  
 

  
 

 

 

  
  
proposed-01 

  
  
  
Semantics of "At
  most once" Delivery assurance 

  
  
  
all - design - unassigned

  
 

 

  
  
 

  
  
  
Description
  

  
The semantics of the
  "at most once" delivery assurance are not clear. 

  
One interpretation is
  that at most once implies that the sender is not required to retransmit
  mesages which are not acked. 

  
Related to i009

  
Justification
  

  
It is
  important to clarify whether the sender must retransmit unacknowledged
  messages when the "at most once" delivery assurance is in use. 

  
Origin
  

  
Tom
  Rutt 

  
Proposal
  12005-07-21 

  
Clarify the semantics.
  There are at least three possible semantics associated with "at most
  once"

  
1.     
  At most once means that the sender will
  never retransmit a message, regardless of whether it is acknolweged by the
  destination. 

  
2.     
  The sender may retransmis messages, but
  is not required to to so, however the destination will not deliver duplicates
  

  
3.     
  The sender must retransmit messages,
  however the destination may drop messages in times of resource saturation,
  but will never deliver a duplicate. 

  
 

 

  
  
proposed-02 

  
  
  
An RM Policy applies
  two-way 

  
  
  
policy - design - unassigned

  
 

 

  
  
 

  
  
  
Description
  

  
In
  WS-RM Policy, and per WS-PolicyAttachment, RM Policy assertions may be
  attached to ports. E.g, details of parameters for the resending mechanism. It
  is implied by doing so, that both inbound and outbound messages are subject
  to this policy. This assumes that there is a strong case for in and out
  messages always using the same Delivery assurance. In effect this is saying
  that an RM Policy applies to two Destinations: the destination of the inbound
  messages, and the destination of the outbound messages (meaning for example
  to both a WS endpoint and its clients). 

  
Justification
  

  
Evidence
  for such an aggregation of quality of service is unclear: On the contrary,
  both (a) differences in technical capabilities between Source and
  Destination, and (b) differences in business and QoS requirements, suggest
  that a policy (delivery assurance) defined for messages going one direction,
  may not be appropriate for messages going the other way. 

  
Origin
  

  
Jacques
  Durand 

  
Proposal
  12005-07-21 

  
Even
  if the scope of an RM Policy remains at port level there could be an
  additional scoping attribute stating inbound vs outbound. Yet a cleaner way
  seems to make use of finer granularity in the attachment (as allowed by
  WS-PolicyAttachment). 

  
 

 

  
  
proposed-03 

  
  
  
RM Policy Assertion
  Model's Base Retransmission Interval Clarification Needed 

  
  
  
policy - design - unassigned

  
 

 

  
  
 

  
  
  
Description
  

  
The
  RM policy assertion model defines InactivityTimeout and
  BaseRetransmissionInterval. The text in the specification WS-RM Policy (Page
  5) implies that these two parameters are essentially serving the same purpose
  i.e. to trigger a retransmit based on a timeout value. If this is the
  intention, the spec needs to clarify the pecking order for an implementation
  i.e. what if timeout occurs before base retransmission interval has expired. 

  
Justification
  

  
There
  is no obvious case mentioned in the spec that requires two timers for
  retransmission upon timeout. 

  
Origin
  

  
Vikas
  Deolaliker 

  
Proposal
  12005-07-22 

  
Merge
  the two into one timer called Retransmission Timeout. 

  
 

 

  
  
proposed-04 

  
  
  
Robust recovery from
  low-resource conditions 

  
  
  
core - design - unassigned

  
 

 

  
  
 

  
  
  
Description
  

  
In
  situations where the RMD is running low on resources, it may want to provide
  hints to the RMS of its situation with the expectation that the RMS pauses or
  slows down the (re)transmittal of messages and avoid further straining of RMD
  resources until recovery. The current solution of statically associating an
  ExponentialBackoff policy assertion may not be timely and sufficient in all
  the cases and a more dynamic solution for throttling the message flow may be
  needed. 

  
Justification
  

  
In a
  low-resource situation, it is likely that the RMD would discard any incoming
  messages and stop sending any Acks. Since the current protocol design does
  not provide for the RMS to become cognizant of the situation on the RMD side,
  RMS may simply keep on (re)transmitting messages resulting into further
  resource utilization (network bandwidth, processing power on both ends, etc.)
  and possibly making the situation worse. It seems that a better option may be
  for the RMD to push back on the RMS in the event of low-resource like
  situations and request the RMS for pausing or slowing down any
  (re)transmissions. 

  
Origin
  

  
Sanjay
  Patil 

  
Proposal
  12005-07-26 

  
RM
  Protocol to support RMD pushing back on the RMS for slowing down or stopping
  (re)transmission of messages.