gmane.ietf.tsvwg

WGLC for draft-ietf-tsvwg-byte-pkt-congest-10 - to conclude 28th June 2013

Gorry Fairhurst — 2013-06-19T15:25:23

This email announces the beginning of a short working group last call 
for draft-ietf-tsvwg-byte-pkt-congest-10, "Byte and Packet Congestion 
Notification". This document is now thought by the authors to be ready 
to proceed to be published as a Proposed Standard, it completed  a 
former WGLC and has since received review by the IESG and was 
subsequently revised. Please send any comments on version -10 to the 
TSVWG list.

The draft is available at:
http://tools.ietf.org/html/draft-ietf-tsvwg-byte-pkt-congest

The last call will run for one week, ending Friday, 28th June 2013.
Emails saying "I support" or "I don't support" are also most helpful in
judging the consensus.

James, David and Gorry
(TSVWG Chairs)

New version of draft-suznjevic-tsvwg-mtd-tcmtf

Mirko Sužnjević — 2013-06-14T11:54:05

Hello,
We have just submitted the new version of draft  draft-suznjevic-tsvwg-mtd-tcmtf-01 renamed Delay Limits and Multiplexing Policies to be employed with Tunneling Compressed Multiplexed Traffic Flows http://tools.ietf.org/html/draft-suznjevic-tsvwg-mtd-tcmtf-01.
It is an extension of tcmtf http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/. Since a specific list for tcmtf exists (tcmtf< at >ietf.org<mailto:tcmtf< at >ietf.org>), the idea is to discuss it there.
The draft contains recommendations for TCMTF multiplexing period for different network services as well as description of several policies required in the process of packet multiplexing.
We are discussing to revise the draft once more before the IETF meeting in Berlin so your feedback will be very welcome. Thank you.
Sincerely,
Mirko Suznjevic

Fwd: Confirmation for Auto-Post of I-Ddraft-shepherd-multicast-udp-guidelines

Greg Shepherd — 2013-06-13T15:29:26

I'd like an agenda slot in Berlin to discuss this work.

Thanks,
Greg

---------- Forwarded message ----------
From: IETF I-D Submission Tool <idsubmission< at >ietf.org>
Date: Wed, Jun 12, 2013 at 10:30 AM
Subject: Confirmation for Auto-Post of I-D
draft-shepherd-multicast-udp-guidelines
To: Greg Shepherd <gjshep< at >gmail.com>

Hi,

The IETF datatracker draft submission service has received your draft
draft-shepherd-multicast-udp-guidelines-01, and requires a
confirmation step in order to be able to complete the posting of
the draft.

Please follow this link to the page where you can confirm the posting:
Confirmation URL:
http://datatracker.ietf.org/submit/status/51145/confirm/1b4e70f5499fef25c2d9d6c7990b8e06df9c81b8/

Best regards,

        The IETF Secretariat
        through the draft submission service

[Technical Errata Reported] RFC3168 (3639)

RFC Errata System — 2013-06-05T20:11:02

The following errata report has been submitted for RFC3168,
"The Addition of Explicit Congestion Notification (ECN) to IP".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3168&eid=3639

--------------------------------------
Type: Technical
Reported by: Richard Scheffenegger <rs< at >netapp.com>

Section: 6.1 / 6.1.3

Original Text
-------------
Section 6.1 says:

* The receiver receives the packet with the CE codepoint set, and
sets the ECN-Echo flag in its next TCP ACK sent to the sender.
[...]

* The sender sets the CWR flag in the TCP header of the next
packet sent to the receiver to acknowledge its receipt of and
reaction to the ECN-Echo flag.

Section 6.1.3 says:

When TCP receives a CE data packet at the destination end-system, the
TCP data receiver sets the ECN-Echo flag in the TCP header of the
subsequent ACK packet.

[...]
The TCP receiver uses the
CWR flag received from the TCP sender to determine when to stop
setting the ECN-Echo flag.

Corrected Text
--------------
Section 6.1.3 should say:

The TCP receiver uses the
CWR flag received from the TCP sender to determine when to stop
setting the ECN-Echo flag. This check has to be performed before
checking if the received segment is CE marked.

Notes
-----
The ordering of the text in the bullet points in section 6.1, and the text in section 6.1.3 can led to inappropriate implementations. At least Section 6.1.3 should be strict about the handling of CE-marked CWR-segments.

If CE is checked first, and ECE set, and thereafter CWR used to disable ECE, a CE-marked CWR segment will not result in the sending of an additional window of ECEs.

All derivatives of BSD used to

First, set ECE because of CE
Second, reset ECE because of CWR

However, the "authorative" NS2 sample code, the TBIT tool, Windows, Solaris and Linux would

First, reset ECE because of CWR
Second, set ECE because of CE

The latter approach seems to be the sensible one, and it was quickly fixed:

