Caitlin Bestler | 11 Sep 00:24 2014


TSVWG                                                    C. Bestler, Ed.
Internet-Draft                                                  R. Novak
Intended status: Experimental                                    Nexenta
Expires: March 14, 2015                               September 10, 2014

           Creation of Transactional Subset Multicast Groups


   This memo presents techniques for controlling the membership of
   multicast groups which are constrained to be a subset of a pre-
   existing multicast group, where such subset groups are only used for
   short duration transactions which are multicast to a subset of the
   larger multicast group.

Editor's Note

   The proper working group for this draft has not yet been determined.
   Alternate working groups include PIM and INT.

   Nexenta has been developing a multicast based transport/storage
   protocol for Object Clusters at Nexenta.  This applies multicast
   datagrams to creation and replication of Objects such as those
   supported by the Amazon Simple Storage Service ("S3") protocol or the
   OpenStack Object Storage service ("Swift").  Creating replicas of
   object payload on multiple servers is an inherent part of any storage
   cluster, which makes multicast addressing very inviting.  There are
(Continue reading)

Caitlin Bestler | 11 Sep 00:23 2014

Fwd: New Version Notification for draft-bestler-transactional-subset-multicast-00.txt

The initial feedback from my pre-draft posting were very useful. One of the hardest things in writing these protocols is realizing
what you haven’t stated because it was just too obvious to you. The first round of feedback was very helpful.

Begin forwarded message:

Subject: New Version Notification for draft-bestler-transactional-subset-multicast-00.txt
Date: September 10, 2014 at 3:17:36 PM PDT
To: Caitlin Bestler <caitlin.bestler <at>>, "Robert Novak" <robert.novak <at>>, Robert Novak <robert.novak <at>>, "Caitlin Bestler" <caitlin.bestler <at>>

A new version of I-D, draft-bestler-transactional-subset-multicast-00.txt
has been successfully submitted by Caitlin Bestler and posted to the
IETF repository.

Name: draft-bestler-transactional-subset-multicast
Revision: 00
Title: Creation of Transactional Subset Multicast Groups
Document date: 2014-09-10
Group: Individual Submission
Pages: 25

  This memo presents techniques for controlling the membership of
  multicast groups which are constrained to be a subset of a pre-
  existing multicast group, where such subset groups are only used for
  short duration transactions which are multicast to a subset of the
  larger multicast group.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at

The IETF Secretariat

Tirumaleswar Reddy (tireddy | 10 Sep 19:07 2014

FW: New Version Notification for draft-wing-tsvwg-turn-flowdata-01.txt

The draft is updated to include upstream and downstream bandwidth parameters. Comments and suggestions
are welcome.


-----Original Message-----
From: internet-drafts <at> [mailto:internet-drafts <at>] 
Sent: Wednesday, September 10, 2014 10:31 PM
To: Ram Mohan R (rmohanr); Brandon Williams; Tirumaleswar Reddy (tireddy); Dan Wing (dwing);
Tirumaleswar Reddy (tireddy); Dan Wing (dwing); Ram Mohan R (rmohanr); Brandon Williams
Subject: New Version Notification for draft-wing-tsvwg-turn-flowdata-01.txt

A new version of I-D, draft-wing-tsvwg-turn-flowdata-01.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:		draft-wing-tsvwg-turn-flowdata
Revision:	01
Title:		TURN extension to convey flow characteristics
Document date:	2014-09-10
Group:		Individual Submission
Pages:		13




   TURN server and the network in which it is hosted due to load could
   adversely impact the traffic relayed through it.  During such high
   load event, it is desirable to shed some traffic but TURN server lack
   requirements about the flows to prioritize them.  This document
   defines such a mechanism to communicate flow characteristics from the
   TURN client to its TURN server.


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at

The IETF Secretariat

Caitlin Bestler | 28 Aug 19:02 2014

Re: Transactional Multicast within Clusters

On Aug 26, 2014, at 8:43 PM, Dave Taht <dave.taht <at>> wrote:

> This made my head hurt. Got code?

This is a very distributed algorithm. Actual code would be very dependent on implementation specifics
at each of the execution locations.

But to break this down, there are four relevant locations in this protocol:

1) The sender
2) The data plane forwarder of multicast frames/packets in the switch/mrouter.
3)The software which updates the control data that the data plane forwarder uses.
    This may be a processor that is part of the switch/mrouter. Concieably this could be
    built “in-line” in the forwarding chip, but that is not required and is probably not desirable.
   The amount of logic that can be considered trivial grows every year, so I don’t want to state
   that it would *never* be done in-line, but I wouldn’t want to buy such a switch anytime soon.
4) The receiver.

Something that I neglected to highlight in the first message is that 2) is unchanged from
existing switches/mrouters. This was a major constraint on the design, but it can be so
obvious when your working on it that you can forget to state it.

The detailed logic example for Method 1 provide in the original post applies to 3) the forwarder-associated
editing of the data used by the data plane to control multicast forwarding.

>> On forwarder X the forwarding rule for new group I contains:
>>        The forwarding port for A.
>>        The forwarding port for B.
>>        The forwarding port to forwarder Y (a hub link). This eventually leads to C.
>> While on forwarder Y the forwarding rule for the new group I will contain:
>>        The forwarding port for forwarder X (a hub link). This eventually leads to A and B.
>>        The forwarding port for C.

