http://blog.gmane.org/gmane.ietf.tsvwg hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.tsvwg/9351 <pre>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 cri</pre> Stein Gjessing 2013-05-15T15:11:41 http://comments.gmane.org/gmane.ietf.tsvwg/9350 <pre>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&lt; at &gt;ietf.org [mailto:ietf-announce-bounces&lt; at &gt;ietf.org] On Behalf Of Mankin, Allison Sent: Monday, May 13, 2013 5:27 PM To: ietf-announce&lt; at &gt;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 pa</pre> Black, David 2013-05-13T22:31:49 http://comments.gmane.org/gmane.ietf.tsvwg/9344 <pre>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</pre> Karen.Nielsen< at >tieto.com 2013-05-07T10:05:43 http://comments.gmane.org/gmane.ietf.tsvwg/9334 <pre>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 </pre> Karen.Nielsen< at >tieto.com 2013-05-06T10:46:34 http://comments.gmane.org/gmane.ietf.tsvwg/9330 <pre>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 pack</pre> Preethi Natarajan 2013-04-23T23:18:43 http://comments.gmane.org/gmane.ietf.tsvwg/9316 <pre>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-por</pre> Martin Stiemerling 2013-04-22T15:31:22 http://comments.gmane.org/gmane.ietf.tsvwg/9302 <pre>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 &amp; 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 </pre> gorry< at >erg.abdn.ac.uk 2013-04-08T07:10:08 http://comments.gmane.org/gmane.ietf.tsvwg/9300 <pre>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). </pre> gorry< at >erg.abdn.ac.uk 2013-04-08T06:50:44 http://comments.gmane.org/gmane.ietf.tsvwg/9226 <pre>&lt;chair hat on&gt; 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 </pre> James Polk 2013-03-20T18:53:27 http://comments.gmane.org/gmane.ietf.tsvwg/9223 <pre>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</pre> Magnus Westerlund 2013-03-20T12:56:53 http://comments.gmane.org/gmane.ietf.tsvwg/9221 <pre> 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. Ple</pre> Ankit Mahawar 2013-03-20T09:46:56 http://comments.gmane.org/gmane.ietf.tsvwg/9204 <pre> 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 t</pre> internet-drafts< at >ietf.org 2013-03-19T17:18:03 http://comments.gmane.org/gmane.ietf.tsvwg/9201 <pre>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) </pre> gorry< at >erg.abdn.ac.uk 2013-03-19T09:07:25 http://comments.gmane.org/gmane.ietf.tsvwg/9190 <pre> 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 proble</pre> internet-drafts< at >ietf.org 2013-03-16T19:13:02 http://comments.gmane.org/gmane.ietf.tsvwg/9183 <pre>This is about the other RFC 4594 update topic discussed yesterday in Orlando. The RFC 4594 update draft proposes to introduce a new diffserv class for (high-resolution) telepresence video. That new class would be split out of the Multimedia Conferencing class. FWIW, that Multimedia Conferencing is also the source out off which the new Video (Conferencing) class for interactive video will be split (the WG already has rough consensus on the need for this new Video class). Here's the relevant slide content from Orlando (slide 1 from the slide deck on Diffserv Service Class Questions): "Hi-Res" NEW - For video and audio/video conferencing - Created for policy-based treatment different than "Video" Question #1: Is this new class needed? The sense of the room was not clearly "Yes" - for that reason, questions #2 and #3 in the slides were not asked in Orlando. I heard considerably more of a hum for "No" than "Yes" and a similar level of hum for "Not sure" as for "Yes". Please comment on the need (or </pre> Black, David 2013-03-15T18:29:00 http://comments.gmane.org/gmane.ietf.tsvwg/9182 <pre>This could look like a protocol update to RFC 4960. - It seems to change a field in the receiver behaviour, I'm not sure whether this should be seen as an update to the base spec or not, have you thought about this? - If it does, maybe you could add: updates="RFC 4960 (if published)". There is also one detail I think should be clear: - I understand that it says this is backwards compatible. - I therefore read this as the receiver side of this logic is optional, if so, saying this is a backwards-compatible optional extension in the abstract is good (no RFC 2119 language in the abstract). Best wishes, Gorry </pre> gorry< at >erg.abdn.ac.uk 2013-03-15T16:45:07 http://comments.gmane.org/gmane.ietf.tsvwg/9179 <pre>The discussion of the Audio service class in the RFC 4594 update draft in the tsvwg meeting yesterday reached a couple of initial conclusions that need to be checked on the list: (1) The class is being renamed from "Telephony" to "Audio", in part because "Telephony" is interpreted to include video in some contexts and that's not intended here. There have also been some slight changes/generalizations to the description. (2) The newly-standardized Voice-Admit PHB is being added to the Audio class. In the absence of objection on the list, these directions will be confirmed as the rough consensus of the tsvwg WG - please comment. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA  01748 +1 (508) 293-7953             FAX: +1 (508) 293-7786 david.black&lt; at &gt;emc.com        Mobile: +1 (978) 394-7754 ---------------------------------------------------- </pre> Black, David 2013-03-15T12:35:40 http://comments.gmane.org/gmane.ietf.tsvwg/9176 <pre> 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-01.txt Pages : 7 Date : 2013-03-14 Abstract: This document defines 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. 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 availab</pre> internet-drafts< at >ietf.org 2013-03-14T19:36:13 http://comments.gmane.org/gmane.ietf.tsvwg/9156 <pre>I've done a fairly detailed read of the above draft, and have some specific comments that I'd like to submit as an individual as we head towards WGLC. Gorry (as an individual) --- Abstract - The abstract will be read by people who do not read any other part of the document. I think the current abstract is terse. It doesn't say some things which I think it should. Missing is a statement that says this defines a new chunk flag, called the I-bit, that can be set by the SCTP stack or by an application. Section 1 "According to [RFC4960] the receiver of a DATA chunk should use delayed SACKs." - I think it is important to say why this is normally the right thing to do - e.g. this remains the normal case. "In specific situations the delaying of SACKs results in reduced performance of the protocol" - A separate subsection on examples of usage, would be really useful (see note on section 4.1), You could then (forward) refer to this here. Section 4.1 "Reasons for setting the I-bit include</pre> Gorry Fairhurst 2013-03-13T15:36:34 http://comments.gmane.org/gmane.ietf.tsvwg/9154 <pre>I don't have an answer to that question, but Mark Allman from ICIR did attempt to characterize buffer bloat on the Internet through an empirical study that appeared in the January edition of CCR. You can find a reference to that paper at the following URL: http://www.sigcomm.org/ccr/papers/2013/January/2427036.2427041 Eliot </pre> Eliot Lear 2013-03-13T14:23:48 http://comments.gmane.org/gmane.ietf.tsvwg/9147 <pre>As it turns out, I'm not going to be able to attend the tsvwg meeting, and specifically the AQM discussion, Thursday. For some reason I hd it in my head that it would be this morning, and was looking forward to it. Thursday, it conflicts with isis, and I will be presenting in isis. To that end, let me express the considerations I hold with regard to AQM, RED, CoDel, and other alternatives. Please think of this as me standing at the mike and babbling... Fred Baker, Random Router Vendor In my opinion, AQM technologies and the recommendation of RFC 2309 are important to the Internet. As Jim Gettys has commented in the BufferBloat discussion and documents from RFCs 896 and 970 through SIGCOMM and INFOCOMM in the 1980's and 1990's have discussed, it is in the interest of all applications to manage their rate of flow to a dull roar, for for their own benefit and for others they compete with. CUBIC and NewReno, in their zeal to achieve maximum bandwidth, drive their traffic outstanding (effective window) to what</pre> Fred Baker (fred 2013-03-12T11:37:24 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.tsvwg