http://lists.freebsd.org/pipermail/freebsd-bugs/2010-April/039450.html

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC3168 (draft-ietf-tsvwg-ecn-04)
--------------------------------------
Title : The Addition of Explicit Congestion Notification (ECN) to IP
Publication Date : September 2001
Author(s) : K. Ramakrishnan, S. Floyd, D. Black
Category : PROPOSED STANDARD
Source : Transport Area Working Group
Area : Transport
Stream : IETF
Verifying Party : IESG

FW: New Version Notification for draft-yong-tsvwg-gre-in-udp-encap-00.txt

Lucy yong — 2013-06-05T14:10:58

Hello,

FYI. We upload this new draft that addresses the inputs and suggestions for draft-yong-tsvwg-upd-encp-4-ip-tunneling prior to and in IETF86. Look forward to seeing the feedback on this draft.

Thanks,
Lucy

[Editorial Errata Reported] RFC3168 (3636)

RFC Errata System — 2013-06-04T13:30:09

The following errata report has been submitted for RFC3168,
"The Addition of Explicit Congestion Notification (ECN) to IP".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3168&eid=3636

--------------------------------------
Type: Editorial
Reported by: Mirja Kühlewind <mirja.kuehlewind< at >ikr.uni-stuttgart.de>

Section: 6.1.1.

Original Text
-------------
If the TCP connection does not
wish to use ECN notification for a particular packet, the sending TCP
sets the ECN codepoint to not-ECT, and the TCP receiver ignores the
CE codepoint in the received packet.

Corrected Text
--------------
If the TCP connection does not
wish to use ECN notification for a particular packet, the sending TCP
sets the ECN codepoint to not-ECT.

Notes
-----
CE should not be set on not-ECT capable packets. If this happens anyway, the CE codepoint would overwrite the ECT codepoint. Thus there is no way for the receiver to know it should ignore the CE codepoint; the sentence is therefore nonsensical.

draft-ietf-tsvwg-sctp-failover: comments and suggestions

Salvatore Loreto — 2013-05-27T13:34:31

Hi there,

Karen (in cc) and I have reviewed together the draft and written down 
the following comments and suggestions


- Section 5.1: CWND Handling for Potentially Failed Destinations

The draft speaks about setting the CWND to 1 MTU (or 2MTU ?) when a 
Potentially Failed Path (destination) is reinstated
in ACTIVE state as a result of the receipt of an HB ACK.

We are not sure what is the motivation for any special measures to be 
taken in this situation.

Generally the CWND settings are governed by RFC4960 prescriptions as to 
set the CWND to 1 MTU after T3-rtx (but not afterHB timeout)
as well as RFC4960 guidelines to converge the CWND to the initial CWND 
towards idle destination addresses.

We believe, in this respect, it is appropriate to keep the standard 
behaviour of RFC4960.



- Section 5.3: Permanent Failover

We have good experiences from live networks with running SCTP in a “no 
switchback” mode of operation with no automatic migration
back to a preferred primary path. Once the primary path is left due to 
it being potentially failed, then a selected alternative path automatically
becomes the new primary path.

This mode of operation corresponds to a simplified variant of the 
permanent failover operation proposed in [CAR002]
with alpha = beta = SCTP_PEER_ADDR:THLDS. The mode of operation is run 
with notifications of change of primary path being provided
to upper layers via RFC6458 SCTP_PEER_ADDR_CHANGE semantics 
(SCTP_ADDR_MADE_PRIM).

The mode of operation does not suit all purposes, but in networks 
environments where a number of equally preferred paths are available,
then by this mode of operation one minimizes the effects of unnecessary 
path bouncing and the thereby associated effects of throughput
degradation due to path changes and slow start operation.

Based on our experiences we would recommend and support that the 
Permanent Failover mode of operation, at least in the simple variant
described above, is promoted as a valid alternative approach. For the 
purpose of activation of this mode of operation a switchback (or failover)
mode operation parameter could be introduced as configurable by the 
introduction of an appropriate new read/write socket option in the 
Socket API.




- Section 5.4: The impact of HB timeouts in association error counter

The draft recommends for excluding HB timeouts from contributing to the 
(association) error counter. We fully support this approach for
all timeouts of HBs that are send to probe the state of destinations 
addresses that are in PF state and we would even propose for the draft
to demand that generally timeouts stemming from HBs, which are not sent 
on the Primary Path, will be excluded from the association error counter.

Thereby the association error counter and thus the association fate 
reflects the forward progress of the data transmission to peer endpoint 
while
at the same time it will be appropriately isolated from timeouts of HBs 
sent on non-data carrying paths.

Allowing timeout of HBs sent on the Primary Path to impact the 
association error counter will serve to validate the aliveness of the 
peer endpoint
when there is no data in transit.

This suggestion follows the thought expressed in 
http://www.ietf.org/mail-archive/web/tsvwg/current/msg11294.html and it 
is thus believed
to fulfil the original intend of RFC4960.



- Section 5.1 Thoughts on the destination address state machine