This assumes the common data plane forwarding model:
* VLAN ID + multicast address indexes to a set of ports. The frame is forwarded on all of those ports except the
port the frame arrived upon.

So the forwarding port set to reach [A,B,C] is the union of the  port sets for [A],[B] and [C].

This is done when the dynamic transactional multicast group is set, not on a per frame/packet basis.

For method 1 the sender and the receivers have agreed to transmit a transaction on transaction multicast
group X, and that the membership
of the transactional group will be [A,B,C]. Rather than having A,B and C use IGMP/MLD to *join* the group,
the sender uses method 1 to
*push* the membership of the group to the relevant switches/mrouters.

Method 2 has the same two layer approach. The setup command is just more ambitious.
It is creating a large set of transactional multicast groups to cover every legitimate set of targets
within an existing multicast group.  For example, all combinations of 3 members of a 10 member
reference group.

One implementation would be as follows:

	t_group = base_t_group
		set forwarding rule for t_group to union of forwarding ports for t_group’s members
		t_group = t_group + 1
	while permuting membership yields a new combination

With method 2 the sender uses the master group (referred to as the “Negotiating Group” in Nexenta’s
Replicast protocol) to announce which
of the pre-existing transactional_groups will be used to complete a given transaction. That
transctional group is now associated with the
transaction because each of the receivers has already granted some form of exclusive right to multicast to
it for a specific overlapping 
duration. This may be exclusive to the port/VLAN, or could conceivably be for a more specific scope. This is
dependent on the higher
layer protocol that is using these new methods for creating transactional multicast groups.


>> Caitlin Bestler
>> caitlin.bestler <at>
>> cait <at>

Caitlin Bestler | 26 Aug 18:03 2014

Draft IETF message to disclose Transactional Multicast within Clusters

Nexenta has been developing a multicast based transport/storage protocol for Object
Clusters at Nexenta. This applies multicast datagrams to creation and replication of
Objects such as those supported by the Amazon S3 protocol. Creating replicas of  object
payload on multiple servers is an inherent part of any storage cluster, which makes
multicast addressing very inviting.  There are issues of congestion control and
reliability to settle, which we were able to do.

However, we found that the existing protocols for controlling multicast group membership
(IGMP and MLD) are not suitable for our storage application. We doubt  this is unique to
our application. It should apply to many clusters that have a need to distribute
transactional messages to dynamically selected subsets of a group within a cluster to
multiple known recipients. HPC clusters using MPI are also potential users of transactional
multicasting. Multicast repication over a VLAN for the internal communications of a pNFS
cluster is another potential application. This is just one example of synchronizing cluster
data where the synchronization does not replicate all of the shared data with the entire
cluster. But these are merely initial hunches, the purpose of this email is to determine exactly
how common the need for “transactional multicast” is, and possibly to incorporate the needs
of other clusters, before submitting a draft.

To be clear, this is a submission to the IETF process proposing enhanced methods for
controlling multicast group membership. This and later posts may make reference to
specific applications, including the Nexenta Replicast protocol for multicast replication
in our Cloud Copy-on-Write (CCOW) Object Cluster. Such examples are merely for
illustrative purposes. Any IETF standardization of the Replicast storage protocols would
be done via the Storm or NFS groups, and would require adoption of a definition of Object
Storage as a service before defining a specific protocol for providing Object Storage

What will be proposing is focused on the management of multicast groups, specifically two
additional methods for setting the membership of a multicast group which can radically
reduce the latency in setting up a group within a known cluster.

The potential for such dramatic savings is that transactional messaging within a cluster
is a radically different use-case from traditional multicast.
This covers a variety of factors:
* How is the group Selected?
* What are the endpoints that receive the messages?
* What is the duration of the group?
* Who are the potential members of the group?
* How much latency does the application tolerate?

Question 1: How is the Group Selected?

In IGMP/MLD the membership of a multicast group is controlled by the listeners joining and
leaving the group. The sender does not control or even know the recipients. This matches
the multicast streaming use-case very well. However it does not match a cluster that needs
to distribute a transactional message to a subset of a known cluster.

The target group is also assumed to be stable for a long sequence of packets, such as
streaming a video. The targeted applications direct transactions to a subset of a stable group.

One example of the need to distribute a transactional message to a subset of a known
cluster is replication within an object cluster. A set of targets has been selected
through an higher layer protocol. IGMP-style setup here adds excessive latency to the
process. The targets must be informed of their selection, they must execute IGMP joins and
confirm their joining to the source before the multicast delivery can begin. Only
replication of large storage assets can tolerate this setup penalty.

A distributed computation may similarly have data that is relevant to a specific set of
recipients within the cluster. Having to replicate the transfer over multiple unicast
connections is undesirable, as is having to incur the latency of IGMP setup.

Two solutions will be proposed where a sender can form or select a multicast group to
match a set of targets, without requiring any extra interaction with THOSE targets as long
as the targets are already members of a pre-existing multicast group. Allowing a sender to
multicast to *any* set of IP addresses would clearly be unacceptable for both security and
network administration reasons.

Question 2: What are the endpoints that receive the messages?

For the specific storage protocol we were working on the desired endpoints are virtual
drives, not IP endpoints. A given storage server can determine which of its virtual drives
is being addressed solely from the destination multicast IP address.

