Subject: RE: [Speechsc] Contiguous Request-ID's

From: Eric Burger <[email-masked]>
Date: Tue, 17 May 2005 17:00:56 -0400

Consider what happens if there is wording in the spec that says Request-ID's
MUST be contiguous.  Let us say a server receives an out-of-order
Request-ID.  Moreover, the spec remains silent on what to do.

I can imagine that some servers will happily accept the request.  They
"know" that there really is not a requirement for contiguous Request-ID's.
It doesn't matter.

I can imagine that other servers, especially those written by folks that
were not involved in this conversation, that will reject the request.  The
spec says Request-ID's MUST be contiguous, and clearly something very bad
has happened -- a message got lost over a reliable transport connection.

Now things get even more interesting.  Since something 'very bad' happened,
and the spec is silent, some servers will reject the request, while others
will tear down the entire MRCPv2 session.  Others may kill all MRCPv2
sessions with that server.

The point is that if we don't specify actions, we will get incompatible
implementations.

> -----Original Message-----
> From: Shanmugham, Saravanan [mailto:[email-masked]] 
> Sent: Tuesday, May 17, 2005 9:55 AM
> To: Eric Burger; [email-masked]
> Subject: RE: [Speechsc] Contiguous Request-ID's
> 
> I don't mind rmoving these restrictions. But I don't see what 
> this change gets us or avoids. Is there anything specific you 
> are trying address here. If not, I would be inclined to leave 
> it as is. 
> 
> Sarvi  
> 
>      -----Original Message-----
>      From: [email-masked] 
>      [mailto:[email-masked]] On Behalf Of Eric Burger
>      Sent: Tuesday, May 17, 2005 1:21 AM
>      To: [email-masked]
>      Subject: [Speechsc] Contiguous Request-ID's
>      
>      Section 5.1, Request:
>      Why must request-id's be contiguous?  Monotonically 
>      increasing makes sense.
>      Do we have a mechanism for handling out-of-order requests? 
>       However, contiguous request-id's imply some mechanism for 
>      dealing with missing requests, which I don't think we 
>      have.  I would either fill-in the mechanisms (with 
>      justification for the complexity) or relax the 
>      requirements appropriately.  Either:
>      
>      1. Keep contiguous (incrementing by 1).  Explain why.  
>      Explain mechanisms for handling missing and out-of-order 
> requests.
>      
>      2. Keep monotonically increasing.  Explain mechanisms for 
>      handling out-of-order requests.
>      
>      3. Keep unique.
>      
>      I vote for #3, unless there are use cases for ordering 
>      requests that arrive over reliable, ordered transports 
>      (TCP, SCTP-Connection-Mode).
>      
>      _______________________________________________
>      Speechsc mailing list
>      [email-masked]
>      https://www1.ietf.org/mailman/listinfo/speechsc
>      
> 

_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 18 May 2005 00:03:54 -0400

I think the Postel dictum should guide us here which leads me to and  
to separate transmitter and receiver behavior. Any request-id scheme  
puts the burden on the receiver to detect duplicates. If there is no  
ordering requirement on request-ids, then the receiver state needed  
is O(M), where M is the maximum number of requests that might ever be  
sent in a session. At the other extreme, requiring contiguous  
monotonic request sequencing winds up either having startup ambiguity  
(what is the first request of a session contiguous to?) or also  
mandating an initial request number (e.g. 1) for a session and opens  
up all the off-by-one style errors.

Specifying monotonic requests tends to be the best compromise - it  
allows duplicate or misordering-through-transmitter-bug detection  
with O(1) state at the receiver. Lastly, the size of course needs to  
be big enough so that you don't need modular arithmetic and window  
computations for them.

So, the above is the long way of saying I think we should do (2), and  
reject duplicate and out-of-order requests with a well-defined error.

Dave.