In RFC4960 address state machine, notification of cease of use of the 
current primary path as transmission path for new data is provided to 
upper layer
via (coupled with) the announcement of the destination as being 
UNREACHABLE. With the introduction of the potentially failed state as a 
semi-hidden
state (not resulting in notified state transition to UL) the information 
on the fail-over to use a new data carrying path is lost.
While there may be merits in suppressing notifications on potentially 
failed addresses, then we believe that it is unfortunate that the 
notification
of failover from usage of the primary path for new data is lost.
This is especially problematic in path bouncing scenarios where the 
primary path is unstable but still works some. E.g., HBs may go through,
but the path breaks (data transmission fails) as soon as it is more 
loaded. In such a situation no notifications may be generated to UL,
even if new data transmission consistently cycles to and from the 
primary path. The solution to such path bouncing scenarios will have to come
from more advanced path failover mechanism, like [CAR002] (and would not 
be solved just by notification), but it would be a great help if appropriate
notifications were provided.

CFP Packet Video 2013 - Special Session on Low-LatencyInteractive Video

Stein Gjessing — 2013-05-15T15:11:41

Hi,
Here is an excellent venue for discussions and publication of results.

Cheers,
Stein
__________________________________________________________

Packet Video 2013 - Special Session on Low-Latency Interactive Video
Sponsored by IEEE Communications Society
December 12. and 13., 2013, San Jose, Ca, USA

Call for papers.

http://pv2013.itec.aau.at/call-for-papers/accepted-special-sessions/#ss1

Several years ago, it was found that users do not like video quality fluctuations. At that time the predominant belief was that network rate fluctuations should be minimized, in order to reasonably interoperate with TCP in the network. This led to the creation of a number of so-called "TCP-friendly" congestion controls that exhibit a smoother sending rate than TCP, while avoiding to send more than a conformant TCP under similar conditions. TFRC is perhaps the best known example of such a congestion control mechanism.

A lot has happened since then:
• The notion of TCP-friendliness has received massive criticism; the widespread deployment of a more aggressive TCP variant, CUBIC, has not led to an Internet meltdown, making the case that diverging from strict TCP-friendliness is possible.
• Latency minimization has become a major goal, especially in the face of “bufferbloat”: large delays from large buffers with simplistic FIFO-queue management.
• Codecs have improved; novel video codecs are able to adjust the data rate, but modern codecs may also produce variable bitrate transmissions with burstier packet flows than before.
• TFRC has been embedded in the DCCP protocol, which has probably never been used for anything other than experiments; instead of running over DCCP, RTP-based applications now contain proprietary congestion control mechanisms.

The emergence of the RTCWEB protocol suite for real-time communication between Web browsers has renewed the interest in developing congestion control standards for real-time media. This time, however, the goal is to get things right: delay should be minimized, and standards should realize congestion control using RTP with RTCP signaling. The IETF “Real-time Media Congestion Avoidance Techniques” (RMCAT) working group has been founded to address this need. New questions arise: what type of congestion controls do we need? How much feedback should we send? How do we make this work in multi-user scenarios, e.g., for video conferencing? What should be the API between a video codec and a new delay-based congestion controlled RTP stream? What is the quality that can be expected from the combination of a codec and congestion control mechanism, when we consider better metrics than plain PSNR?

Topics of interest include, but are not limited to:
• Congestion control algorithms for interactive real-time video: requirements, evaluation criteria, and mechanisms
• Necessary RTP/RTCP extensions
• Field experience with video codecs in a low-delay, real-time setting
• Interactions between applications and RTP flows
• Failing to meet real-time schedules: impact, techniques to detect, instrument or diagnose it

Organizers:
• Michael Welzl, University of Oslo (michawe at ifi.uio.no)
• Stein Gjessing, University of Oslo (steing at ifi.uio.no)

FW: NomCom 2013-2014 Call for Volunteers - CORRECTED dates in first sentence

Black, David — 2013-05-13T22:31:49

Please give some thought to participating in this year's NomCom.
This is a great way to contribute to the IETF.

Thanks,
--David


-----Original Message-----
From: ietf-announce-bounces< at >ietf.org [mailto:ietf-announce-bounces< at >ietf.org] On Behalf Of Mankin, Allison
Sent: Monday, May 13, 2013 5:27 PM
To: ietf-announce< at >ietf.org
Subject: NomCom 2013-2014 Call for Volunteers - CORRECTED dates in first sentence

The IETF nominating committee (nomcom) process for 2013-14 has begun. The 
IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB,
and the IESG. Ten voting members for the nomcom are selected in a verifiably
random way from a pool of volunteers. The more volunteers, the better chance
we have of choosing a random yet representative cross section of the IETF
population.  This year, a challenge:  let's get beyond the 100-mark for
number of volunteers.  Let's get to 200 volunteers!

The details of the operation of the nomcom can be found in RFC 3777.  
 
Volunteers must have attended 3 of the past 5 IETF meetings.  As specified in
RFC 3777, that means three out of the five past meetings up to the time this
email announcement goes out to start the solicitation of volunteers. The five
meetings out of which you must have attended three are IETF 82, 83, 84, 85, 86.

