SCTP implementation into an Instant Messenger with File Transfer
2014-04-22 16:58:18 GMT
sorry for the delay I have reviewed Generic Aggregated RSVP for IPv4 and IPv6 Reservations Over PCN Domains (draft-ietf-tsvwg-rsvp-pcn-08). It took a while because of the changes but the resulting document makes sense to me, both relative to the original PCN architecture and in the absolute, so I think this is ready to proceed. Scott
hi TSV Working Group folks. i briefly presented "Adobe's Secure Real-Time Media Flow Protocol" (RTMFP) to this working group at IETF 86 in Orlando, and notified this mailing list, soliciting feedback on the specification I-D to help improve it. i received invaluable feedback from the community, and when the specification was published as RFC 7016, it was very much improved from the initial draft due in large part to the community review it received. RTMFP is a general purpose endpoint-to-endpoint transport protocol designed for real-time and P2P communication. it is deployed widely in the Internet as part of Adobe Flash and other software. i have submitted a new companion I-D, "Adobe's RTMFP Profile for Flash Communication", that describes how RTMFP (the generic protocol) is used to transport the video, audio, and data messages of real-time and P2P communications in Flash, including the concrete RFC 7016 "Cryptography Profile" for Flash. this new specification illustrates a practical application of RTMFP, which can also help folks understand how to apply RTMFP's capabilities to use cases other than Flash communication. we will eventually be submitting this specification to the Independent Submission Editorial Board for publication as an Informational RFC. to that end i am soliciting feedback, comments, and reviews of this I-D to help us improve its quality, readability, implementability, etc. --- Name: draft-thornburgh-rtmfp-flash Revision: 00 Title: Adobe's RTMFP Profile for Flash Communication Document date: 2014-04-14 Group: Individual Submission Pages: 45 URL: http://www.ietf.org/internet-drafts/draft-thornburgh-rtmfp-flash-00.txt Status: https://datatracker.ietf.org/doc/draft-thornburgh-rtmfp-flash/ Htmlized: http://tools.ietf.org/html/draft-thornburgh-rtmfp-flash-00 IPR: https://datatracker.ietf.org/ipr/2345/ Abstract: This memo describes how to use Adobe's Secure Real-Time Media Flow Protocol (RTMFP) to transport the video, audio, and data messages of Adobe Flash platform communications. Aspects of this application profile include cryptographic methods and data formats, flow metadata formats, and protocol details for client-server and peer-to-peer communication. --- thank you. -michael thornburgh
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Additional Policies for the Partial Reliability Extension of the Stream Control Transmission Protocol Authors : Michael Tuexen Robin Seggelmann Randall R. Stewart Salvatore Loreto Filename : draft-ietf-tsvwg-sctp-prpolicies-02.txt Pages : 7 Date : 2014-04-08 Abstract: This document defines policies for the Partial Reliability Extension of the Stream Control Transmission Protocol (PR-SCTP) allowing to limit the number of retransmissions or to prioritize user messages for more efficient send buffer usage. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-prpolicies/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-prpolicies-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-prpolicies-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/
Added milestone "Submit 'DSCP packet markings for RTCWeb QoS' to IESG as a Proposed Standard RFC", due September 2014. URL: http://datatracker.ietf.org/wg/tsvwg/charter/
The chairs judge the consensus of this WG is to adopt: draft-dhesikan-tsvwg-rtcweb-qos with the intention of publishing this as a Proposed Standard. Authors: Please upload a new revision of the draft, updated by the discussion at the London IETF meeting as "draft-ietf-tsvwg-rtcweb-qos" Gorry, James, & David TSVWG Co-Chairs
kindly any recommendations or advice ...
[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.]
Re: "... the RTCWeb guys [don't want the combination of timed reliability and lifetime] "
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
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?
Thanks to our note-takers! I've now uploaded the notes and tried to cross-check with the audio recording: http://www.ietf.org/proceedings/89/minutes/minutes-89-tsvwg Please check and send the Chairs an email if you think there are changes needed (if something was said not reflected correctly)! Best wishes, Gorry, David and James (tsvwg co-chairs)