Randolph | 22 Apr 18:58 2014

SCTP implementation into an Instant Messenger with File Transfer

Dear SCTP Community,

SCTP has been implemented into an Instant Messenger with File Transfer.
Binaries are available for windows, a compile info for Linux and several other operating systems is also given (c++ / Qt).

Please test it and if you like, describe your research. The used library spot-on is an evaluation project and please post improvement requests there.

For the implementation see the homepage of the Chat-App:
http://goldbug.sf.net  - an extended gui is provided by the library too for more detailed tests.

Bradner, Scott | 22 Apr 17:09 2014

Generic Aggregated RSVP for IPv4 and IPv6 Reservations Over PCN Domains

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.


Michael Thornburgh | 21 Apr 23:34 2014

feedback request: draft-thornburgh-rtmfp-flash

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/

   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

thank you.

-michael thornburgh

James Polk | 7 Apr 21:37 2014


please ignore

James Polk (jmpolk | 8 Apr 21:25 2014


test, please ignore
internet-drafts | 8 Apr 13:30 2014

I-D Action: draft-ietf-tsvwg-sctp-prpolicies-02.txt

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

   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:

There's also a htmlized version available at:

A diff from the previous version is available at:

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:

IETF Secretariat | 27 Mar 16:39 2014

Milestones changed for tsvwg WG

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/

Gorry Fairhurst | 25 Mar 08:43 2014

TSVWG has adopted draft-ietf-tsvwg-rtcweb-qos

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

ihab jabor | 18 Mar 12:00 2014

Fwd: SCTP Congestion Control

My name is Ihab ,
I will be gratitude for you help in  advance, my research focus on Congestion control of SCTP actually I'm workout develop and optimize the slow start and congestion avoidance in SCTP.
I've been implemented SCTP through various simulation scenarios then I've been draw CWND also figure out many performance factors like throughput and queue size.   
I used SCTP RFC 2690 in NS2 which have been implemented by Protocol Engineering Lab in University of Delaware,
 kindly below the peace of C++ code regarding congestion control SCTP protocol which fetch from NS2 in addition some question notes.

Slow start::::
  1. {
  2.       spDest->iCwnd += MIN(spDest->iNumNewlyAckedBytes, (int)uiMaxDataSize);
  3.       tiCwnd++; // trigger changes for trace to pick up
  4.     }

Congestion avoidance

  1. if(spDest->iPartialBytesAcked >= spDest->iCwnd &&
  2.      spDest->iOutstandingBytes >= spDest->iCwnd )
  3.     {
  4.       DBG_PL(AdjustCwnd, "adjusting cwnd") DBG_PR;
  5.       if(spDest->iCwnd <= spDest->iPartialBytesAcked)
  6.           spDest->iPartialBytesAcked -= spDest->iCwnd;
  7.       else
  8.         spDest->iPartialBytesAcked = 0;
  9.       spDest->iCwnd += uiMaxDataSize;
  10.       tiCwnd++; // trigger changes for trace to pick up
  11.     }

kindly any recommendations or advice ...

Michael Ramalho (mramalho | 12 Mar 18:50 2014

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

[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] "


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



gorry | 12 Mar 16:42 2014

TSV WG notes from IETF-89, london

Thanks to our note-takers!

I've now uploaded the notes and tried to cross-check with the audio


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)