If you qualify, please volunteer.  However, much as we want this, before you 
decide to volunteer, please be sure you are willing to forgo appointment
to any of the positions for which this nomcom is responsible.  
 
The list of people and posts whose terms end with the March 2014 IETF
meeting, and thus the positions for which this nomcom is responsible, are

IAOC:
Chris Griffiths

IAB:

Bernard Aboba
Marc Blanchet
Ross Callon
Eliot Lear
Hannes Tschofenig

IESG:

Barry Leiba (Applications)
Brian Haberman (Internet)
Benoit Claise (Operations and Management)
Gonzalo Camarillo (RAI)
Stewart Bryant (Routing)
Sean Turner (Security)
Martin Stiemerling (Transport)

The primary activity for this nomcom will begin in July 2013 and should be
completed in January 2014.  The nomcom will have regularly scheduled
conference calls to ensure progress.  There will be activities to collect 
requirements from the community, review candidate questionnaires, review
feedback from community members about candidates, and talk to 
candidates.  Thus, being a nomcom member does require some time commitment.

Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours) 
June 16, 2013, as follows:

To: amankin< at >verisign.com
Subject: Nomcom 2013-14 Volunteer

Please include the following information in the email body:

 <Your Full Name>   
  // First/Given Name followed by Last/Family Name
  // matching how you enter it in the IETF Registration Form)
 <Current Primary Affiliation>
  // Typically what goes in the Company field
  // in the IETF Registration Form
[<All email addresses used to register for the past 5 IETF meetings>]
 <Preferred email address>  
 <Telephone number> 
  // For confirmation if selected

You should expect an email response from me within 3 business days stating
whether or not you are qualified.  If you don't receive this response,
please re-send your email with the tag "RESEND"" added to the subject line.

If you are not yet sure if you would like to volunteer, please consider
that nomcom members play a very important role in shaping the leadership
of the IETF. Volunteering for the nomcom is a great way to contribute
to the IETF! 

I will be publishing a more detailed target timetable, as well as details 
of the randomness seeds to be used for the RFC 3797 selection process, 
within the next couple weeks.  

Thank you!
Allison Mankin
amankin< at >verisign.com

P.S. Because the 2012-2013 nomcom is still at work, we cannot use the ietf
addresses for the nomcom chair or the nomcom committee yet, so please send
all the volunteer mail (and any questions/comments you may have) to the 
address given.

QUESTION on Return of SACKs and HB ACKs

2013-05-07T10:05:43

Hi,

RFC4960 in Section 6.4 opens up for the possibility that SACKs may be returned on a different path (or IP Path)
that the reflected path (or IP Path) of the incoming Data.

This, as said in RFC4960, can be the situation when a SACK acknowledges Data TSNs that have come in on different paths as well as it
 may (MAY) be a beneficial reaction if evidence is available that indicates the unavailability of the reflected data path. Such unavailability
evidence could come from arrival of duplicate Data chunks (as pointed to in RFC4960) possibly such evidence could also be established
by other means (like e.g., if HBs indicates the reflected Path to be unavailable). The latter aspect are not mentioned in RFC4960.

I am wondering, if anybody (IETF SCTP community and/or RFC4960 Authors) has any view on the validity (or the contrary) of
not returning SACKs on the reflected IP Path ?

Obviously it is very important for the path selection for return of SACKs to be as
stable and consistent as feasible, as one otherwise risks to jeopardize the validity of Data RTT measurements of peer, and using the reflected IP path
is one way to achieve this. But having said this, then I wonder if there otherwise are considered to be significant problems with the
return of SACKs via paths there are different from the reflected IP Path of Data. Issues that makes is so that an SCTP implementation should best possible prevent situations where data and SACK do not follow the same path (in opposite directions).

Possibly also the situation with return of SACKs acknowledging Data chunks that have come in on multiple paths will be even more relevant for CMT-SCTP.
This may open up for either demanding for SACKs to be returned split according to the incoming path of Data or for the recommendation of RFC4960 to use reflected path of Data to be broaden up to recommend for consistent choice of return path of SACKs.

Finally following the thoughts above for SACK return, then one may also think about the corresponding situation with the return of HB ACKs.

RFC4960 seems to assume for HB ACKs always to be returned on the reflected path of the HB as it says, Section 3.3.6, but notably the only Keyword
that applies to return of HB ACK is the SHOULD of Section 6.4 :

A HEARTBEAT ACK is always
   sent to the source IP address of the IP datagram containing the
   HEARTBEAT chunk to which this ack is responding.

Also here one can wonder as to whether it is best to have the HB ACK returned in the path over which it is most likely to reach peer or whether
it must (?) be returned on the reflect path of the incoming HB. I am not sure if the RFC4960 SHOULD here should be read mostly as a MUST or mostly as a
SHOULD unless other things make it beneficiary to use a different path ?

A BIG Thanks in Advance !

BR, Karen

10 IW also for SCTP

2013-05-06T10:46:34

Hi,

Experimental RFC6928 proposes to increase initial window for TCP from the 4 segments from RFC3390
to 10 segments.

