Re: [rtcweb] Lower-overhead protocol variations

On Feb 20, 2013, at 10:31 PM, Randell Jesup wrote:

> This is a relevant thread to current discussions:
> 
> http://www.w3.org/mid/D1737092-F63D-4821-B3FA-D425267E4F23@cisco.com
> 
> and continued with subject change in
> 
> http://www.w3.org/mid/4F4D6315.9000601@jesup.org
> 
> I'm re-evaluating if the original decision against even/odd was required,
> in order to see if we can collapse the current draft 0-RTT proposal
> into a single declarative "open" message on a stream with no response or ack
> required. Even/odd (perhaps based on a property of the SCTP association?)
> would avoid the need for mismatched channel pairs, and thus avoid the need
> for the response/ack and the need to send with the in-order bit.
I'm not sure what you mean you even/odd?

I guess you will send the "open" message reliable and ordered. OK.
Are you proposing that there is no ACK sent back? What would happen
if one side sends an "open" message indicating an unordered data channel,
sends a user message on this channel and the user message is delivered
first?
> 
> The only hole I've seen so far is that if the return stream isn't
> currently within the range of valid streams (i.e. at the far end) there's
> no easy way to return an error.  However, we expect to be able to
How are the stream in both directions tied together? How is the allocation
done? Can't the sender of the "open" message know that there is no backward
channel?
Maybe you are thinking about each side only using even outgoing streams for
data channels initiated by its own, and the next higher odd for the ones
initiated by the peer. If you are thinking like this, each side knows if
the resources are there and, if not, can request more. Do you have something
like this in mind?

Best regards
Michael
> negotiate additional streams on request, so this may not really matter.
> 
> We may need to reserve more initial streams, but the overhead for this is
> minimal.
> 
> Perhaps this would address some of the concerns voiced here.  Also,
> someone will be posting a use case soon this sort of change will
> help.... <jesup waits for the post>
> 
> -- 
> Randell Jesup
> randell-ietf@jesup.org
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 