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
(Continue reading)

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,
(Continue reading)

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
(Continue reading)

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.



(Continue reading)

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.

Black, David | 8 Aug 02:06 2014

WG Adoption Call for draft-fairhurst-tsvwg-circuit-breaker- 22 August 2014

The TSVWG chairs are considering adoption of the above draft. This draft
has been discussed at previous IETF meetings and on the list.

At the recent Toronto IETF meeting, the draft received strong support from
the people present in the meeting room, and no comments against adopting
this draft as a TSVWG work item.

The WG chairs now invite any further comments on this adoption. If there
are concerns or comments about adoption please send comments to the list
or to the Chairs.  We plan to make a final decision on this adoption on
22 August 2014.

Also, would the draft author (Gorry) please send a note to the list
indicating whether you know of any IPR related to this draft that
requires disclosure in accordance with BCP 79.  Needless to say,
Gorry is recused from this decision, as he is the author of this draft.

--David (tsvwg WG co-chair)
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786 <at>        Mobile: +1 (978) 394-7754

RFC Errata System | 6 Aug 14:22 2014

[Editorial Errata Reported] RFC4960 (4071)

The following errata report has been submitted for RFC4960,
"Stream Control Transmission Protocol".

You may review the report below and at:

Type: Editorial
Reported by: Federico Zuccardi Merli <federico.zuccardimerli <at>>

Section: 6.1

Original Text
      However, regardless of the value of rwnd (including if it is 0),
      the data sender can always have one DATA chunk in flight to the
      receiver if allowed by cwnd (see rule B below).  This rule allows
      the sender to probe for a change in rwnd that the sender missed
      due to the SACK having been lost in transit from the data receiver
      to the data sender.

Corrected Text

The whole paragraph is a one-to-one repetition of the final part of first paragraph of Rule A).
The position of the paragraph does not affect meaning, but the repetition hinders readability.
(Continue reading)

gorry | 28 Jul 14:38 2014

Draft notes from Toronto meeting

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


Michael Tuexen | 22 Jul 16:21 2014

Name of the new DATA chunk

Dear all,

it was suggested to use I-DATA chunk for Interleaving DATA chunk as a better
name for the chunk defined in

Any opinons?

Best regards