From RC2960 to RFC4960, SCTP was augmented to operate with initial window of 4MTUs following RFC3390.
Indeed RFC4460 says the following:

"RFC 2960 was published with the intention of having the same
   congestion control properties as TCP.  Since the publication of RFC
   2960, TCP's initial congestion window size has been increased via RFC
   3390.  This same update will be needed for SCTP to keep SCTP's
   congestion control properties equivalent to that of TCP."

From a technical perspective there does not seem to be anything in RFC6928 that is particularly specific to TCP compared with SCTP and based on this observation I suppose that it would be equally relevant to think about introducing an equivalent experimental usage of larger IWs, up to 10MTUs, also for SCTP and to have such usage be appropriately specified at some point in time.

I wonder if this is also how the tsvwg sees this ?

Thanks!

BR, Karen

Follow-up: PIE performance in cable modem environments

Preethi Natarajan — 2013-04-23T23:18:43

Hello,

This is a follow-up to Greg White's (from Cable Labs) talk at the recent
ICCRG meeting on PIE's performance in cable modem environments.

Post the meeting, Greg was kind to share his ns-2 DOCSIS model with us. We
investigated PIE's performance using this model. The key items from this
investigation: 
1. Bug in PIE code: The previous PIE release (that Greg used for
evaluations) was missing a line of code. This missing line brings down drop
probability under certain conditions and turns out to be critical for the
cable modem scenario. Without this line of code, the drop probability
remains high and takes longer to come down even when the queue delay has
remained lower than the reference. The updated ns-2 PIE code can be found
here  ftp://ftpeng.cisco.com/pie/.
2. Bug in ns-2 TCP/Linux: Greg's cable modem simulations used the TCP Cubic
variant. We discovered a serious bug in ns-2 TCP/Linux Agent (confirmed by
Dr. Injong Rhee's team) that makes TCP/Cubic senders very aggressive and
unresponsive to packet drops/notifications, pretty much like UDP traffic.
Please find more details about the bug here --
http://sourceforge.net/tracker/?func=detail&aid=3608750&group_id=149743&atid
=775392.
We are working with Cable Labs to verify the cable modem results, they'll
soon be available on our FTP site along with the PIE code.

A technical paper about PIE was recently accepted at the IEEE Conference on
High Performance Switching and Routing 2013. A copy of the paper is attached
here.

The Linux PIE implementation is expected to be ready by next week and we'll
follow-up on that as well.

Many thanks,
Preethi on behalf of PIE team.

ports that have been (widely) used

Martin Stiemerling — 2013-04-22T15:31:22

Hi all,

Here is a message from Stephen Farrell (SEC AD). He isn't subscribed to 
the tsvwg list, but had a question when reviewing [1].

I'm personally also interested to see what the people's opinion is.



*************************
I see that you've a draft [1] in progress that offers guidance to
folks who are requesting port allocations.

We've seen a few cases recently where well-meaning folk turned up
and asked for ports to be allocated that have been widely used for
some years. For example [2] is one such where I shepherded the
5742 review.

I think it'd be great if [1] offered guidance to people who are
trying to regularise such situations.

Personally, I would hope that guidance would lean more towards
keeping things working that have been working, but in any case I
think clear IETF consensus guidance would be very useful here no
matter what that guidance is.

Thanks,
Stephen.

[1] http://tools.ietf.org/html/draft-ietf-tsvwg-port-use-01
[2]
https://datatracker.ietf.org/doc/draft-hartmann-default-port-for-irc-via-tls-ssl/

************************

Thanks,

   Martin

TSVWG Draft Status Notes - 8th April 2013

2013-04-08T07:10:08

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.

Best wishes,

Gorry, David & James
(TSVWG Chairs)
Mar 2013


---
Recently published:

draft-ietf-tsvwg-sctpsocket was published as RFC 6458.
draft-ietf-tsvwg-sctp-strrst was published as RFC 6535.
draft-ietf-tsvwg-source-quench was published as RFC 6633.

-------------------------------------------------------------------
IDs in RFC Editor Queue:
http://www.rfc-editor.org/queue.html
None.

-------------------------------------------------------------------
IDs in IESG processing:

draft-ietf-tsvwg-sctp-udp-encap - Document Shepherd: Gorry
(Replaced: draft-tuexen-sctp-udp-encap)
Lars sent a note as AD agreeing to progress this work.
Work was coordinated with DCCP work on encaps.
draft-tuexen-sctp-udp-encaps-06, January 10, 2011
Adopted as a work item 21 Sept 2011 (Gorry)
WG -02 8 Dec 2011
WGLC completed Friday 20th April 2012, many discussion and notes that
there were implementations (including: FreeBSD and released in 9.1 & MacOS
X)
ID was ready for AD submission, 20th Oct 2012
Checked IANA port usage. IANA issue resolved, UDP port will be owned by IETF.
IESG comments incorporated.
STATUS: Shortened WGLC to end 5th April 2013.
{Supported in WGLC: GF; TD; MW; BM; IR} - Recommended publication.
DUE: Waiting for AD-reveiw to publish.
---

draft-ietf-tsvwg-byte-pkt-congest - Document Shepherd: Gorry
New editor added Jul 2010.
New revision 25 Oct 2010.
WG -01, June 10, 2011
IETF-81: discussed whether this should be BCP.
ADs & Chairs agree to progress as a BCP
Status changed to BCP (new-ID WG -05)
Presented at IETF-82 (Taipei), request for WGLC.
Gorry added as Shepherd (Jan 2012), Wes added as responsible AD (Jun 2012).
WGLC concluded with comments on I-D, Friday 30th March 2012.
Draft version of write-up sent to list, comments received.
- Gorry working with authors to clear list of WGLC questions (5 sept 2012).
WG Chair received version that includes additional feedback during WGLC
STATUS: IETF LC feedback; IESG Review - with AD.
-------------------------------------------------------------------
WG Drafts with Chairs:
draft-ietf-tsvwg-sctp-sack-immediately - Document Shepherd: Gorry
Replaces: draft-tuexen-tsvwg-sctp-sack-immediately
-05, 2011-01-02
- Aug 2011, discussed on list and issues raised.
- Implemented in BSD & Linux- 2 reviews received.
- WG adoption call after IETF-85, started 13/12/2013. Support {AB, IR, SL,
MB, TD}
- Implemented/released in FreeBSD, partially implemented in Linux
- Adopted as a work item. [Milestone: May 2013, PS]
- No major remaining comments at IETF-86, March 2013.
DUE: WGLC ending Friday 5th April 2013
{Supported in WGLC: TD; MW; DB; GF; YN; AB} - summary sent 8th April 2013
{Comments include: DB; YN; AB; MW}
DUE: Feedback during WGLC: Revised I-D needed

-------------------------------------------------------------------
WG Drafts:

draft-ietf-tsvwg-rsvp-pcn - Document Shepherd: James
Replaces: draft-karagiannis-pcn-tsvwg-rsvp-pcn
WG interest in this topic recorded at IETF-81.
Individual -01, 2011-07-11
AD decision allowed this to be added to the milestones
Document adopted, status will be EXP (IETF-84 due to dependencies on PCN
RFCs)
WG -00 8 Oct 2011
RSVP-DIR review received (BB).
MILESTONE EXPIRED.
DUE: Please comment on RVSP & PCN aspects; Revised I-D needed
---

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
WG -01, June 1, 2011
Authors restructured draft (-03)
Added support for single and multi-homed support.br>IETF-86: 3 people in
meeting had read -04 or -05.
DUE: Authors please update following comments to TSVWG.
DUE: Please comment on list - MILESTONE EXPIRED.
---
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
WG adoption was approved - request to comment to list on 26/6/2012.
Adopted by WG. [Milestone: Jul 2013, EXP]
DUE: Please comment on list.
---
draft-ietf-tsvwg-sctp-dtls-encaps - Document Shepherd: Gorry
Replaces: draft-tuexen-tsvwg-sctp-dtls-encaps-01
Implemented in Firefox, Chrome interested.
RTCweb requires this.
WG adoption call after IETF-85. Adoption started 13/12/2013. Support {AB,
IR, SL, MB, TD}
Implemented in Firefox (FF21)
Adopted as a work item. [Milestone: Jan 2014, PS]
DUE: Please comment on list.
---
draft-ietf-tsvwg-intserv-multiple-tspec - Document Shepherd: David
WG interest in this topic recorded at IETF-78.
Charter update would be 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)
RSVP directorate was consulted.
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 approach presented following WG comments, revised MILESTONE needed.
DUE: Discussion needed on list.
---

