RE: [wsrm] Number of fault messages to send after the receiver aborts ordered delivery for local reasons

Alan:

 

"After sending 5 abort faults in response to 5 received messages after 
ordered delivery has been aborted for the group, the receiver will stop sending 
the abort fault."

 

that is better, yet could be worded 
something like:

-  "receiving RMP MUST publish a GroupAborted fault for each one of 
the 5 first messages 

received for the aborted group, and MAY do so for subsequent 
messages." (so it is possible to accommodate other policies, e.g. 
exponential back-off. Also "publish" accommodates "poll" 
cases.)

 

We 
might still have a general provision for handling denial of service attacks (not 
just in hat case), that say that in case  of suspicious pattern of 
communication taht creates an obvious burden on the receiver, the receiver may 
decide to drop

any 
sending duty required by this spec, and send another special fault about this 
?

 

 

Jacques

 

  
-----Original Message-----
From: Alan Weissberger 
  [mailto:]
Sent: Wednesday, May 05, 2004 11:34 
  AM
To: ; wsrm
Subject: [wsrm] Number of 
  fault messages to send after the receiver aborts ordered delivery for local 
  reasons

  
First, a review of 
  the discussion of this topic on yesterday's call and then my revised 
  proposal:

  
 

  
1.  Here is what 
  Tom recorded in the minutes of yesterday's call:

  
Bob F: suggested: 
  Any additional messages that are 
  received for an aborted group, until the group expiry time, MUST have the 
  GroupAborted fault sent. 

  
Jacques, requiring 
  that every message received has to have this fault returned.  The Receiver may decide to only send 
  once every 10 messages received in that group.

  
 Jacques: we should not mandate one fault 
  notice for each received message.

  
 Alan: a responsible sending RMP will cease 
  sending on the group once it receives this fault for this group.  This would be a small number of 
  messages in transit which would require sending this fault.

  
Bob F: if you have 
  high bandwidth, low latency channel , they could wait 
  a few seconds to wait and send the fault replies.

  

  
Jacques: in ebMS people had considered a sender with bad intentions, 
  to overload the receiver.  This 
  concern is addressed in the design of the ebMS 
  protocol.  In the same way we 
  deferred the resend policy, we could say that the receiver must publish a 
  group abort fault when the group is aborted.  This publishing could be open for 
  config parameters to decide the 
frequency.

  
Tom:  We need 
  further discussions.  Take to the 
  email list.

  
2. Alan's basic 
  premise:   We should not complicate the protocol to accomodate the 
  exception condition where multiple messages are in transit AFTER the receiver 
  has aborted ordered delivery for the group.  In the majority of cases, 
  one or a few messages may be outstanding when the abort fault is 
  received.  Hence, there is not a big burden for the receiver to send the 
  abort fault for each message received after ordered delivery was 
  abandoned.

  
On the other hand, 
  the denial of service situation must be prevented, as per Jacques 
  comment.  What if the sender mis-behaves and sends a very large number of 
  messages to the receiver which has aborted ordered delivery and sent the abort 
  fault?  Here is my proposal for this case:

  
"After sending 5 
  abort faults in response to 5 received messages after ordered delivery has 
  been aborted for the group, the receiver will stop sending the abort 
  fault."

  
Comment:  there 
  is no need to complicate the protocol by waiting for n messages (i.e. 
  batching) before sending the next abort fault and repeating this process 
  endlessly.  Just send 5 aborts and be done!  After that, the 
  receiver just ignores messages belonging to the aborted group.

  
 

  
alan

  
 

To unsubscribe from this 
  mailing list (and be removed from the roster of the OASIS TC), go to 
  http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.