One of the questions for the mailing list is whether this is unique to this storage
protocol, or whether the ability to identify a multicast group as a set of higher layer
objects is generally desirable.

Question 3: What is the duration of the group?

IGMP/MLD is designed primarily for the multicast streaming use-case. A group has an
indefinite lifespan, and members come and go at any time during this lifespan, which might
be measured in minutes, hours or days.

Transactional multicasting seeks to identify a multicast group for the duration of sending
a set of multicast datagrams related to a specific transaction. Recipients either receive
the entire set of datagrams or they do not. Multicast streaming typically is transmitting
error tolerant content, such as MPEG encoded material. Transaction multicasting will
typically transmit data with some form of validating signature that allows each recipient
to confirm full reception of the transaction.

This obviously needs to be combined with applicable congestion control strategies being
deployed by the upper layer protocols. The Nexenta Replicast protocol only does bulk
transfers against reserved bandwidth, but there are probably as many solutions for this
problem as there are applications. Replicast relies upon IEEE I802.1 Datacenter Bridging
(DCB) protocols such as Priority Flow Control and Congestion Notification to provide 
no-drop service. The DCB protocols deal with the fine timing of congestion avoidance,
but require higher layer transport or application protocols to keep the sustained
traffic rates below the sustained capacity. Creating explicit reservations for bulk
transfers is the main method for accomplishing this.

The important distinction between Replicast and conventional multicast applications is
that there is no need to dynamically adjust multicast forwarding tables during the
lifespan of a transaction, while IGMP and MLD are designed to allow the addition and
deletion of members while a multicast group is in use. This distinction is not   unique to
Nexenta's Replicast storage application. Transactional replication is a common
element in cluster protocol design.

The limited duration of a transactional multicast group implies that there is no need for
the multicast forwarding element to rebuild its forwarding tables after it restarts. Any
transaction in progress will have failed, and been retried by the higher-layer protocol.
Merely limiting the rate at which it fails and restarts is all that is required of each
forwarding element.

Another implication is that there is no need for the forwarding elements to rebuild the
membership list of a transactional multicast group after the forwarding element has been
reset. The transactions using the forwarding element will all fail, and be retried by a
higher layer transport or application protocol. Assuming that forwarding elements do not
reset multiple times a minute this will have very limited impact on overall application

The duration of a transaction is application specific, but inherently limited. A failed
transaction will be retried at the application layer, so obviously it has a duration 
measured in seconds at the longest.

Question 4: Who are the members of the group?

IGMP/MLD is designed to allow any number of recipients to join or leave a group at will.

Transactional multicast requires that the group be identified as a small subset of a
pre-existing multicast group.

Building forwarding rules that are a subset of forwarding rules for an existing multicast
group can done substantially faster than creating forwarding rules  to arbitrary and
potentially previously unknown destinations.

Question 5: How much latency does the application tolerate?

While no application likes latency, multicast streaming is very tolerant of setup latency.
If the end application is viewing or listening to media, how many msecs are required to
subscribe to the group will not have a measurable impact to the end user.

For transactions in a cluster, however, every msec is delaying forward progress. The time
it takes to do an IGMP join would be a significant addition to the latency of storing an
object in an object cluster using SSD or other fast storage technology.

Proposed Method 1:

Set the multicast forwarding rules for pre-existing multicast forwarding address X to be
the subset of the forwarding rules for existing group Y required to reach a specified
member list.

This is done by communicating the same instruction (above) to each multicast forwarding
network element.  This can be done by unicast addressing with each of them, or by 
multicasting the instructions.

Each multicast forwarder will set its multicast forwarding port set to be the union of the
unicast forwarding it has for the listed members, but result must be a subset of the
forwarding ports for the parent group.

For example, consider an instruction is to create a transaction multicast group I which is
a subset of multicast group J to reach addresses A,B and C.

Addresses A and B are attached to multicast forwarder X, while C is attached to multicast
forwarder Y.

On forwarder X the forwarding rule for new group I contains:
	The forwarding port for A.
	The forwarding port for B.
	The forwarding port to forwarder Y (a hub link). This eventually leads to C.

While on forwarder Y the forwarding rule for the new group I will contain:
	The forwarding port for forwarder X (a hub link). This eventually leads to A and B.
	The forwarding port for C.

Many ethernet switches already support command line and/or SNMP methods of setting these
multicast forwarding rules, but it is challenging for an application to reliably apply the
same changes using multiple vendor specific methods. Having a standardized method of
pushing the membership of a multicast group from the sender would be desirable.

Proposed Method 2:

There is a large group of pre-configured multicast groups which are an enumeration of the
possible subsets of a master group. This will be a specific subset, such as all
combinations of 3 members for multicast group X. These groups are enumerated and assuaged
successive multicast addresses within a block.

The sender first obtains exclusive permission to utilize a portion of the reception
capacity of each desire target, and then selects the multicast address that will reach
that group.

In a straightforward enumeration of 3 members out of a group of 20, there are 20*19*18/3*2
or 1040 possible groups. Typically the higher layer protocol will have negotiated the
right to send the transaction with the member prior to selecting the multicast group. In
making the final selection, the actual multicast group is
selected and some offered targets are declined.

Those 1040 possible groups can be enumerated in order (starting with M1, M2 and M3 and
ending with M18, M19 and M20) and assigned multicast addresses from N to N+1039.

