Subject: [Speechsc] Contiguous Request-ID's

From: Eric Burger <[email-masked]>
Date: Tue, 17 May 2005 04:21:26 -0400

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

---

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Tue, 17 May 2005 06:55:14 -0700

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).

---

From: Eric Burger <[email-masked]>
Date: Wed, 18 May 2005 18:04:30 -0400

Works for me. 

> From: David R. Oran [mailto:[email-masked]] 
> Sent: Wednesday, May 18, 2005 12:04 AM
> To: Eric Burger
> Cc: Shanmugham, Saravanan; [email-masked]
> Subject: Re: [Speechsc] Contiguous Request-ID's
> 
> 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.
> 
> On May 17, 2005, at 5:00 PM, Eric Burger wrote:
> 
> > 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.
> >
> >
> >> 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
> >>