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

"Michael Ramalho (mramalho)" <mramalho@cisco.com> Wed, 12 March 2014 17:50 UTC

Return-Path: <mramalho@cisco.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259631A0381 for <tsvwg@ietfa.amsl.com>; Wed, 12 Mar 2014 10:50:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.047
X-Spam-Level:
X-Spam-Status: No, score=-10.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWq-4nf2paow for <tsvwg@ietfa.amsl.com>; Wed, 12 Mar 2014 10:50:20 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id ED95C1A04D2 for <tsvwg@ietf.org>; Wed, 12 Mar 2014 10:50:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8298; q=dns/txt; s=iport; t=1394646614; x=1395856214; h=from:to:subject:date:message-id:mime-version; bh=xQTrNPWD0ro2Snmj/268eSp40lLMNjTPL3jWASG6Fn0=; b=aKP5r6TQPa/rO0nse+uqDMFIPsg7tKP/NLy4Y/ITusSWV3FKdEbnTPhe UykL+ZnOm6lmp6JclJq70mqDQSBiNf70wvVIOqiiBN1ZiMEdCyzsWQoyT /A2jNhVlVWoRJJao9W+NyoY64ntWSuBF1HJpI3C+kZIWyEC6LhJAnV9K+ Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag4FAGidIFOtJXHA/2dsb2JhbABagkJEO1e+S4MKgR8WdIInAQQtXgEqViYBBBuHcaF6sGsXjgQEI4NcgRQEqnKDLYFpQg
X-IronPort-AV: E=Sophos; i="4.97,639,1389744000"; d="scan'208,217"; a="26934575"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-2.cisco.com with ESMTP; 12 Mar 2014 17:50:13 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2CHoDcZ001736 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <tsvwg@ietf.org>; Wed, 12 Mar 2014 17:50:13 GMT
Received: from xmb-rcd-x12.cisco.com ([169.254.2.163]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Wed, 12 Mar 2014 12:50:13 -0500
From: "Michael Ramalho (mramalho)" <mramalho@cisco.com>
To: "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: Review of draft-tuexen-tsvwg-sctp-prpolicies-03.txt
Thread-Index: Ac8+G4Mg+xgaPtwOT5+D/vFGILRo5A==
Date: Wed, 12 Mar 2014 17:50:13 +0000
Message-ID: <D21571530BF9644D9A443D6BD95B910323060082@xmb-rcd-x12.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.117.125.233]
Content-Type: multipart/alternative; boundary="_000_D21571530BF9644D9A443D6BD95B910323060082xmbrcdx12ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/s9pxQhExnkutfaojW7Qt3hrYhgo
Subject: [tsvwg] Review of draft-tuexen-tsvwg-sctp-prpolicies-03.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Mar 2014 17:50:25 -0000

[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),



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!



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



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!



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.



Is the issue here simply that you don't want to make the new API a little more complex? Or backward compatibility?



I think the key point here is that at least "priority" and "timed reliability" are probably desired together. What do others think?



Michael Ramalho