When the transaction requires reaching M4, M5 and M19, you simply select that group.
Because exclusive rights to use multicasting to M4, M5 and M19 have already been obtained
through the higher layer protocol the group [M4,M5,M19] is already exclusively claimed.

These 1040 groups may be set up through any of the following means:
* Traditional IGMP/MLD joining/leaving.
* Setting static forwarding rules using SNMP MIBs and/or switch-specific command line
 interfaces. Note that the wide-spread existence of command line interfaces to custom
 set multicast forwarding rules is an indicator that there are existing applications
 that find the exising IGMP/MLD protocols to be inadequate to fulfill their needs.
* Method 1 as described previously.

Security Considerations

The methods described here enable no sender to multicast messages to any destination
that was not already addressable by it. Therefore no new security vulnerabilities
are enabled by these techniques.


The proposal provides for two new methods to manage multicast group membership,
Thee are simple techniques, but provide  a cohesive cluster-wide approach to providing
transactional multicasting. These techniques are better suited for transactional multicasting
that the existing methods, IGMP and MLD, which are oriented to the streaming use-cases.

Caitlin Bestler
caitlin.bestler <at>
cait <at>

Re: draft-stewart-tsvwg-sctp-ndata-03.txt

Hi Michael,

Sorry for the late follow up.
Please find some feedback inline below.

Generally I should note that the section numbering in the more recent
versions of the draft does not correspond to the section numbering
of the version to which the comments were provided. Still I hope that we
can make sense of the below..

BR, Karen

> -----Original Message-----
> From: Michael Tuexen [mailto:Michael.Tuexen <at>]
> Sent: 4. juli 2014 22:42
> To: Karen E. Egede Nielsen
> Cc: Randall Stewart; tsvwg <at>; Salvatore Loreto
> Subject: Re: draft-stewart-tsvwg-sctp-ndata-03.txt
> On 05 Nov 2013, at 00:51, Karen E. Egede Nielsen
<karen.nielsen <at>>
> wrote:
> > Hi,
> >
> > Please accept the folowing comments to draft-stewart-tsvwg-sctp-ndata-
> 03.txt.
> > Please use as fit.
> Hi Karen,
> thank you very much for your comments. I'm sorry for not responding
> earlier...
> See my comments in-line.
> Best regards
> Michael
> >
> > General comments:
> > -----------------------
> >
> > The draft draft-stewart-tsvwg-sctp-ndata-03.txt, in my opinion,
> > addresses an important limitation of SCTP message fragmentation The
> > limitation is important to have removed in order to support large
> transfer by SCTP without detroying concurrent transmission of data with
> time characteristics.
> >
> > The advanced stream scheduling modes, suggested in the draft, also
> > seems very instrumental in order to instantiate different real time
> characteristics on different streams.
> >
> > Title:  Given the scheduling aspects included in the draft, one should
> consider to adjust the title so that it better accommodate for the
> parts. Actually stream scheduling seems to be main topic of the draft
> the new (or extended) data chunk format just a mean to support more
> flexible (interleaved) scheduling of fragments.
> The is correct.
> >
> > Something else:  The “N” as “New” in N-DATA seems not so future-proof.
> Perhaps E for word “Extended” (E-DATA) would be a better naming ?
> Possibly. But we are using N-DATA in several places... Will think about
> >

[Karen] A suggestion given at the tsvwg session at IETF 90 was I-data
chunk where I is for interleaving. A different alternative is the E-data
chunk where E is for extended.

> > It should be clarified in the Introduction that the draft makes use of
> Supported Extension Parameter as defined in RFC5061.
> Make sense. Done.
> >
> > Detailed Comments:
> > ---------------------------
> >
> > Section 1.1:
> > 1.       It should be clarified that the draft defines a new data
chunk option as
> well as that it defines an advanced stream scheduler function and that
> are independent functions.
> Correct. I agree.
> > 2.       It could be clarified that the intention is for the new data
chunk to be
> used for all data transmitted on a particular association (i.e., not
> fragments).
> Done.
> > 3.       It could be clarified that the usage of the new data chunk
> differentiable on a per association basis and that an SCTP
implementation as
> such shall support coexistence of associations which use the existing
> chunk format and associations which use the new data chunk format.
> Sure. Done.
> >
> > Section 3.1:
> > 1.       In the third paragraph that starts with “Sender side usage..
”, it should
> be clarified that the new data chunk is used for all data chunks and not
> only data chunks that need fragmentation.
> Fixed.
> > 2.       The situation, when the peer does not support N-DATA but the
> request it, should preferably be elaborated on in this section or
> else in the draft. Presumably then in this situation the SCTP layer
simply uses
> the legacy data chunk with its in-build limitations. However this should
> described.
> Fixed.
> > 3.       Information should preferably be provided to UL about whether
> supports usage of N-DATA. For a socket api compliant implementation such
> information could possibly be provided in an extension of SCTP_STATUS ?
> I would prefer to signal it in the SCTP_ASSOC_CHANGE indicating
> However, this goes into the socket API section.
> >

[Karen] Yes I agree that the realization of the function over the socket
api goes into the socket api section.
The requirement to provision information to ULP about what was negotiated
for the
association is part of the substance of the function and should go here.
Right ?

> > Section 4.1 – minor/editorial:
> >
> > 1.       The text could be clarified so that it more clearly refers to
> many” and to
> > “one-to-one” sockets. The text could also better describe the
behaviour of
> the socket option on each type.
> Could you be more specific where information is missing?