draft-ietf-tsvwg-port-use-00 - Document Shepherd: Gorry
Replaces: draft-touch-tsvwg-port-use-00
- Intended to be advice to protocol designers needing a port.
5 people have 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
DUE: Please read an individual sections and provide feedback!
DUE: Please comment to list.
---

draft-ietf-tsvwg-rsvp-app-id-vv-profiles
Replaces: draft-polk-tsvwg-rsvp-app-id-vv-profiles
-01 Presented in Beijing, IETF-79.
-02, 14-Mar-2011
Presented IET-80.
WG needs to assess if the new draft should be a work item.
Seek to coordinate with music with partner ID:
draft-polk-mmusic-traffic-class-for-sdp
Gorry liaised with MMUSIC WG Chairs on companion draft (norm ref from this
tsvwg draft), intended for LC early 2013.
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)
Thought ready for joint call with related draft in MMUSIC.
DUE: Reviewers are needed to prepare for a WGLC.
DUE: Waiting for WG feedback.

-------------------------------------------------------------------
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.

draft-polk-tsvwg-rfc4594-update - Document Contact: David
Discussed at IETF-83, Paris
Noted at IETF-84, but not discussed (no time).
ID-discussed at IETF-85.
DUE: Please comment on list.
---

draft-polk-tsvwg-new-dscp-assignments - Document Contact: David
- noted at IETF-84, but not discussed (no time).
Linked to above
DUE: Please comment on list.
---

