Re: [tsvwg] Review of draft-tuexen-tsvwg-sctp-prpolicies-03.txt

[Michael Tuexen <[e-mail]>]

On 12 Mar 2014, at 18:50, Michael Ramalho (mramalho) <[e-mail]> wrote:

> [Everyone except Michael: I volunteered to be a reviewer on the SCTP "PR-policies" draft while at the IETF in London. This exchange between me and Michael Tuexen are a part of that review process.]
>  
> ***
>  
> Michael (Tuexen),
Hi Michael,

just to be sure: the current version of the document is
http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-prpolicies-01
>  
> Re: "...  the RTCWeb guys [don't want the combination of timed reliability and lifetime] "
> AND
> Re: " The current API allows you only to have a single parameter... So we would not define a "generic combination" of existing policies, but a single new policy having two parameters and having the semantics of combining two existing policies."
>  
> If the current API allows you only to have a single parameter, then I presume (by extension) that you cannot have priority (this draft) and timed reliability (RFC 3758) combination either.
>  
> I am SURE that if you asked the "RTCWeb guys" if they wanted that particular combination that they would have said YES!
The W3C documents specifies a timeout and a number of retransmission and you are only allowed
to set one of them. I found this pretty restrictive and suggested to remove this restriction
in the API and add support for such a policy with two parameters to this ID. The explicit
feedback from Firefox and Chrome people was that they will keep the restriction for now.
It was then privately between SCTP implementers discussed that it might not be good
to implement something on the guess what might be needed in the future, but to wait if
a concrete use case comes up in the future.
>  
> Indeed, I was on a call just yesterday where priority within a PR-SCTP stream was discussed (where they assumed "timed-reliability" was in effect). This is of particular use for video (and video encoding in screen sharing modes).
>  
> So, I see we have (at present) three dimensions of PR policy:
>  
> 1) Timed Reliability
> 2) Limited Retransmissions
> 3) Priority
Correct. But I don't think Priority means what the WebRTC people consider a priority. My understanding
is that they use it as weight how to distribute the bandwidth on the SCTP association between the
data channels. However, it seems the priority stuff is pretty vague.
>  
> For the record, I don't think people will come up with additional policies for a specific stream ... but there is something I don't like about your proposal to create another policy that is a combination of two or three of the existing ones because of the combinatorics involved (individual policies for 1&2, 2&3, 1&3, 1&2&3). One more policy and that gets untenable!
The current concept is that you can have a single policy for each SCTP user message.
The policy is based on an enumeration, not on a bitfield where you could select more than one.
This ID specifies two new policies in addition to the already existing one.
>  
> Since the "retransmission decision" is conditioned by policy ... (presumably a break from within an "if and if else" portion) ... I don't see the combination as being particularly hard in code.
I don't get what you want to say here.
>  
> Is the issue here simply that you don't want to make the new API a little more complex? Or backward compatibility?
I'm not against extending the API. That is why I suggested to add policies with more than one parameter,
but up to now this is not needed by RTCWeb.
>  
> I think the key point here is that at least "priority" and "timed reliability" are probably desired together. What do others think?
Interesting that you bring up the priority one here, since it was not mentioned up to know for WebRTC.
The combination is saw of some use (to make the W3C API less restrictive) was the combination of
'number of retransmissions' and 'livetime'. But I'm open and interested in others views.

Best regards
Michael
>  
> Michael Ramalho