[Karen] Right now  the text of section 4.1.2 says that the socket option
 applies to future associations. Yes I can interpret this also for a
one-to-one style socket but I would
prefer to have this written out. Like what happens for a one-to-one
socket; is this option rejected or ignored (?)
on already established associations.

I further think that one wants to cache (as for the number of streams)
both what was negotiated as well as what
was intended to be negotiated. If the SCTP_NDATA_ENABLE, when read, tells
what was intended to be negotiated, then we need somewhere else
(e.g. SCTP_STATUS) to read what got negotiated.

> > 2.       The second paragraph sentence: “An N-DATA chunk aware
> should also set the fragment interleave level to 2” – should refer to
> appropriate option of RFC6458.
> >
> > Section 4.1 – substance:
> >
> > 1.       I would like to press for that the ability to change the
N-DATA setting
> on current (established) associations is removed. It looks to open up
for a
> number of complexities both in SCTP layer as well as in O&M layer;
E.g.,  if N-
> DATA feature is disabled, what about retransmissions where original was
> send as N-DATA. When the O&M operation is made, then how to control
> when it takes effect in the SCTP layer in respect to data already in SND
> buffer. Further the disabling only effectively can control the sending
> These details would have to be described in draft and, secondly,
> implemented, both of which could be somewhat of a challenge. Are there
> some important use-cases that demands for this “flexibility” ?
> This functionality isn't there. I agree completely with you. Isn't the
text in
> 4.1.1 on SCTP_NDATA_ENABLE clear on this?

[Karen]  The new text is much better.

Section 4.2.1 still has the following:

"and will also prevent current associations from
   producing N-DATA chunks for future large fragmented messages"

Do you really want to have this ? I would not...

> > 2.       I believe that one NEED to have the possibility, on a per
> basis, to read whether the peer supports N-DATA or not. This regardless
> whether it be an association belonging
> Isn't the notification good enough? You can't query ASCONF support,
> Reset, and so on.
> This is currently only done via the notification. I'm open to discuss a
> method...
> > to a one-to-many socket or a one-to-one socket. Support for read via
> socket api should be described in the draft. This may be provided via an
> extension of SCTP_STATUS (?). Optionally one may also prescribe for such
> information to be returned as part of an extension of RFC3873,
> sctpAssocTable object.
> Let's talk about MIB stuff in general in a separate document. We are
> MIB support for all SCTP extensions. If there is a real need in this, we
> think about updating the MIB RFC. Years ago, when I implemented it for
> FreeBSD, I had a bunch of comments.
> > 3.       Situation with association restart on SCTP level should
preferably be
> described.
> You get a new notification...
[Karen] Fine :-) .. But what I want to know is the following:

Can usage of N-DATA be re-negotiated during restart of association.
Which setting of the local side dictates what should happen on a
one-to-one association during restart.
Will SCTP layer cache what originally was set in the SCTP_NDATA_ENABLE
option and use this to guide
re-negotiation during restart ?

> >
> > Section 4.1.2:
> >
> >
> > 1.       Would it be reasonable to specify a subset of the listed
> options as something that an implementation that support N-DATA MUST
> support and others as MAY or optional.  Alternatively one may specify
that at
> least one of the options need to be supported ?
> I would just look which constants are defined... We can make a statement
> that not all implementation support all.
> > 2.       The SCTP_SS_FAIR_BANDWIDTH could be demanding from an
> implementation perspective.
> > 3.       It should be clarified that these scheduling options are
applicable for
> sending normal DATA chunks also when peer does not support usage of N-
> Yepp. I'll work on this while polishing/testing the implementation..
> >
> >
> > Possible addition to the draft content: (?)
> >
> > Possibly one could contemplate to include improvement of the receiver
> side operation also. As follows:
> >
> > ·         The SCTP receive operation could be extended to allow for
> specification of read stream scheduling  - possibly options – to start
with (RS:
> Read Scheduling):
> > o   SCTP_RS_FIRST_COME: The simple first-come, first-serve algorithm
> > is selected by using this value.  It just queues messages that are
readable in
> the order in which they have been received by the SCTP layer.
> > o   SCTP_RS_PRIORITY:  SCTP operates with a number of receive queues
> per association according to a number of priorities set. For each
> queue simple first-come, first-serve algorithm is used .I.e., for each
> queue messages are queued as readable in the order in which they have
> been received by the SCTP layer .The priority can be assigned on a per
> stream basis. Value 0 is default priority, higher values are higher
priority (or
> lower), lower values are lower priority (or higher).
> > Select, poll (BSD) and epoll (Linux) mechanism must be extended to
> support specification, and notification, of receiving readable event on
a per
> priority RCV queue basis.
> As we discussed, I think this could go into a separate document...
> >
> >
> > Editorial:
> >
> > Abstract: which which à which
> > Section 2: FSN's are unsigned number à FSN's are unsigned numbers
> Fixed.
> >
> > BR, Karen

Bob Briscoe | 13 Aug 19:14 2014

Re: Draft notes from Toronto meeting


The notes on the morning session seem to end in the middle of a 
sentence. Then the afternoon session starts. Has there been some text lost?

The break happens during the discussion of Tunnel Congestion Feedback 
(which was last in the morning). But I'm interested to know what the 
end of the discussion was.