draft-stewart-tsvwg-sctpecn-02
Partially replaces (draft-stewart-tsvwg-sctp-nonce)
IETF-78 suggested there was interest in this topic.
Discussed at IETF-83, Paris.
ECN was confirmed to be within the TSVWG Charter
DUE: A call for adoption will be made on the list, please comment on this
draft.

---

draft-tuexen-tsvwg-sctp-multipath (CMT)
-00 Presented in Prague, IETF-80.
- understood not to conflict with draft-nishida-tsvwg-sctp-failover
- Implemented in FreeBSD (ns2, inet)
- subsumes NR-SACK
-01, 2010-12-27
DUE: Please comment to list.
DUE: Need to decide if this can be adopted as a WG Item
---------------------------------------------------------------

Related non-TSVWG items:

draft-ietf-behave-sctpnat-03.txt
BEHAVE WG item linked to SCTP encapsulation work.
---
draft-ohanlon-rmcat-dflow
Discussed at IETF-84, Vancouver
This draft is related to the new rmcat work.
Comments received on list prior to IETF-85.
DUE: Revised ID needed
------------------------------------------------------------------
Other news:
ITU-T Study Group 12 Liaison on QoS Classes & markings for interconnection

------------------------------------------------------------------
Other drafts history:

waiting on:
draft-ietf-tsvwg-natsupp-04
---

draft-briscoe-tsvwg-ecn-encap-guidelines - Document Contact: Gorry
-00 Presented in Prague, IETF-80.
- comments at IETF-80 (see minutes)
Authors need to update this draft.
New ID presented in Atlanta, IETF-85.
DUE: Please comment on list.
---
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.
DUE: Please comment on list.
---
draft-carlberg-tsvwg-ecn-reactions
Reactions to Signaling from ECN Support for RTP/RTCP
-00 presented IETF-82
Not yet requested to become a work item.
- This draft is related to the new rmcat work.
DUE: Please comment on list.
---
draft-ietf-idr-sla-exchange-00
Inter-domain SLA Exchange
- QoS aspects thought to fall within TSVWG charter

---
draft-yong-tsvwg-udp-encap-4-ip-tunneling
ID presented in Orlando, IETF-86, Mar 2013.
- Thought to fall within TSVWG charter
- Need to coordinate with UDP-Guidelines and Checksum Guidelines
---

Other drafts linked to this space:

draft-ietf-mpls-in-udp
draft-kumar-softwire-uet-00
draft-xu-softwire-ip-in-udp-01
draft-shepherd-multicast-udp-guidelines-00 Multicast UDP Usage Guidelines
for Application Designers
Announced at Orlando, IETF-86, Mar 2013 (no presentation)
- Thought to fall within TSVWG charter
- Need to confirm need by RTCweb

---
draft-tuexen-tsvwg-sctp-prpolicies
- Thought to fall within TSVWG charter
- Need to confirm need by RTCweb

---
draft-fairhurst-tsvwg-buffers-00 Advice on network buffering
ID presented to ICCRG in Orlando, IETF-86, Mar 2013.
---
May be related to ECN work in TSVWG:

draft-zhang-tsvwg-tunnel-congestion-exposure

WGLC for draft-ietf-tsvwg-sctp-udp-encaps-14 to confirm changes- Concluded

2013-04-08T06:50:44

This email concludes the shortened  WGLC period.  There was consensus to
proceed with publication (5 notes) of support) and no notes that suggest
the new wording in this version of the document needs to be changed.

The Chairs will recommend that this document proceed to be published by
the RFC-Ed.

Best wishes,

Gorry
(as TSVWG Co-Chair).

Fwd: [MMUSIC] Review of draft-ietf-mmusic-sctp-sdp-03

James Polk — 2013-03-20T18:53:27

<chair hat on>

this review by Magnus might be of interest to some in this WG.

please comment on the MMUSIC list though, for 
those WG chair's to be aware of your support/comments, concerns, or whatever...

James

review of draft-ietf-tsvwg-sctp-dtls-encaps-00

Magnus Westerlund — 2013-03-20T12:56:53

Hi,

I have reviewed the SCTP in DTLS encapsulation draft and have some
comments.

1. Abstract:
SCTP
   over DTLS is used by the RTCWeb protocol suite for transporting non-
   media data between browsers.

I think if one likes to include something like this in the abstract one
should word it like "An initial usage of ..."

2. Section 5.5:
   The SCTP implementation MUST support the extension defined in
   [RFC3758].

I wonder why this is required in a protocol encapsulation declaration?
This specification is from my perspective a common tool that anyone that
has similar requirements as WebRTC can choose to use. CLUE WG is clearly
one with high probability to have need for UDP/DTLS/SCTP. However, I
don't yet know if CLUE for example has any requirements that requires
partial reliability.