At 13:38 28/07/2014, gorry <at> wrote:

>Please review the draft notes and send any comments/corrections, they are
>available at:

Bob Briscoe,                                                  BT 

gorry | 11 Aug 15:37 2014

TSVWG Status update, August 2014.

The list below shows the status of the working group documents as we see
it. Please check below and comment on drafts using the list. Please do
send any corrections/omissions to the chairs.

Gorry, David & James
(TSVWG Chairs)
August 2014


Document recently published:
RFC 7141, formerly draft-ietf-tsvwg-byte-pkt-congest - Document Shepherd:


IDs in RFC Editor Queue ( :


IDs in IESG processing:
draft-ietf-tsvwg-rsvp-pcn - Document Shepherd: James/David
Document adopted, status will be EXP (IETF-84 due to dependencies on RSVP)
RSVP-DIR review received (BB, KC).
WGLC concluded Friday, August 23rd, 2013.
Nov 2013, Next step new ID required to address RSVP model and then repeat
WGLC Document revised. Francois added as author.
No noted disagreement from WG.
Mar 2014, WGLC started on the updated text. Scott Bradner commented on
document in WGLC.
Because this is intended to become an Experimental RFC (and not Proposed
Standard), it was necessary to perform the IANA actions prior to
submitting the RFC publication request. - Done.
Aug 2014 - IANA actions performed, write-up submitted;
RFC publication requested.

New proposed work:
draft-fairhurst-tsvwg-circuit-breaker (adoption request on tsvwg list)
draft-eggert-tsvwg-rfc5405bis (adoption request soon)
draft-geib-tsvwg-diffserv-intercon-02.txt (next version expected to be
called for adoption)
draft-welzl-ecn-benefits (please read)

WG Drafts with Chairs:
draft-ietf-tsvwg-sctp-dtls-encaps - PS - Document Shepherd: Gorry
Replaces: draft-tuexen-tsvwg-sctp-dtls-encaps-01
WG adopted 13/12/2013. Support {AB, IR, SL, MB, TD}
[Milestone: Jan 2014, PS] Implemented in Firefox (FF21).
Required by RTCweb. Comments received.
WGLC ended 28th February 2014.
Comments from Joe Touch (draft updated)
Review comments and revised ID published.
++ Eric Rescorla has reviewed this.
DUE: Security input needed to determine text describing DTLS version.

DUE: WG Shepherd write-up to be prepared.
draft-ietf-tsvwg-sctp-prpolicies - PS - Document Shepherd: Gorry
Replaces: draft-tuexen-tsvwg-sctp-prpolicies
Nov 2013, Adopted SCTP PR Polices intended for publication as a PS RFC
March 2014, Next revision expected for WGLC.
Gorry read 20-May-2014, needs to be PS, explain Info section in wrietup
Revised ID May 2014.
1-Jul-2014 Gorry reviewed standards language
WGLC started to end July 21st, 2014
- support JHS, KN, MB, IR, GF; comments from Karen Nielson, Brian
Bidulock, Gorry
DUE: Revised ID now needed after WGLC
DUE: WG Shepherd write-up to be prepared - Gorry

WG Drafts
draft-ietf-tsvwg-port-use - Document Shepherd: Gorry
Replaces: draft-touch-tsvwg-port-use-00
- Intended to be advice to protocol designers needing a port.
5 people looked at this document, Prague IETF-80
Individual -01 July 2011
IETF-81 insufficient feedback from WG at this time.
IETF-82, discussed.
Adopted by WG Presented IETF-86, March 2013
Milestone updated to June 2014
Mar 2014, Chairs WGLC to be started after current WG actions.
- IANA review comments received
- Sent review requests to RAI, APPS, and SEC areas during 1st WGLC.
+ Comments May 2014: Paul Hoffman; Lars Eggert; IANA; David Black;
5 Jun 2014, WGLC completed - comments received.
DUE: Revised ID needed.
Replaces: draft-polk-tsvwg-rsvp-app-id-vv-profiles
-01 Presented in Beijing, IETF-79.
-02, 14-Mar-2011
Presented IETF-80.
Seek to coordinate with music with partner ID:
Gorry liaised with MMUSIC WG Chairs on companion draft (norm ref from this
tsvwg draft).
Adopted as a TSVWG work item, December 2013, [Milestone Jul 2013].
This will update a RFC 2872 (PS).
Presented at IETF-86,
Mar 2013 (no comments)
Expected ready for WGLC (waiting on MMUSIC)
DUE: Reviewers are needed to prepare for a WGLC
draft-ietf-tsvwg-natsupp-tsvwg - Document Shepherd: James
Replaces: draft-stewart-natsupp-tsvwg
Dependency from BEHAVE WG.
Adopted as a work item 21 Sept 2010 (Gorry).
WG -00, 29/11/2010 Uploaded as: draft-ietf-natsupp-tsvwg
Authors restructured draft (-03)
Added support for single and multi-homed support.
IETF-86: 3 people in meeting had read -04 or -05.
Feb 2014, Authors please update following comments and align to related
draft on SCTP NAT (conflicts found in language)
Authors expected to produce a single document to replace both.
++ Dan Wing has committed to review this.
++ Fred Baker has committed to review this.
Chairs: We plan to start a WGLC, but are expecting this document to be
restructured and merged with draft-ietf-tsvwg-sctpnat
draft-ietf-tsvwg-sctpnat - Document Shepherd: Gorry
Replaces: draft-ietf-behave-sctpnat-03.txt Adopted Nov 2013.
Former BEHAVE WG work item that defines SCTP NAT support
Feb 2014, Authors please update following comments and align to related
draft on SCTP NAT (conflicts found in language)
Chairs: - authors have requested a single document to replace both.
++ Fred Baker will review next version.
Separated the simpler case for single-homed use - this separation should
be clearer
Chairs: We plan to start a WGLC, but are expecting this document to be
restructured and merged with draft-ietf-tsvwg-sctpnat
draft-ietf-tsvwg-behave-requirements-update - Document Shepherd: David
Replaces: draft-ietf-behave-requirements-update-00
Nov 2013, Former BEHAVE WG work item intended for publication as a BCP
Mar 2014, Irene R reviewed this and found no conflict with SCTP drafts.
Some suggestions (in no particular order) for a shepherd:
++ Dave Thaler, may review, as former behave co-chair
++ David Harrington, has been around in behave, and he knows how to do
this and volunteered multiple times.
++ Ask Jana to review this.
++ Dan has committed to review this.
Chairs: Check intention and planned timeline.
DUE: Please comment on list
draft-ietf-tsvwg-sctp-failover - Document Shepherd: James
Replaces: draft-nishida-tsvwg-sctp-failover
Individual-00 Presented in Prague, IETF-80.
- Understood not to conflict with draft-tuexen-tsvwg-sctp-multipath
- PF has been coded into FreeBSD
Adopted by WG 26/6/2012. [Milestone: Jul 2013, EXP]
DUE: March 2014.
DUE: Please comment on list.
draft-ietf-tsvwg-sctp-ndata - PS
- replaces: draft-stewart-tsvwg-sctp-ndata-03 Nov 2013,
Adopted , intended for publication as a PS RFC
Mar 2014, 5-6 people had read.
DUE: Revised ID needed.
draft-tsvwg-gre-in-udp-encap - PS Document Shepherd: David
- replaces: draft-yong-tsvwg-gre-in-udp-encap
Dec 2013, Adopted , intended for publication as a PS RFC
Feb 2014, discussion of scope and applicability of circuit breakers
Mar 2014 consider MUST implement, SHOULD use in these environments for CB
DUE: Revised ID needed, waiting on RTG AD text inclusion with
draft-ietf-mpls-in-udp draft that will also be used in this draft.
draft-ietf-tsvwg-rtcweb-qos - PS - Document Shepherd: David
- Replaces: draft-dhesikan-tsvwg-rtcweb-qos
- RTCweb and QoS Markings
- Authors requested TSVWG adoption.
- Who has read the draft? (lots 10's of people)
25-Mar-2014, Adopted by tsvwg
- Who thinks it is important to do work in the IETF? (Many)
I-D updated after initial TSVWG feedback
Mar 2014, Adoption call (strong support in WG meeting London)
Adoption call concluded 24 Match 2014: intended as a PS RFC for Sept 2014
++ Magnus agreed to review this.
Mar 2014, Please subscribe to "DART" for other related discussions.
Aug 2014, DART draft (draft-ietf-dart-dscp-rtp) is now in WGLC; that draft
needs to be completed before we can WGLC this rtcweb-qos draft.
DUE: Please comment on list, see IETF DART WG.
draft-ietf-tsvwg-ecn-encap-guidelines - Document Contact: Gorry

replaced draft-briscoe-tsvwg-ecn-encap-guidelines
-00 Presented in Prague, IETF-80.
- comments at IETF-80 (see minutes)
New ID presented in Atlanta, IETF-85. ID presented in IETF-88,89
++ forward an appropriate message (perhaps your note to the mailing list
for approval to adopt) to ieee-ietf-coord <at>
++ Reviewers: Andrew McGregor, Dirk Kutscher, Richard Scheffnegger, Brian
Mar 2014, WG Call for adoption started, to end 4th March 2014
19 for, 1 against. 8 echoed on the list
Adoption call concluded and document adopted.
* ecn-encap-guidelines and AQM are the main new things they need to know
on <>IEEE802.1Q)
DUE: Please comment on list.
Expired WG documents:
draft-ietf-tsvwg-intserv-multiple-tspec - Document Shepherd: David
WG interest in this topic recorded at IETF-78.
Charter update needed to progress this work.
5 Reviews needed to determine energy/technical direction.
WG -05 (presented in Beijing, IETF-79)
WG -06 (presented in Prague, IETF-80)
2 reviews from RSVP-DIR received (Bruce Davie, ?)
2 additional reviews promised (Ken Carlberg, Francois LeF)
Chairs asked AD for a Charter update (IESG agreed)
Draft discussed at IETF-80, and request to update charter agreed
- AD advised 4 named reviewers will be required
Adopted for progression as PS, for May 2012
- New name: 'RSVP Multiple Instance'.
Draft is now expired and dead.
DUE: Draft authors will request replacement with
draft-polk-rsvp-multi-instance-object (and WG adoption of that draft in
Honolulu, IETF-91)

The following have received recent discussion at TSVWG meetings or on
the list. Inclusion in the list below does not indicate support for
these specific drafts and other contributions are also warmly welcomed.
Authors request to be considered for adoption:
draft-geib-tsvwg-diffserv-intercon-02.txt - Document Contact: David
DiffServ interconnection classes
New ID presented in Atlanta, IETF-85.
ID presented in Orlando, IETF-86, Mar 2013. Mar 2014, intended scope
unclear at IETF London Adoption call to be considered, but scope needs to
be first refined and a revised draft is necessary to avoid implications of
broader applicability.
July 2014 - ID presented in Toronto. Strong hum of support to work on
this, but a revised draft is needed first.
DUE: revised draft required, WG adoption call expected on that next version.
- Individual (Gorry & Lars)
Mar 2014, the ADs proposed the WG re-open the UDP Guidelines RFC for
update to include this work and other topics.
NOTE: Update milestone in charter, if adopted: ‘Multicast UDP Guidelines’
is being incorporated in this.
Presented IETF-90, Hum supporting adoption, none against.
++ Brian Tramwell and Jana agreed to review this.
Chairs:Adoption call to be started on list.

- Individual (Gorry Fairhurst)
Call for WG adoption issued - August 2014
DUE: Please comment on list
- Individual (no decision to adopt at this time)
- QoS-aspects to be discussed in tsvwg (thought to also be relevant to
- Individual (Michael Welzl)
- Thought to be within tsvwg or aqm WGs, to be proposed as a work item in

+++ END OF LIST +++

Ruediger.Geib | 11 Aug 12:21 2014

Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02

Hi David,

new EF related text has been added in the -01 version. I've copied 
in some text of RFC3246 related to EF remarking and policing below. 
My take:

. remarking of entire flows is an option, but no remarking of 
  packets exceeding EF capacity limits.
- looking at the EF jitter and delay properties, I doubt that 
  shaping is desirable. RFC3246 doesn't mention shaping as part 
  of EF conditioning. I personally wouldn't expect EF shaping 
  in sections where policing is applied. 
- dropping of packets exceeding EF capacity is a MUST, if I 
  interpret RFC3246 correctly.

I suggest to adapt the section of draft-dart-dscp to be more 
precise regarding the optional remarking of EF traffic and to 
remove shaping as a conditioning option if traffic is beyond 
the EF forwarding capacity limit. A Proposal for the final 

...exceeds that capacity must be dropped. EF compliant flows may 
be remarked to a different DSCP.

All other new text indicated by the Diff version looks allright.




3. Expedited Forwarding (EF) [RFC3246] intended for inelastic	
   traffic. Beyond the basic EF PHB, the VOICE-ADMIT PHB [RFC5865]	
   is an admission controlled variant of the EF PHB. Both of these	
   PHBs are based on pre-configured limited forwarding capacity;	
   traffic that exceeds that capacity may be shaped, remarked to a	
   different DSCP, or dropped.


RFC3246 (three excerpts):

   Packets belonging to a single microflow within the EF aggregate
   passing through a device SHOULD NOT experience re-ordering in normal
   operation of the device.

   Packets marked for EF PHB MAY be remarked at a DS domain boundary
   only to other codepoints that satisfy the EF PHB.  Packets marked for
   EF PHBs SHOULD NOT be demoted or promoted to another PHB by a DS

   If the EF PHB is implemented by a mechanism that allows unlimited
   preemption of other traffic (e.g., a priority queue), the
   implementation MUST include some means to limit the damage EF traffic
   could inflict on other traffic (e.g., a token bucket rate limiter).
   Traffic that exceeds this limit MUST be discarded.

-----Ursprüngliche Nachricht-----
Von: Dart [mailto:dart-bounces <at>] Im Auftrag von Ben Campbell
Gesendet: Samstag, 9. August 2014 19:50
An: dart <at>
Cc: Richard Barnes; draft-ietf-dart-dscp-rtp.all <at>; mls.ietf <at>
Betreff: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02

This is a DART Working Group Last Call of draft-ietf-dart-dscp-rtp-02. It's available on the data tracker
at the following URL:

The WGLC will conclude on 22 August, 2014. Please send your comments to the authors and the DART mailing
list. If you've reviewed it and think it's good to go, please say so.


IETF Secretariat | 11 Aug 09:32 2014

Milestones changed for tsvwg WG

Changed milestone "Submit 'DTLS Encapsulation of SCTP Packets for
RTCWEB ' to IESG for consideration as a Proposed Standard RFC", set
due date to October 2014 from January 2014.

Changed milestone "Submit 'Recommendations for Transport Port Uses' to
the IESG", set due date to December 2014 from June 2014.


karagian | 10 Aug 08:31 2014

FW: New Version Notification - draft-ietf-tsvwg-rsvp-pcn-09.txt

Hi all,

Please note that in the new version of the RSVP over PCN draft, see below, we have incorporated the IANA
changes associated with the recommendations of Francois.

Best regards,

Van: internet-drafts <at> [internet-drafts <at>]
Verzonden: zondag 10 augustus 2014 8:25
Aan: tsvwg-chairs <at>; draft-ietf-tsvwg-rsvp-pcn <at>; spencerdawkins.ietf <at>
Onderwerp: New Version Notification - draft-ietf-tsvwg-rsvp-pcn-09.txt

A new version (-09) has been submitted for draft-ietf-tsvwg-rsvp-pcn:

The IETF datatracker page for this Internet-Draft is:

Diff from previous version:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at

IETF Secretariat.