So please explain why mandating the partial reliability is necessary for
a DTLS encapsulation of SCTP. I think it is fine for the RTCWEB data
channel document to mandate the support of the PR-SCTP extension in the
context of WebRTC. But, please try to have the correct specifications in
the appropriate places.

3. Section 5.6:
The same as 2) appears to be true also here. Are there reasons why one
needs this extension when one uses the DTLS encapsulation?

4. Section 5.7:
To my understanding this is a pure performance enchancement. Thus I
wonder over the SHOULD level of an extension that yet not exist. I think
it is fine to indicate the issue. And if you actually have a draft ready
do an informative reference. But I do question the need for a normative
reference here. Isn't it better to let this specification be published
in a timely fashion?

5. Section 5.8:
Yet another case of a potential issue when running in common context
with real-time applications. This encapsulation does not in any way is
solely for real-time applications. Thus I think both using MAY is
unwarranted and I question how necessary this whole discussion are.

I think this document is suffering from an issue of not getting the
correct separation between the documents. This needs to specify the DTLS
encapsualtion of SCTP and what is needed. But I think is the wrong place
to have requirements on SCTP extensions that are specific in the context
of particular applications or class of applications. So please ensure
that you have the basics of the encapsulation in place, then ensure that
the extensions can be negotiated and allow the applications to make the
choices it needs on what features of SCTP it requires.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund< at >ericsson.com
----------------------------------------------------------------------

Query regarding heartbeat re-transmission pattern

Ankit Mahawar — 2013-03-20T09:46:56

Hi All ,

I have a basic query regarding SCTP heartbeat re-transmission pattern .

As per the RFC 4960 :

Furthermore, when its peer is multi-homed, an endpoint SHOULD try to
retransmit a chunk that timed out to an active destination transport
address that is different from the last destination address to which the
DATA chunk was sent.

Also,
When retransmitting data that timed out, if the endpoint is multi-homed, it
should consider each source-destination address pair in its retransmission
selection policy.  When retransmitting timed-out data, the endpoint should
attempt to pick the most divergent source-destination pair from the
original source-destination pair to which the packet was transmitted.

Suppose if we have multihomed SCTP endpoints A and B .

A                      B

a.a.a.p               b.b.b.p
a.a.a.s               b.b.b.s

If we transmit heartbeat from a.a.a.s to b.b.b.s and it is not acknowledged
so does it re-transmit it using the same src and destination or with
a.a.a.p to b.b.b.s.

Please help to understand .

Thanks

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you

I-D Action: draft-ietf-tsvwg-sctp-udp-encaps-14.txt

2013-03-19T17:18:03

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           : UDP Encapsulation of SCTP Packets for End-Host to End-Host Communication
Author(s)       : Michael Tuexen
                          Randall R. Stewart
Filename        : draft-ietf-tsvwg-sctp-udp-encaps-14.txt
Pages           : 12
Date            : 2013-03-19

Abstract:
   This document describes a simple method of encapsulating SCTP Packets
   into UDP packets and its limitations.  This allows the usage of SCTP
   in networks with legacy NAT not supporting SCTP.  It can also be used
   to implement SCTP on hosts without directly accessing the IP-layer,
   for example implementing it as part of the application without
   requiring special privileges.

   Please note that this document only describes the functionality
   required within an SCTP stack to add on UDP encapsulation, providing
   only those mechanisms for two end-hosts to communicate with each
   other over UDP ports.  In particular, it does not provide mechanisms
   to determine whether UDP encapsulation is being used by the peer, nor
   the mechanisms for determining which remote UDP port number can be
   used.  These functions are are out of scope for this document.

   This document covers only end-hosts and not tunneling (egress or
   ingress) end-points.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-udp-encaps

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-udp-encaps-14

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-udp-encaps-14


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Draft TSVWG notes for IETF-86, Orlando.

2013-03-19T09:07:25

The draft notes for the WG's meetings in Orlando have been posted to the
proceedings site:
http://www.ietf.org/proceedings/86/minutes/minutes-86-tsvwg

Thanks to this meeting's TSVWG Note-Takers:
   Enrico Marocco - Monday
   John Leslie - Additional notetaker, Monday.
   Scott Brim - Thursday

Please send any comments/corrections to the list or to me directly,

Best wishes,

Gorry
(TSVWG Co-Chair)

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

2013-03-16T19:13:02

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           : SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol
Author(s)       : Michael Tuexen
                          Irene Ruengeler
                          Randall R. Stewart
Filename        : draft-ietf-tsvwg-sctp-sack-immediately-02.txt
Pages           : 7
Date            : 2013-03-16

Abstract:
   This document updates RFC 4960 by defining a method for the sender of
   a DATA chunk to indicate that the corresponding SACK chunk should be
   sent back immediately and not be delayed.  It is done by specifying a
   bit in the DATA chunk header, called the I-bit, which can get set
   either by the SCTP implementation or by the application using an SCTP
   stack.  Since unknown flags in chunk headers are ignored by SCTP
   implementations, this extension does not introduce any
   interoperability problems.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-sack-immediately

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-sack-immediately-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-sack-immediately-02


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/