From sandeepkandula30@gmail.com Mon Aug 1 00:13:54 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4788521F8541 for ; Mon, 1 Aug 2011 00:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cq8Rqs1Huxcv for ; Mon, 1 Aug 2011 00:13:53 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3310621F853E for ; Mon, 1 Aug 2011 00:13:52 -0700 (PDT) Received: by wyj26 with SMTP id 26so1112856wyj.31 for ; Mon, 01 Aug 2011 00:13:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=DAZvSMz2aHEa83XnjS8uDv6Okf2c+m3lFgyDdoO8E9M=; b=kvzzeuUqs1U5EbyVXDka2POPGghMwY6W3MHFyZmfjUcx8vD9KULQZz1Q9NYt5Kjnl0 WMir0nEtTcn26g53XNWkvKM5QsNMuInSEUV8WueEm0YIHkDoe2mR3Qpypkl7800ELcps 9ylKo55poZF90MNS6jQivkZhAv4DSpUo2Jlyw= Received: by 10.216.135.71 with SMTP id t49mr370571wei.43.1312182837059; Mon, 01 Aug 2011 00:13:57 -0700 (PDT) MIME-Version: 1.0 Sender: sandeepkandula30@gmail.com Received: by 10.216.133.94 with HTTP; Mon, 1 Aug 2011 00:13:37 -0700 (PDT) In-Reply-To: References: From: sandeep kandula Date: Mon, 1 Aug 2011 12:43:37 +0530 X-Google-Sender-Auth: jT8iXJm9dKM2gTVOKhCQNgfx9OM Message-ID: Subject: Query: OpenSSL compatibility with LK-SCTP Transport. To: lksctp-developers , tsvwg Content-Type: multipart/alternative; boundary=0016e6de17d3e221ad04a96c5f2c Cc: Rashm! Agrawal X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 07:13:54 -0000 --0016e6de17d3e221ad04a96c5f2c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi All, I=92m a new baby to open source world. Please forgive me, if I posted this query to a wrong mailing list. Here is my query. Currently I have a proprietary application which uses LKSCTP (Open source SCTP implementation) stack. And I=92m planning use the =93Transport Layer Security=94 for the SCTP transport provided by the LKSCT= P community, as suggested by RFC 3436. (http://www.ietf.org/rfc/rfc3436.txt) Can somebody help me regarding this, by answering following quires? 1. Can I use TLS (Transport Layer Security) with LKSCTP, without losing any of my SCTP features? If =93No=94 What are SCTP features I cannot use wi= th TLS. 2. Is OPENSSL is correct choice for this? If =93No=94 Why cannot I use OpenSSL for this? Do you have any other suggestion please help me. 3. What are the limitations if I use the TLS for my application through SCTP transport? Please let me know if you have any suggestion or more information regarding the same. Thanks in advance for your help. --=20 Regards, Sandeep. --0016e6de17d3e221ad04a96c5f2c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi All,

I=92m a new baby to open source world. Please f= orgive me, if I posted this query to a wrong mailing list.

Here is m= y query. Currently I have a proprietary application which uses LKSCTP (Open= source SCTP implementation) stack. And I=92m planning use the =93Transport= Layer Security=94 for the SCTP transport provided by the LKSCTP community,= as suggested by RFC 3436. (http://www.ietf.org/rfc/rfc3436.txt)

Can somebody help me regarding this, by answering following quires?
=
1.=A0=A0=A0 Can I use TLS (Transport Layer Security) with LKSCTP, witho= ut losing any of my SCTP features? If =93No=94 What are SCTP features I can= not use with TLS.
2.=A0=A0=A0 Is OPENSSL is correct choice for this? If =93No=94 Why cannot I= use OpenSSL for this? Do you have any other suggestion please help me.
= 3.=A0=A0=A0 What are the limitations if I use the TLS for my application th= rough SCTP transport?

Please let me know if you have any suggestion or more information regar= ding the same.
Thanks in advance for your help.



--
Regards,
Sandee= p.
--0016e6de17d3e221ad04a96c5f2c-- From Michael.Tuexen@lurchi.franken.de Mon Aug 1 01:12:40 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2CB021F84DF for ; Mon, 1 Aug 2011 01:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGYeZsvHxkAw for ; Mon, 1 Aug 2011 01:12:40 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id D071D21F84DD for ; Mon, 1 Aug 2011 01:12:39 -0700 (PDT) Received: from [192.168.1.195] (p508FC7A4.dip.t-dialin.net [80.143.199.164]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 116981C0C0BCA; Mon, 1 Aug 2011 10:12:41 +0200 (CEST) Subject: Re: Query: OpenSSL compatibility with LK-SCTP Transport. Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Date: Mon, 1 Aug 2011 10:12:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: sandeep kandula X-Mailer: Apple Mail (2.1084) Cc: tsvwg , lksctp-developers , Rashm! Agrawal X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 08:12:40 -0000 On Aug 1, 2011, at 9:13 AM, sandeep kandula wrote: >=20 > Hi All, >=20 > I=92m a new baby to open source world. Please forgive me, if I posted = this query to a wrong mailing list. >=20 > Here is my query. Currently I have a proprietary application which = uses LKSCTP (Open source SCTP implementation) stack. And I=92m planning = use the =93Transport Layer Security=94 for the SCTP transport provided = by the LKSCTP community, as suggested by RFC 3436. = (http://www.ietf.org/rfc/rfc3436.txt) >=20 > Can somebody help me regarding this, by answering following quires? >=20 > 1. Can I use TLS (Transport Layer Security) with LKSCTP, without = losing any of my SCTP features? If =93No=94 What are SCTP features I = cannot use with TLS. You can not use unordered delivery and PR-SCTP. Since OpenSSL does = require a 1-to-1 relation between SSL objects and BIOs, there is no easy way to use OpenSSL to = realize TLS/SCTP. To overcome this limitations you can use DTLS/SCTP, which is specified = in http://tools.ietf.org/html/rfc6083 and you can get an implementation for OpenSSL from http://sctp.fh-muenster.de/dtls-patches.html (at the table called 'Features' almost at the bottom of the page) I supports recent versions of FreeBSD and LKSCTP in on a 3.0 kernel. You = need a patch for the netinet/sctp.h file, which I can send you privately. I hope this clarifies also your other questions. Best regards Michael > 2. Is OPENSSL is correct choice for this? If =93No=94 Why cannot I = use OpenSSL for this? Do you have any other suggestion please help me. > 3. What are the limitations if I use the TLS for my application = through SCTP transport?=20 >=20 > Please let me know if you have any suggestion or more information = regarding the same. > Thanks in advance for your help. >=20 >=20 >=20 > --=20 > Regards, > Sandeep. From bob.briscoe@bt.com Mon Aug 1 07:17:38 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF9A21F8C43 for ; Mon, 1 Aug 2011 07:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwFOXlq35D2n for ; Mon, 1 Aug 2011 07:17:36 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by ietfa.amsl.com (Postfix) with ESMTP id 84E4621F8C42 for ; Mon, 1 Aug 2011 07:17:35 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Aug 2011 15:17:40 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Aug 2011 15:17:40 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1312208256606; Mon, 1 Aug 2011 15:17:36 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.253]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p71EHafC017368; Mon, 1 Aug 2011 15:17:36 +0100 Message-Id: <201108011417.p71EHafC017368@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 01 Aug 2011 10:17:24 -0400 To: Fred Baker From: Bob Briscoe Subject: Re: Review draft-ietf-tsvwg-byte-pkt-congest-04 ? In-Reply-To: <36A3BFC5-889D-4470-88BE-36D6E8758AF5@cisco.com> References: <201107290734.p6T7Ymk1025025@bagheera.jungle.bt.co.uk> <36A3BFC5-889D-4470-88BE-36D6E8758AF5@cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_518683036==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 01 Aug 2011 14:17:40.0516 (UTC) FILETIME=[C5A35640:01CC5055] Cc: tsvwg list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 14:17:38 -0000 --=====================_518683036==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Fred, Tx for review. inline responses... At 00:35 31/07/2011, Fred Baker wrote: >On Jul 28, 2011, at 11:14 PM, Bob Briscoe wrote: > > Would you be willing to review this, now it is well-baked? > > > > It had wide review earlier in its life, but only 2 or 3 reviews > since we reorganised it to make it easier to read (hopefully). > >Sure Bob. > > > Abstract > > > > This memo concerns dropping or marking packets using active queue > > management (AQM) such as random early detection (RED) or pre- > > congestion notification (PCN). > >This sentence seems to mix apples and orangutans. RED is an AQM >procedure, meaning that it decides by some mechanism what packets to >do something to with a view to active queue management. The >structure of the sentence would suggest that PCN is also an AQM >procedure. I'll argue that either the AQM procedure uses dropping >and/or PCN for signaling or the drop/mark mechanism uses AQM to >decide what do affect and the signaling procedure to comminicate. >While they both (RED/AQM and PCN, as well as dropping) merit mention >in the abstract, I wouldn't put them parallel in the sentence. You >can't really say "I think I'll turn off RED and turn on PCN". The structure of your sentences above implies you are considering PCN to be the name of the encoding of the signals, or perhaps the field they are encoded in. That's not so. PCN is an AQM algorithm [RFC5670] that uses an encoding of the DS & ECN fields to signal [RFC5696]. They aren't PCN signals, they are signals in the DS/ECN fields from a PCN algorithm. (Confusingly, PCN is also the term for a whole admission control architecture [RFC5559]). From RFC5670: " Note that although [RFC3168] defines a broadly RED-like (Random Early Detection) default congestion marking behaviour, it allows alternatives to be defined; this document defines such an alternative. " Turning off RED and turning on PCN is precisely what you do to enable PCN (for a particular set of DSCPs). If you're happy with this explanation, is the abstract still OK as it stands? > > We give three strong recommendations: > > (1) packet size should be taken into account when transports read > > congestion indications, (2) packet size should not be taken into > > account when network equipment creates congestion signals (marking, > > dropping), and therefore (3) the byte-mode packet drop variant of the > > RED AQM algorithm that drops fewer small packets should not be used. > >Wow. Before I go into the draft itself, let me comment on how I have >historically come down on Van and Sally's debate here. > >If one is dropping traffic to signal congestion, the only loss that >TCP or SCTP is cognizant of in that sense is the loss of data >packets. Dropping a SYN, SYN-ACK, INIT, or whatever prevents a >session from opening, dropping a FIN/RST/etc prevents it from >closing, and dropping an ACK delays a signal releasing state in the >transport and potentially triggering new transmissions. None of >those have anything to do with the congestion window. Hence, if I >could understand TCP traffic in the place that queues are managed >(which I often cannot - the data is encrypted, or I'm on another >card that simply doesn't have that visibility) I would restrict >congestion-management signals in the form of loss to data segments. > >Ditto if someone is marking TCP/SCTP traffic; ECN depends on a >signal returning on data packets, and as a result is primarily >implemented (by TCP) in data packets. One could argue that I could >learn CE from an Ack or whatever, but I'm not sure why I would >bother, as communicating it back requires saving it somewhere as >opposed to simply including it in a reply I'm going to send anyway. > >The question of doing it on bytes vs packets was never, to my >knowledge, about preventing the loss of small packets. It was about >working effectively with TCP's congestion control mechanisms and >managing router resources. Van wanted us to integrate packet depth >because router resources were measured in buffers, which are the >same size regardless of how much data they contain (in some >implementations), and Sally wanted it on bytes because that was a >reasonable heuristic for identifying data segments, which interact >better with TCP's mechanisms. > >Having for 30+ years worked on equipment that was able to chain >relatively small buffers to store a larger message, Van's argument >has always seemed incomplete to me, and Sally's makes sense >mechanistically. So I have generally come down on the side of bytes... Yup. I'm aware of this debate. The doc addresses it head on. >But, whatever. On to your document... > >I have dropped your entire document into my mail window. Text I >don't have a problem with I will simply hack out, copying back text >I have questions about. I assume that you can find it in the >document by the markers I leave behind or by common search >functions. I'm not going to say "[snip]"... > > > 1. Introduction > > > When notifying congestion, the problem of how (and whether) to take > ^...the participants in a session of the onset of... OK > > packet sizes into account has exercised the minds of researchers and > > practitioners for as long as active queue management (AQM) has been > > discussed. Indeed, one reason AQM was originally introduced was to > > reduce the lock-out effects that small packets can have on large > > packets in drop-tail queues. > >True, but I'll note that large packets can have a lock-out effect on >small packets as well. RFCs 896 and 970, at least, worried about >small packets not because there were so many of them, but because >they implied the presence of additional IP and TCP headers and as a >result relatively inefficient use of the line. Yup. Just to check: you're not asking us to change anything in this para, just noting? (A transport benefits from using the Nagle algo without the network additionally biasing drop probability towards small packets.) > > The byte vs. packet dilemma arises at three stages in the congestion > > notification process: > > > > Measuring congestion: When the congested resource decides locally to > > measure how congested it is, should the queue measure its length > > in bytes or packets? > > > > Encoding congestion notification into the wire protocol: When the > > congested network resource decides whether to notify the level of > > congestion by dropping or marking a particular packet, should its > > decision depend on the byte-size of the particular packet being > > dropped or marked? > > > > Decoding congestion notification from the wire protocol: When the > > transport interprets the notification in order to decide how much > > to respond to congestion, should it take into account the byte- > > size of each missing or marked packet? > > > > Consensus has emerged over the years concerning the first stage: > > whether queues are measured in bytes or packets, termed byte-mode > > queue measurement or packet-mode queue measurement. This memo > > records this consensus in the RFC Series. In summary the choice > > solely depends on whether the resource is congested by bytes or > > packets. > >If you're recording a consensus for posterity, I think it needs to >be more clearly stated. Do you mean "the consensus is that both >choices are viable; the implementor or operator should choose to >measure whatever is congesting his links"? I personally don't hear a >clear statement here about (1). All the clear statements are in S.2 Recommendations. So we need to say: "Section 2.1 of this memo records this consensus in the RFC Series." > > The controversy is mainly around the last two stages: whether to > > allow for the size of the specific packet notifying congestion i) > > when the network encodes or ii) when the transport decodes the > > congestion notification. >... > > The primary purpose of this memo is to build a definitive consensus > > against deliberate preferential treatment for small packets in AQM > > algorithms and to record this advice within the RFC series. It > > recommends that (1) packet size should be taken into account when > > transports read congestion indications, (2) not when network > > equipment writes them. > > >I have read the rest of the paper, but let me stop here and make >some generalizations. > >First, I expected to find some data or pointers to data. There are >in fact some pointers to other documents. The vast majority of the >statements in the document that might be supported by data appear to >say "80% of those we might have expected to respond didn't, but..." >or something like that. I'd be a lot happier with statements of the >form "we ran a test..." or "we were able to construct a proof that >the mathematics tells us..." The subsections of S.3 give all the motivating arguments. * Some are in the form of a proof (S.3.1 on scaling). * Some (S.3.2) are in form of layering arguments about where the more generic functions should be placed. Are we going to make AQM decisions depend on inspection of the structure of transport protocols like TCP, SCTP, DCCP, RTP etc etc. (assuming no IPsec)? * Yes, some (e.g. S.3.3 on DoS) ought to reference empirical data to back them up. We need to add a ref here to tests of the performance for small packets of byte-mode drop (such results were not intended to show that small packet DoS works, but they do). * Some are in the form of statements of a security vulnerability (S.3.4 small != control) If performance were the issue, then I would agree that references to performance studies would be necessary. However, whether a future protocol design can be made to go slightly faster if the network does byte-mode drop, versus the end-system taking account of packet size is a moot question in the presence of larger arguments of scaling and security vulnerabilities. This document isn't about which AQM design gives the best performance if we hold the TCP design static. It's about the constraints we are faced with for future protocol design beyond TCP. >Second, I disagree with the argument about a "perverse favoring of >small packets". At least in implementations I'm familiar with, the >policy isn't "drop only large packets"; it's "make the drop >probability of a packet proportional to the ratio of its size to the >bit rate of the link". Yup. >If all packets are 9000 bytes and you're on an STM-4 link, the drop >probability of a packet is proportional to (8*9000)/622000000. If >all packets are 64 bytes, the drop probability of any given packet >is proportional to (8*64)/622000000, which is smaller, but there are >9000/64 times as many to choose from. Any given bit on the wire has >the same probability of being contained in a packet that got lost. I believe there's a mistake here. To see why it's a mistake, I'll carry through the numerical example to the end (as in Appx A.2). Assume the constant of proportionality in both your cases is 100, that is: Drop prob of large pkts is 100*(8*9000)/622000000 ~ 1.2% Drop prob of small pkts is 100*(8*64)/622000000 ~ 0.0082% Let's compare the losses from a stream of 64,000 large pkts vs 9,000,000 small pkts Each stream contains the same number of bytes (64,000*9,000 = 9,000,000*64 = 576MB) so it will last for the same time on the same link. Number of large pkts dropped by byte-mode drop = 100*(8*9000)/622000000 * 64,000 = 1.2% * 64,000 = 741 large packets Number of small pkts dropped by byte-mode drop = 100*(8*64)/622000000 * 9,000,000 = 0.0082% * 9,000,000 = 741 small packets Number of Bytes dropped in large packets by byte-mode drop = 741*9,000B = 6.67MB Number of Bytes dropped in small packets by byte-mode drop = 741*64B = 47.4kB With byte-mode drop, any given bit on the wire does NOT have the same probability of being contained in a packet that got lost. Yes, there are 9000/64 times as many small packets to choose from. Therefore in order to drop a bit with the same probability no matter what size packet it is in, each small packet should be dropped with the SAME probability as a large packet (packet-mode drop). With the same probability per packet, the dice is thrown 9000/64 times more often for small packets, but if the outcome is a drop, the amount of bytes lost is only 64/9000 times as much. These two already cancel each other out. So there's no need to deflate the probability of dropping small packets further. >On the other hand, if packets are variable in size and you're keying >off packet depth, a bit on the wire that is contained in a small >packet has a much greater proportional probability of being tagged >than one in a large packet. I think your phrase "keying off packet depth" means measuring queue length in packets, rather than deciding the probability of dropping a particular packet based on its size. If so, I don't believe the second part of the sentence is correct. When a small packet arrives at a queue of packets of different sizes, its /own/ size doesn't make any difference to the number of packets in the queue. That's why the draft separates out how you measure the queue length, from how you calculate the probability of tagging a particular packet. >I don't see that one is incented to send small packets; if the >probability that a given bit gets lost is the same regardless of >size, it seems to me that it takes size out of the discussion. Exactly. I agree that the goal is for the probability of losing a bit to be independent of the size of packet it happens to be in. But byte-mode drop fails that test (miserably). Packet-mode drop passes. >I'll go back and read the paper again a couple of times before >commenting further. Thanks again for your time on this. Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design --=====================_518683036==.ALT Content-Type: text/html; charset="us-ascii" Fred,

Tx for review. inline responses...

At 00:35 31/07/2011, Fred Baker wrote:

On Jul 28, 2011, at 11:14 PM, Bob Briscoe wrote:
> Would you be willing to review this, now it is well-baked?
>
> It had wide review earlier in its life, but only 2 or 3 reviews since we reorganised it to make it easier to read (hopefully).

Sure Bob.

> Abstract
>
>    This memo concerns dropping or marking packets using active queue
>    management (AQM) such as random early detection (RED) or pre-
>    congestion notification (PCN).

This sentence seems to mix apples and orangutans. RED is an AQM procedure, meaning that it decides by some mechanism what packets to do something to with a view to active queue management. The structure of the sentence would suggest that PCN is also an AQM procedure. I'll argue that either the AQM procedure uses dropping and/or PCN for signaling or the drop/mark mechanism uses AQM to decide what do affect and the signaling procedure to comminicate. While they both (RED/AQM and PCN, as well as dropping) merit mention in the abstract, I wouldn't put them parallel in the sentence. You can't really say "I think I'll turn off RED and turn on PCN".

The structure of your sentences above implies you are considering PCN to be the name of the encoding of the signals, or perhaps the field they are encoded in. That's not so.

PCN is an AQM algorithm [RFC5670] that uses an encoding of the DS & ECN fields to signal [RFC5696]. They aren't PCN signals, they are signals in the DS/ECN fields from a PCN algorithm.

(Confusingly, PCN is also the term for a whole admission control architecture [RFC5559]).

From RFC5670:
"
   Note that although
[RFC3168] defines a
broadly RED-like (Random Early
   Detection) default congestion marking behaviour, it allows
   alternatives to be defined; this document defines such an
   alternative.
"

Turning off RED and turning on PCN is precisely what you do to enable PCN (for a particular set of DSCPs).

If you're happy with this explanation, is the abstract still OK as it stands?

>    We give three strong recommendations:
>    (1) packet size should be taken into account when transports read
>    congestion indications, (2) packet size should not be taken into
>    account when network equipment creates congestion signals (marking,
>    dropping), and therefore (3) the byte-mode packet drop variant of the
>    RED AQM algorithm that drops fewer small packets should not be used.

Wow. Before I go into the draft itself, let me comment on how I have historically come down on Van and Sally's debate here.

If one is dropping traffic to signal congestion, the only loss that TCP or SCTP is cognizant of in that sense is the loss of data packets. Dropping a SYN, SYN-ACK, INIT, or whatever prevents a session from opening, dropping a FIN/RST/etc prevents it from closing, and dropping an ACK delays a signal releasing state in the transport and potentially triggering new transmissions. None of those have anything to do with the congestion window. Hence, if I could understand TCP traffic in the place that queues are managed (which I often cannot - the data is encrypted, or I'm on another card that simply doesn't have that visibility) I would restrict congestion-management signals in the form of loss to data segments.

Ditto if someone is marking TCP/SCTP traffic; ECN depends on a signal returning on data packets, and as a result is primarily implemented (by TCP) in data packets. One could argue that I could learn CE from an Ack or whatever, but I'm not sure why I would bother, as communicating it back requires saving it somewhere as opposed to simply including it in a reply I'm going to send anyway.

The question of doing it on bytes vs packets was never, to my knowledge, about preventing the loss of small packets. It was about working effectively with TCP's congestion control mechanisms and managing router resources. Van wanted us to integrate packet depth because router resources were measured in buffers, which are the same size regardless of how much data they contain (in some implementations), and Sally wanted it on bytes because that was a reasonable heuristic for identifying data segments, which interact better with TCP's mechanisms.

Having for 30+ years worked on equipment that was able to chain relatively small buffers to store a larger message, Van's argument has always seemed incomplete to me, and Sally's makes sense mechanistically. So I have generally come down on the side of bytes...

Yup. I'm aware of this debate. The doc addresses it head on.


But, whatever. On to your document...

I have dropped your entire document into my mail window. Text I don't have a problem with I will simply hack out, copying back text I have questions about. I assume that you can find it in the document by the markers I leave behind or by common search functions. I'm not going to say "[snip]"...

> 1.  Introduction

>    When notifying congestion, the problem of how (and whether) to take
                   ^...the participants in a session of the onset of...

OK


>    packet sizes into account has exercised the minds of researchers and
>    practitioners for as long as active queue management (AQM) has been
>    discussed.  Indeed, one reason AQM was originally introduced was to
>    reduce the lock-out effects that small packets can have on large
>    packets in drop-tail queues.

True, but I'll note that large packets can have a lock-out effect on small packets as well. RFCs 896 and 970, at least, worried about small packets not because there were so many of them, but because they implied the presence of additional IP and TCP headers and as a result relatively inefficient use of the line.

Yup. Just to check: you're not asking us to change anything in this para, just noting?
(A transport benefits from using the Nagle algo without the network additionally biasing drop probability towards small packets.)


>    The byte vs. packet dilemma arises at three stages in the congestion
>    notification process:
>
>    Measuring congestion:  When the congested resource decides locally to
>       measure how congested it is, should the queue measure its length
>       in bytes or packets?
>
>    Encoding congestion notification into the wire protocol:  When the
>       congested network resource decides whether to notify the level of
>       congestion by dropping or marking a particular packet, should its
>       decision depend on the byte-size of the particular packet being
>       dropped or marked?
>
>    Decoding congestion notification from the wire protocol:  When the
>       transport interprets the notification in order to decide how much
>       to respond to congestion, should it take into account the byte-
>       size of each missing or marked packet?
>
>    Consensus has emerged over the years concerning the first stage:
>    whether queues are measured in bytes or packets, termed byte-mode
>    queue measurement or packet-mode queue measurement.  This memo
>    records this consensus in the RFC Series.  In summary the choice
>    solely depends on whether the resource is congested by bytes or
>    packets.

If you're recording a consensus for posterity, I think it needs to be more clearly stated. Do you mean "the consensus is that both choices are viable; the implementor or operator should choose to measure whatever is congesting his links"? I personally don't hear a clear statement here about (1).

All the clear statements are in S.2 Recommendations. So we need to say:

"Section 2.1 of this memo records this consensus in the RFC Series."


>    The controversy is mainly around the last two stages: whether to
>    allow for the size of the specific packet notifying congestion i)
>    when the network encodes or ii) when the transport decodes the
>    congestion notification.
...
>    The primary purpose of this memo is to build a definitive consensus
>    against deliberate preferential treatment for small packets in AQM
>    algorithms and to record this advice within the RFC series.  It
>    recommends that (1) packet size should be taken into account when
>    transports read congestion indications, (2) not when network
>    equipment writes them.


I have read the rest of the paper, but let me stop here and make some generalizations.

First, I expected to find some data or pointers to data. There are in fact some pointers to other documents. The vast majority of the statements in the document that might be supported by data appear to say "80% of those we might have expected to respond didn't, but..." or something like that. I'd be a lot happier with statements of the form "we ran a test..." or "we were able to construct a proof that the mathematics tells us..."

The subsections of S.3 give all the motivating arguments.
* Some are in the form of a proof (S.3.1 on scaling).
* Some (S.3.2) are in form of layering arguments about where the more generic functions should be placed. Are we going to make AQM decisions depend on inspection of the structure of transport protocols like TCP, SCTP, DCCP, RTP etc etc. (assuming no IPsec)?
* Yes, some (e.g. S.3.3 on DoS) ought to reference empirical data to back them up. We need to add a ref here to tests of the performance for small packets of byte-mode drop (such results were not intended to show that small packet DoS works, but they do).
* Some are in the form of statements of a security vulnerability (S.3.4 small != control)

If performance were the issue, then I would agree that references to performance studies would be necessary. However, whether a future protocol design can be made to go slightly faster if the network does byte-mode drop, versus the end-system taking account of packet size is a moot question in the presence of larger arguments of scaling and security vulnerabilities.

This document isn't about which AQM design gives the best performance if we hold the TCP design static. It's about the constraints we are faced with for future protocol design beyond TCP.


Second, I disagree with the argument about a "perverse favoring of small packets". At least in implementations I'm familiar with, the policy isn't "drop only large packets"; it's "make the drop probability of a packet proportional to the ratio of its size to the bit rate of the link".

Yup.

If all packets are 9000 bytes and you're on an STM-4 link, the drop probability of a packet is proportional to (8*9000)/622000000. If all packets are 64 bytes, the drop probability of any given packet is proportional to (8*64)/622000000, which is smaller, but there are 9000/64 times as many to choose from. Any given bit on the wire has the same probability of being contained in a packet that got lost.

I believe there's a mistake here. To see why it's a mistake, I'll carry through the numerical example to the end (as in Appx A.2).
Assume the constant of proportionality in both your cases is 100, that is:
 Drop prob of large pkts is 100*(8*9000)/622000000 ~ 1.2%
 Drop prob of small pkts is 100*(8*64)/622000000   ~ 0.0082%

Let's compare the losses from a stream of 64,000 large pkts vs 9,000,000 small pkts
Each stream contains the same number of bytes (64,000*9,000 = 9,000,000*64 = 576MB) so it will last for the same time on the same link.

Number of large pkts dropped by byte-mode drop
 = 100*(8*9000)/622000000 * 64,000
 = 1.2% * 64,000
 = 741 large packets

Number of small pkts dropped by byte-mode drop
 = 100*(8*64)/622000000 * 9,000,000
 = 0.0082% * 9,000,000
 = 741 small packets

Number of Bytes dropped in large packets by byte-mode drop
 = 741*9,000B
 = 6.67MB
Number of Bytes dropped in small packets by byte-mode drop
 = 741*64B
 = 47.4kB

With byte-mode drop, any given bit on the wire does NOT have the same probability of being contained in a packet that got lost.

Yes, there are 9000/64 times as many small packets to choose from. Therefore in order to drop a bit with the same probability no matter what size packet it is in, each small packet should be dropped with the SAME probability as a large packet (packet-mode drop).

With the same probability per packet, the dice is thrown 9000/64 times more often for small packets, but if the outcome is a drop, the amount of bytes lost is only 64/9000 times as much. These two already cancel each other out. So there's no need to deflate the probability of dropping small packets further.

On the other hand, if packets are variable in size and you're keying off packet depth, a bit on the wire that is contained in a small packet has a much greater proportional probability of being tagged than one in a large packet.

I think your phrase "keying off packet depth" means measuring queue length in packets, rather than deciding the probability of dropping a particular packet based on its size. If so, I don't believe the second part of the sentence is correct.

When a small packet arrives at a queue of packets of different sizes, its /own/ size doesn't make any difference to the number of packets in the queue. That's why the draft separates out how you measure the queue length, from how you calculate the probability of tagging a particular packet.

I don't see that one is incented to send small packets; if the probability that a given bit gets lost is the same regardless of size, it seems to me that it takes size out of the discussion.

Exactly. I agree that the goal is for the probability of losing a bit to be independent of the size of packet it happens to be in.

But byte-mode drop fails that test (miserably). Packet-mode drop passes.


I'll go back and read the paper again a couple of times before commenting further.

Thanks again for your time on this.



Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design --=====================_518683036==.ALT-- From dreibh@iem.uni-due.de Wed Aug 3 02:10:53 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB11321F8B28 for ; Wed, 3 Aug 2011 02:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3np5sbbMCgZU for ; Wed, 3 Aug 2011 02:10:53 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id D509D21F8B24 for ; Wed, 3 Aug 2011 02:10:52 -0700 (PDT) Received: from kappes.localnet ([132.252.151.80]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id p73998vP032217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 3 Aug 2011 11:09:09 +0200 To: tsvwg@ietf.org Subject: Call for Papers: PAMS 2012 -- 2nd International Workshop on Protocols and Applications with Multi-Homing Support From: Thomas Dreibholz Organization: University of Duisburg-Essen, Institute for Experimental Mathematics Date: Wed, 3 Aug 2011 11:09:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201108031109.08451.dreibh@iem.uni-due.de> X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 09:10:54 -0000 (Our apologies if you receive multiple copies of this CfP) CALL FOR PAPERS 2nd International Workshop on Protocols and Applications with Multi-Homing= =20 Support (PAMS 2012) In conjunction with the 26th IEEE International Conference on Advanced=20 Information Networkingand Applications (AINA 2012) =46ukuoka, Japan, March 26-29, 2012 http://tdrwww.iem.uni-due.de/pams2012.html The intent of our workshop is to bring together people from research and industry, in order to provide a discussion forum for state-of-the-art topics related to multi-homing on Network, Transport, Session and Application Laye= rs. The PAMS workshop will include full-paper sessions as well as a poster sess= ion (with short presentations) to introduce preliminary ideas as well as work in progress. Workshops proceedings will be published by the IEEE CS Conference Publishing Service and will be included in the Digital Library. The main topics to be addressed include (but are not limited to): * Network Resilience by Multi-Homing * Network Architectures for Multi-Homed Systems * Performance Evaluation of Multi-Homed Systems * Deployment of Multi-Homed Protocols in Existing Networks with Middleboxes * Design and Implementation of Multi-Homed Systems * Load Sharing and Load Balancing for Multi-Homed Systems * Mobility for Multi-Homed Systems * Protocols with Multi-Homing Support * Congestion and Flow Control of Multi-Homed Systems * Quality of Service for Multi-Homed Systems * Security of Multi-Homed Systems * Application Deployment and Support for Legacy Applications * Cross-Layer Optimization for Multi-Homed Systems * Multi-Homing in the Context of Future Internet GENERAL CHAIRS: * Thomas Dreibholz, University of Duisburg-Essen, Germany * Martin Becke, University of Duisburg-Essen, Germany PROGRAM CHAIRS: * Michael T=FCxen, M=FCnster University of Applied Sciences, Germany * Erwin P. Rathgeb, University of Duisburg-Essen, Germany PROGRAM COMMITTEE * Hakim Adhari, University of Duisburg-Essen, Germany * Nicola Altan, Cetekom, Germany * Paul Amer, University of Delaware, U.S.A. * Holger Bleul, DB Systel, Germany * Anna Brunstr=F6m, Karlstad University, Sweden * Glenford Mapp, Middlesex University, United Kingdom * Michio Honda, Keio University, Japan * Seok J. Koh, Kyungpook National University, Korea * Preethi Natarajan, Cisco, U.S.A. * Brad Penoff, University of British Columbia, Canada * Irene R=FCngeler, M=FCnster University of Applied Sciences, Germany * Robin Seggelmann, M=FCnster University of Applied Sciences, Germany * Esbold Unurkhaan, Mongolian University of Science and Technology,=20 Mongolia * Alan Wagner, University of British Columbia, Canada * Michael Welzl, University of Oslo, Norway * Xing Zhou, Hainan University, China IMPORTANT DATES * Paper Submission Deadline: October 01, 2011 * Author Notification: December 01, 2011 * Camera-Ready Paper Submission: January 06, 2012 CONTACT =46or further information, please contact: * Thomas Dreibholz (dreibh AT iem.uni-due.de) * Martin Becke (martin.becke AT uni-due.de) WEBSITE http://tdrwww.iem.uni-due.de/pams2012.html From dwing@cisco.com Thu Aug 4 17:05:13 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43AA711E808D for ; Thu, 4 Aug 2011 17:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.704 X-Spam-Level: X-Spam-Status: No, score=-103.704 tagged_above=-999 required=5 tests=[AWL=-1.105, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5erqtPw1vGF for ; Thu, 4 Aug 2011 17:05:12 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4144511E807C for ; Thu, 4 Aug 2011 17:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2197; q=dns/txt; s=iport; t=1312502728; x=1313712328; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=dfkkhckJ77Eq51embRWftHYjhuVk2gomQulxHwoUclk=; b=aetiVyuMDRS1261s3LktY1J2aH0HTlZ2d4Wv4qTi0hanXVP+vGMLqSYA mgnR/7IrCPYw0rjs8LsXp26DJ/ExK/4ZOAn2vBe8DUiT6P0rdOaDS0hex M47AeUtv4BZdGTYPFhlilX4BLOYWMzYBp6uT8g0dM+h8Avq2ypMxwP72/ E=; X-IronPort-AV: E=Sophos;i="4.67,320,1309737600"; d="scan'208";a="9844990" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-7.cisco.com with ESMTP; 05 Aug 2011 00:05:27 +0000 Received: from dwingWS (sjc-vpn2-56.cisco.com [10.21.112.56]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p7505Otb029975; Fri, 5 Aug 2011 00:05:25 GMT From: "Dan Wing" To: , , , , , "'Peter Lei \(peterlei\)'" , Subject: Apparent SCTP API oversights, draft-ietf-tsvwg-sctpsocket-30 Date: Thu, 4 Aug 2011 17:05:22 -0700 Message-ID: <026301cc5303$611e3a40$235aaec0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxTA163JtV0CXp5SVyERmdtdK9aGg== Content-Language: en-us X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 00:05:13 -0000 I would like clarification on my misunderstanding, or changes to draft-ietf-tsvwg-sctpsocket, to accommodate what appear to be some oversights in the SCTP API: 1. The infotype parameter of sctp_sendv() allows indicating if the data should be sent with partial reliability or full reliability using sctp_prinfo. However, there does not appear to be a way to adjust the IPv4 or IPv6 DSCP bits when switching between full/partial reliablity, except by modifying the entire association itself (using spp_ipv4_tos). This is quite limiting. 2. When modifying an association (e.g., to have different DSCP value), I could not find text in draft-ietf-tsvwg-sctpsocket-30 that indicates if the modification applies immediately (including to packets queued and to packets not yet acknowledged by the receiver) or if the modification applies to subsequent calls to send(). This means that to attempt to work around (1), it isn't clear if the API would permit me to modify the association's DSCP value, call send(), and know that payload will be sent with the desired DSCP value. 3. Related to (1), it is desirable that full reliable packets not be bundled with partial reliability packets, so that they can have different DSCP markings. http://tools.ietf.org/html/rfc4960#section-10.1 mentions a no-bundle flag. However, I could not find in draft-ietf-tsvwg-sctpsocket-30 where this is controlled; it appears the API lacks this ability. 4. draft-ietf-tsvwg-sctpsocket-30 uses the archaic term ToS rather than DSCP. At a minimum, to ease string searching, please add text near spp_ipv4_tos something like "This is also called the DSCP field [RFC2474]". I would prefer, though, that draft-ietf-tsvwg-sctpsocket-30 use the term DSCP in compliance with RFC3260 and other DiffServ documents. 5. I believe it is an oversight that draft-ietf-tsvwg-sctpsocket-30 provides a way to adjust the IPv4 ToS (spp_ipv4_tos) and the IPv6 flow label (spp_ipv6_flowlabel), but lacks a way to query or adjust the IPv6 Traffic Class field. Please correct this oversight or add text justifying the inability to adjust the IPv6 Traffic Class field. -d From tuexen@fh-muenster.de Fri Aug 5 13:58:21 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37FD221F8754 for ; Fri, 5 Aug 2011 13:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFLRfidosdcz for ; Fri, 5 Aug 2011 13:58:20 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id EE4CE21F874E for ; Fri, 5 Aug 2011 13:58:19 -0700 (PDT) Received: from [192.168.1.193] (p508FA3C9.dip.t-dialin.net [80.143.163.201]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 893D21C0C0BD6; Fri, 5 Aug 2011 22:58:35 +0200 (CEST) Subject: Re: Apparent SCTP API oversights, draft-ietf-tsvwg-sctpsocket-30 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <026301cc5303$611e3a40$235aaec0$@com> Date: Fri, 5 Aug 2011 22:58:34 +0200 Content-Transfer-Encoding: 7bit Message-Id: <7A0DE9E5-DE21-49BB-B75E-8150A2068334@fh-muenster.de> References: <026301cc5303$611e3a40$235aaec0$@com> To: Dan Wing , ka-cheong.poon@oracle.com, "James M. Polk" X-Mailer: Apple Mail (2.1244.3) Cc: vladislav.yasevich@hp.com, "Peter Lei \(peterlei\)" , tsvwg@ietf.org, randall@lakerest.net, draft-ietf-tsvwg-sctpsocket@tools.ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 20:58:21 -0000 Hi Dan, thank you very much for your comments. See my answers in-line. Best regards Michael On Aug 5, 2011, at 2:05 AM, Dan Wing wrote: > I would like clarification on my misunderstanding, or changes > to draft-ietf-tsvwg-sctpsocket, to accommodate what appear to > be some oversights in the SCTP API: > > 1. The infotype parameter of sctp_sendv() allows indicating if the > data should be sent with partial reliability or full reliability > using sctp_prinfo. However, there does not appear to be a way to > adjust the IPv4 or IPv6 DSCP bits when switching between > full/partial reliablity, except by modifying the entire > association itself (using spp_ipv4_tos). This is quite limiting. A couple of points: * The DSCP stuff applies to packets, not to user messages. Any send() call applies to a user message. So this does not really fit. * The sendv() is a convenience function, so you can't do everything with it. The generic way is by using CMSGs. * The DCSP stuff is related to the IP layer, not the SCTP layer. * I'm also not sure if you can easily map PR-SCTP policies to DCSP code points. You might want to do that for particular usages of particular policies, but in general a mapping seems to be hard. * For IPv6 you can do that by using the IPV6_TCLASS CMSG. * For IPv4 there is no CMSG for specifying the TOS (as far as I know). But adding such a CMSG at the IPv4 layer would be the way to address this. > > > 2. When modifying an association (e.g., to have different DSCP > value), I could not find text in draft-ietf-tsvwg-sctpsocket-30 that > indicates if the modification applies immediately (including to > packets queued and to packets not yet acknowledged by the > receiver) or if the modification applies to subsequent calls > to send(). > > This means that to attempt to work around (1), it isn't clear > if the API would permit me to modify the association's DSCP > value, call send(), and know that payload will be sent with > the desired DSCP value. At least for the FreeBSD implementation this applies to all packets (transmitted or retransmitted) sent after the socket option has been set. The values do NOT stick to user messages. > > > 3. Related to (1), it is desirable that full reliable packets not > be bundled with partial reliability packets, so that they can have > different DSCP markings. ... which means the workaround doesn't really work... > > http://tools.ietf.org/html/rfc4960#section-10.1 mentions a no-bundle > flag. However, I could not find in draft-ietf-tsvwg-sctpsocket-30 > where this is controlled; it appears the API lacks this ability. The functionality is provide by the SCTP_NODELAY socket option. > > > 4. draft-ietf-tsvwg-sctpsocket-30 uses the archaic term ToS > rather than DSCP. At a minimum, to ease string searching, please > add text near spp_ipv4_tos something like "This is also called the > DSCP field [RFC2474]". I would prefer, though, that > draft-ietf-tsvwg-sctpsocket-30 use the term DSCP in compliance > with RFC3260 and other DiffServ documents. I'm happy to change this text. However, the document has passed the WG LC. Not sure how to handle this? WG chairs? We can either reissue he document with the small changes discussed in this mail or handle it as comments during the IESG review. Up to the chairs. > > > 5. I believe it is an oversight that draft-ietf-tsvwg-sctpsocket-30 > provides a way to adjust the IPv4 ToS (spp_ipv4_tos) and the IPv6 > flow label (spp_ipv6_flowlabel), but lacks a way to query or adjust > the IPv6 Traffic Class field. Please correct this oversight or > add text justifying the inability to adjust the IPv6 Traffic Class > field. Hmmm. You have a point here... It is hard to change he structure anymore since implementations are out... However, the spp_ipv6_flowlabel is 32-bit, enough space to contain the flowlabel and the DSCP. We could add text how to [sg]et the DSCP. Kacheong: Do you have some suggestions here? > > -d > > > From dwing@cisco.com Fri Aug 5 16:36:12 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39EDF21F8757 for ; Fri, 5 Aug 2011 16:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.671 X-Spam-Level: X-Spam-Status: No, score=-103.671 tagged_above=-999 required=5 tests=[AWL=-1.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tlw98bP+879k for ; Fri, 5 Aug 2011 16:36:11 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 22A0E21F8754 for ; Fri, 5 Aug 2011 16:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5794; q=dns/txt; s=iport; t=1312587390; x=1313796990; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=Zz77616vX75gVc4ojyCej9LSusk+9GTA1SYmcpDTesY=; b=VTekImc0Y/TsLBydnmgI9p3aJHvA2baVvtAXXwWgrPfwcknPFFgJtVXM qzD8lZ9IbuxcwjG8FyMFAvoz58Qk9O5TsubrQI6ac2QGD+jEpEU+2ADvL 8EBAX8n8Wi4naWGXXQD0DTVWw81NkFuu7sNDWuIC+ACK9+4nW5nJXRkQH s=; X-IronPort-AV: E=Sophos;i="4.67,326,1309737600"; d="scan'208";a="10282036" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-3.cisco.com with ESMTP; 05 Aug 2011 23:36:29 +0000 Received: from dwingWS (sjc-vpn6-1795.cisco.com [10.21.127.3]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p75NaQI2007458; Fri, 5 Aug 2011 23:36:27 GMT From: "Dan Wing" To: "'Michael Tuexen'" , , "'James M. Polk'" References: <026301cc5303$611e3a40$235aaec0$@com> <7A0DE9E5-DE21-49BB-B75E-8150A2068334@fh-muenster.de> In-Reply-To: <7A0DE9E5-DE21-49BB-B75E-8150A2068334@fh-muenster.de> Subject: RE: Apparent SCTP API oversights, draft-ietf-tsvwg-sctpsocket-30 Date: Fri, 5 Aug 2011 16:36:26 -0700 Message-ID: <028f01cc53c8$7f665800$7e330800$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxTsnWm/dEVTGBqTL2blI26RvMamQAE5ThA Content-Language: en-us Cc: vladislav.yasevich@hp.com, "'Peter Lei \(peterlei\)'" , tsvwg@ietf.org, randall@lakerest.net, draft-ietf-tsvwg-sctpsocket@tools.ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 23:36:12 -0000 > -----Original Message----- > From: Michael Tuexen [mailto:tuexen@fh-muenster.de] > Sent: Friday, August 05, 2011 1:59 PM > To: Dan Wing; ka-cheong.poon@oracle.com; James M. Polk > Cc: draft-ietf-tsvwg-sctpsocket@tools.ietf.org; tsvwg@ietf.org; > randall@lakerest.net; Peter Lei (peterlei); vladislav.yasevich@hp.com > Subject: Re: Apparent SCTP API oversights, draft-ietf-tsvwg-sctpsocket- > 30 > > Hi Dan, > > thank you very much for your comments. > See my answers in-line. > > Best regards > Michael > > On Aug 5, 2011, at 2:05 AM, Dan Wing wrote: > > > I would like clarification on my misunderstanding, or changes > > to draft-ietf-tsvwg-sctpsocket, to accommodate what appear to > > be some oversights in the SCTP API: > > > > 1. The infotype parameter of sctp_sendv() allows indicating if the > > data should be sent with partial reliability or full reliability > > using sctp_prinfo. However, there does not appear to be a way to > > adjust the IPv4 or IPv6 DSCP bits when switching between > > full/partial reliablity, except by modifying the entire > > association itself (using spp_ipv4_tos). This is quite limiting. > A couple of points: > * The DSCP stuff applies to packets, not to user messages. Any > send() call applies to a user message. So this does not really > fit. > * The sendv() is a convenience function, so you can't do everything > with it. The generic way is by using CMSGs. > * The DCSP stuff is related to the IP layer, not the SCTP layer. > * I'm also not sure if you can easily map PR-SCTP policies to > DCSP code points. You might want to do that for particular > usages of particular policies, but in general a mapping seems > to be hard. > * For IPv6 you can do that by using the IPV6_TCLASS CMSG. > * For IPv4 there is no CMSG for specifying the TOS (as far > as I know). But adding such a CMSG at the IPv4 layer would > be the way to address this. To me this seems necessary, or else SCTP's ability to carry multiple streams (of different application delivery precedence, e.g., partial reliability) cannot influence the network's drop precedence. Without this capability the only workable alternative, if someone wants the network to know the drop precedence for a packet, is to create two separate SCTP associations and carry the reliable stream in one association and the unreliable stream in the other association. Creating a separate connection with certain DSCP values is what we do with UDP and TCP today. This limitation seems the antithesis of SCTP's design which allows a single SCTP association to carry several streams where each stream can have different retransmit characteristics. > > 2. When modifying an association (e.g., to have different DSCP > > value), I could not find text in draft-ietf-tsvwg-sctpsocket-30 that > > indicates if the modification applies immediately (including to > > packets queued and to packets not yet acknowledged by the > > receiver) or if the modification applies to subsequent calls > > to send(). > > > > This means that to attempt to work around (1), it isn't clear > > if the API would permit me to modify the association's DSCP > > value, call send(), and know that payload will be sent with > > the desired DSCP value. > At least for the FreeBSD implementation this applies to all > packets (transmitted or retransmitted) sent after the socket option > has been set. The values do NOT stick to user messages. This seems significant, and means an application cannot work around the missing functionality in the API. Can this be added to the document? > > 3. Related to (1), it is desirable that full reliable packets not > > be bundled with partial reliability packets, so that they can have > > different DSCP markings. > ... which means the workaround doesn't really work... > > > > http://tools.ietf.org/html/rfc4960#section-10.1 mentions a no-bundle > > flag. However, I could not find in draft-ietf-tsvwg-sctpsocket-30 > > where this is controlled; it appears the API lacks this ability. > The functionality is provide by the SCTP_NODELAY socket option. Can the word "bundle" be added somewhere in the description of SCTP_NODELAY? Such consistency of terminology eases searching for things like this. > > 4. draft-ietf-tsvwg-sctpsocket-30 uses the archaic term ToS > > rather than DSCP. At a minimum, to ease string searching, please > > add text near spp_ipv4_tos something like "This is also called the > > DSCP field [RFC2474]". I would prefer, though, that > > draft-ietf-tsvwg-sctpsocket-30 use the term DSCP in compliance > > with RFC3260 and other DiffServ documents. > I'm happy to change this text. However, the document has passed > the WG LC. Not sure how to handle this? WG chairs? > We can either reissue he document with the small changes discussed > in this mail or handle it as comments during the IESG review. > Up to the chairs. > > > 5. I believe it is an oversight that draft-ietf-tsvwg-sctpsocket-30 > > provides a way to adjust the IPv4 ToS (spp_ipv4_tos) and the IPv6 > > flow label (spp_ipv6_flowlabel), but lacks a way to query or adjust > > the IPv6 Traffic Class field. Please correct this oversight or > > add text justifying the inability to adjust the IPv6 Traffic Class > > field. > Hmmm. You have a point here... > It is hard to change he structure anymore since implementations are > out... However, the spp_ipv6_flowlabel is 32-bit, enough space to > contain the flowlabel and the DSCP. We could add text how to [sg]et > the DSCP. That seems a reasonable solution which makes only a small change to existing code. -d > Kacheong: Do you have some suggestions here? > > > > -d > > > > > > From internet-drafts@ietf.org Sat Aug 6 06:02:27 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F4321F85B2; Sat, 6 Aug 2011 06:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.396 X-Spam-Level: X-Spam-Status: No, score=-102.396 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, SARE_SUB_6CONS_WORD=0.356, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gCkdM+WO79o; Sat, 6 Aug 2011 06:02:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC3921F8581; Sat, 6 Aug 2011 06:02:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-tsvwg-sctp-strrst-12.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110806130226.26043.62994.idtracker@ietfa.amsl.com> Date: Sat, 06 Aug 2011 06:02:26 -0700 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 13:02:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working = Group of the IETF. Title : Stream Control Transmission Protocol (SCTP) Stream Recon= figuration Author(s) : Randall R. Stewart Michael Tuexen Peter Lei Filename : draft-ietf-tsvwg-sctp-strrst-12.txt Pages : 33 Date : 2011-08-06 Many applications that use SCTP want the ability to "reset" a = stream. The intention of resetting a stream is to set the numbering sequence of the stream back to 'zero' with a corresponding notification t= o the upper layer that this has been performed. The applications that want this feature want it so that they can "re-use" streams for dif= ferent purposes but still utilize the stream sequence number so that the application can track the message flows. Thus, without this feature, a new use of an old stream would result in message numbers greater than expected unless there is a protocol mechanism to "reset the streams back to zero". This document also includes methods for resetting the transport sequence numbers, adding additional streams and resetting all stream sequence numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-strrst-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-strrst-12.txt From Michael.Tuexen@lurchi.franken.de Sat Aug 6 06:05:33 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7CB21F8867 for ; Sat, 6 Aug 2011 06:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Xnlet31tJWR for ; Sat, 6 Aug 2011 06:05:33 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE6521F8841 for ; Sat, 6 Aug 2011 06:05:32 -0700 (PDT) Received: from [192.168.1.195] (p508FA3C9.dip.t-dialin.net [80.143.163.201]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 1C5C81C0C0BCC for ; Sat, 6 Aug 2011 15:05:51 +0200 (CEST) Subject: Re: I-D Action: draft-ietf-tsvwg-sctp-strrst-10.txt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= X-Priority: 3 In-Reply-To: <193C0C0D-EA43-4C64-943A-600D0400525F@lakerest.net> Date: Sat, 6 Aug 2011 15:05:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <390F8D41-58B5-4926-A493-E273CC16D398@lurchi.franken.de> References: <20110626102951.11992.17163.idtracker@ietfa.amsl.com> <008e01cc3666$1b8d2220$4001a8c0@gateway.2wire.net> <193C0C0D-EA43-4C64-943A-600D0400525F@lakerest.net> To: tsvwg list X-Mailer: Apple Mail (2.1084) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 13:05:34 -0000 On Jul 29, 2011, at 2:27 PM, Randy Stewart wrote: > Tom: >=20 > Ok after sitting with Michael here, in the TSVWG meeting room, I see = what > happened here... you did not see my "else" clause or it was not clear = enough. > So to make it more clear I have changed the text to be as follows: >=20 > Otherwise process the Incoming SSN Reset Request Parameter = normally responding > to the peer with an acknowledgment. Note that this case includes the = situation where > some of the streams requested overlap with the jsut sent Outgoing SSN = Reset Request.=20 > Even in such a situation the Incoming SSN Reset MUST be processed = normally even > though this means that (if the endpoint elects to do the stream reset) = streams > that are already at SSN 0, will be reset a subsequent time. Dear all, as agreed on in the TSVWG session, no followup was received within a = week. So the authors consider the issue to be resolved in http://www.ietf.org/id/draft-ietf-tsvwg-sctp-strrst-12.txt Can we close the WG LC on this document? Best regards Michael >=20 >=20 >=20 > On Jun 29, 2011, at 10:08 AM, t.petch wrote: >=20 >> There are still some quirks of spelling, some old, some new, and I = think that >> the race >=20 >=20 > And as to the "quirks" of spelling.. could you please be more = specific.. or > as Scott would say... "send text"! >=20 > Thanks >=20 > R >=20 >> condition is still not wholy covered in 5.2.3. I am thinking of a = case where >> the >> Incoming SSN Reset Request Parameter specifies eg streams 2 and 3 = while the >> Outgoing >> SSN Reset Request Parameter specifies eg streams 1 and 2. >>=20 >> Tom Petch >>=20 >> ----- Original Message ----- >> From: "Michael T=FCxen" >> To: "Randy Stewart" >> Cc: "tsvwg list" >> Sent: Sunday, June 26, 2011 1:11 PM >> Subject: Re: I-D Action: draft-ietf-tsvwg-sctp-strrst-10.txt >>=20 >>=20 >> On Jun 26, 2011, at 12:55 PM, Randy Stewart wrote: >>=20 >>> This submission has all the previous comment .. not to many I = think.. >> These issues are not yet resolved, but on my ToDo list: >> * Address Geavins comments. >> * Add incoming streams request parameters. >>=20 >> These were the points brought up during LC, which I know hoe to = address. >> And the out-of-band vs. in-band discussion, which is still open. >>=20 >> Best regards >> Michael >>>=20 >>> It was about to expire so I thought it best to update (especially = since >>> my affiliation has changed ;-) >>>=20 >>> Still unresolved is the out-of-band vs in-band idea... again >>> I don't see how you do this totally inband.. >>>=20 >>> R >>> On Jun 26, 2011, at 6:29 AM, Internet-Drafts@ietf.org wrote: >>>=20 >>>> 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. >>>>=20 >>>> Title : Stream Control Transmission Protocol (SCTP) = Stream >> Reconfiguration >>>> Author(s) : Randall R. Stewart >>>> Peter Lei >>>> Michael Tuexen >>>> Filename : draft-ietf-tsvwg-sctp-strrst-10.txt >>>> Pages : 31 >>>> Date : 2011-06-26 >>>>=20 >>>> Many applications that use SCTP want the ability to = "reset" a >> stream. >>>> The intention of resetting a stream is to set the numbering = sequence >>>> of the stream back to 'zero' with a corresponding = notification to >> the >>>> upper layer that this has been performed. The applications that = want >>>> this feature want it so that they can "re-use" streams = for >> different >>>> purposes but still utilize the stream sequence number so that the >>>> application can track the message flows. Thus, without this = feature, >>>> a new use of an old stream would result in message numbers greater >>>> than expected unless there is a protocol mechanism to "reset = the >>>> streams back to zero". This document also includes methods = for >>>> resetting the transport sequence numbers, adding additional streams >>>> and resetting all stream sequence numbers. >>>>=20 >>>>=20 >>>> A URL for this Internet-Draft is: >>>> = http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-strrst-10.txt >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> This Internet-Draft can be retrieved at: >>>> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-strrst-10.txt >>>>=20 >>>=20 >>> ----- >>> Randall Stewart >>> randall@lakerest.net >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20 > ----- > Randall Stewart > randall@lakerest.net >=20 >=20 >=20 >=20 >=20 From tuexen@fh-muenster.de Sun Aug 7 07:50:06 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5A021F86BC for ; Sun, 7 Aug 2011 07:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.472 X-Spam-Level: X-Spam-Status: No, score=-0.472 tagged_above=-999 required=5 tests=[AWL=-1.861, BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Bk+mfgETBZk for ; Sun, 7 Aug 2011 07:50:06 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 43A0921F8661 for ; Sun, 7 Aug 2011 07:50:04 -0700 (PDT) Received: from [192.168.1.195] (p508F9E3B.dip.t-dialin.net [80.143.158.59]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id E33C51C0C0BEA; Sun, 7 Aug 2011 16:50:24 +0200 (CEST) Subject: Re: Apparent SCTP API oversights, draft-ietf-tsvwg-sctpsocket-30 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <028f01cc53c8$7f665800$7e330800$@com> Date: Sun, 7 Aug 2011 16:50:23 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <026301cc5303$611e3a40$235aaec0$@com> <7A0DE9E5-DE21-49BB-B75E-8150A2068334@fh-muenster.de> <028f01cc53c8$7f665800$7e330800$@com> To: Dan Wing X-Mailer: Apple Mail (2.1084) Cc: ka-cheong.poon@oracle.com, tsvwg@ietf.org, vladislav.yasevich@hp.com, draft-ietf-tsvwg-sctpsocket@tools.ietf.org, "'Peter Lei \(peterlei\)'" , randall@lakerest.net, "'James M. Polk'" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2011 14:50:06 -0000 On Aug 6, 2011, at 1:36 AM, Dan Wing wrote: >> -----Original Message----- >> From: Michael Tuexen [mailto:tuexen@fh-muenster.de] >> Sent: Friday, August 05, 2011 1:59 PM >> To: Dan Wing; ka-cheong.poon@oracle.com; James M. Polk >> Cc: draft-ietf-tsvwg-sctpsocket@tools.ietf.org; tsvwg@ietf.org; >> randall@lakerest.net; Peter Lei (peterlei); vladislav.yasevich@hp.com >> Subject: Re: Apparent SCTP API oversights, draft-ietf-tsvwg-sctpsocket- >> 30 >> >> Hi Dan, >> >> thank you very much for your comments. >> See my answers in-line. >> >> Best regards >> Michael >> >> On Aug 5, 2011, at 2:05 AM, Dan Wing wrote: >> >>> I would like clarification on my misunderstanding, or changes >>> to draft-ietf-tsvwg-sctpsocket, to accommodate what appear to >>> be some oversights in the SCTP API: >>> >>> 1. The infotype parameter of sctp_sendv() allows indicating if the >>> data should be sent with partial reliability or full reliability >>> using sctp_prinfo. However, there does not appear to be a way to >>> adjust the IPv4 or IPv6 DSCP bits when switching between >>> full/partial reliablity, except by modifying the entire >>> association itself (using spp_ipv4_tos). This is quite limiting. >> A couple of points: >> * The DSCP stuff applies to packets, not to user messages. Any >> send() call applies to a user message. So this does not really >> fit. >> * The sendv() is a convenience function, so you can't do everything >> with it. The generic way is by using CMSGs. >> * The DCSP stuff is related to the IP layer, not the SCTP layer. >> * I'm also not sure if you can easily map PR-SCTP policies to >> DCSP code points. You might want to do that for particular >> usages of particular policies, but in general a mapping seems >> to be hard. >> * For IPv6 you can do that by using the IPV6_TCLASS CMSG. >> * For IPv4 there is no CMSG for specifying the TOS (as far >> as I know). But adding such a CMSG at the IPv4 layer would >> be the way to address this. > > To me this seems necessary, or else SCTP's ability to carry > multiple streams (of different application delivery precedence, e.g., > partial reliability) cannot influence the network's drop precedence. If you want a per user message DSCP, that is required. However, we don't define any IPv[46] layer socket option or CMSG in the SCTP socket API ID. > Without this capability the only workable alternative, if someone > wants the network to know the drop precedence for a packet, is > to create two separate SCTP associations and carry the reliable stream > in one association and the unreliable stream in the other association. > Creating a separate connection with certain DSCP values is what we > do with UDP and TCP today. This limitation seems the antithesis of > SCTP's design which allows a single SCTP association to carry several > streams where each stream can have different retransmit characteristics. Hmm. Assuming you would send user messages with a limited lifetime of, let's say, 5 seconds. What DSCP would you use? For different PR-SCTP policies, this might be clearer. For example, FreeBSD allows to limit the number of retransmissions. For limiting it to 0, it might be clear, but what would be an appropriate DSCP with you allow, let's say, 3 retransmissions? Or do you have a different PR-SCTP policy in mind? In general I'm wondering how SCTP behaves if you use different DSCP within the same SCTP association. Not that it might break the association, but I'm not sure about interactions with the CC. > > >>> 2. When modifying an association (e.g., to have different DSCP >>> value), I could not find text in draft-ietf-tsvwg-sctpsocket-30 that >>> indicates if the modification applies immediately (including to >>> packets queued and to packets not yet acknowledged by the >>> receiver) or if the modification applies to subsequent calls >>> to send(). >>> >>> This means that to attempt to work around (1), it isn't clear >>> if the API would permit me to modify the association's DSCP >>> value, call send(), and know that payload will be sent with >>> the desired DSCP value. >> At least for the FreeBSD implementation this applies to all >> packets (transmitted or retransmitted) sent after the socket option >> has been set. The values do NOT stick to user messages. > > This seems significant, and means an application cannot work > around the missing functionality in the API. Can this be > added to the document? Up to the chairs... > > >>> 3. Related to (1), it is desirable that full reliable packets not >>> be bundled with partial reliability packets, so that they can have >>> different DSCP markings. >> ... which means the workaround doesn't really work... >>> >>> http://tools.ietf.org/html/rfc4960#section-10.1 mentions a no-bundle >>> flag. However, I could not find in draft-ietf-tsvwg-sctpsocket-30 >>> where this is controlled; it appears the API lacks this ability. >> The functionality is provide by the SCTP_NODELAY socket option. > > Can the word "bundle" be added somewhere in the description of > SCTP_NODELAY? Such consistency of terminology eases searching for > things like this. > > >>> 4. draft-ietf-tsvwg-sctpsocket-30 uses the archaic term ToS >>> rather than DSCP. At a minimum, to ease string searching, please >>> add text near spp_ipv4_tos something like "This is also called the >>> DSCP field [RFC2474]". I would prefer, though, that >>> draft-ietf-tsvwg-sctpsocket-30 use the term DSCP in compliance >>> with RFC3260 and other DiffServ documents. >> I'm happy to change this text. However, the document has passed >> the WG LC. Not sure how to handle this? WG chairs? >> We can either reissue he document with the small changes discussed >> in this mail or handle it as comments during the IESG review. >> Up to the chairs. >> >>> 5. I believe it is an oversight that draft-ietf-tsvwg-sctpsocket-30 >>> provides a way to adjust the IPv4 ToS (spp_ipv4_tos) and the IPv6 >>> flow label (spp_ipv6_flowlabel), but lacks a way to query or adjust >>> the IPv6 Traffic Class field. Please correct this oversight or >>> add text justifying the inability to adjust the IPv6 Traffic Class >>> field. >> Hmmm. You have a point here... >> It is hard to change he structure anymore since implementations are >> out... However, the spp_ipv6_flowlabel is 32-bit, enough space to >> contain the flowlabel and the DSCP. We could add text how to [sg]et >> the DSCP. > > That seems a reasonable solution which makes only a small change > to existing code. However, this does not solve your problem of being able to provide a per packet DSCP. You can do this with the IPV6_TCLASS cmsg for IPv6, but I'm not aware of something similar for IPv4. Maybe the reason is that for UDP you can do this my using a setsockopt() call before each send() call. I'm not sure if it makes sense for TCP to use multiple DSCPs per TCP connection. Best regards Michael > > -d > >> Kacheong: Do you have some suggestions here? >>> >>> -d >>> >>> >>> > > From randall@lakerest.net Mon Aug 8 04:30:13 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB2C21F8782 for ; Mon, 8 Aug 2011 04:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9c-RPPwZQ3CA for ; Mon, 8 Aug 2011 04:30:12 -0700 (PDT) Received: from lakerest.net (lakerest.net [70.155.160.98]) by ietfa.amsl.com (Postfix) with ESMTP id 6786A21F873D for ; Mon, 8 Aug 2011 04:30:12 -0700 (PDT) Received: from [10.1.1.49] (bsd3.lakerest.net [70.155.160.101]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id p78BRMIu015846 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 8 Aug 2011 07:27:22 -0400 (EDT) (envelope-from randall@lakerest.net) Subject: Re: Apparent SCTP API oversights, draft-ietf-tsvwg-sctpsocket-30 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Randy Stewart In-Reply-To: Date: Mon, 8 Aug 2011 07:27:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4D71CA28-A424-4524-91EB-E269509DEE64@lakerest.net> References: <026301cc5303$611e3a40$235aaec0$@com> <7A0DE9E5-DE21-49BB-B75E-8150A2068334@fh-muenster.de> <028f01cc53c8$7f665800$7e330800$@com> To: Michael Tuexen X-Mailer: Apple Mail (2.1084) Cc: ka-cheong.poon@oracle.com, tsvwg@ietf.org, vladislav.yasevich@hp.com, draft-ietf-tsvwg-sctpsocket@tools.ietf.org, "'Peter Lei \(peterlei\)'" , Dan Wing , "'James M. Polk'" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 11:30:13 -0000 Comments in-line... On Aug 7, 2011, at 10:50 AM, Michael Tuexen wrote: > On Aug 6, 2011, at 1:36 AM, Dan Wing wrote: >=20 >>> -----Original Message----- >>> From: Michael Tuexen [mailto:tuexen@fh-muenster.de] >>> Sent: Friday, August 05, 2011 1:59 PM >>> To: Dan Wing; ka-cheong.poon@oracle.com; James M. Polk >>> Cc: draft-ietf-tsvwg-sctpsocket@tools.ietf.org; tsvwg@ietf.org; >>> randall@lakerest.net; Peter Lei (peterlei); = vladislav.yasevich@hp.com >>> Subject: Re: Apparent SCTP API oversights, = draft-ietf-tsvwg-sctpsocket- >>> 30 >>>=20 >>> Hi Dan, >>>=20 >>> thank you very much for your comments. >>> See my answers in-line. >>>=20 >>> Best regards >>> Michael >>>=20 >>> On Aug 5, 2011, at 2:05 AM, Dan Wing wrote: >>>=20 >>>> I would like clarification on my misunderstanding, or changes >>>> to draft-ietf-tsvwg-sctpsocket, to accommodate what appear to >>>> be some oversights in the SCTP API: >>>>=20 >>>> 1. The infotype parameter of sctp_sendv() allows indicating if the >>>> data should be sent with partial reliability or full reliability >>>> using sctp_prinfo. However, there does not appear to be a way to >>>> adjust the IPv4 or IPv6 DSCP bits when switching between >>>> full/partial reliablity, except by modifying the entire >>>> association itself (using spp_ipv4_tos). This is quite limiting. >>> A couple of points: >>> * The DSCP stuff applies to packets, not to user messages. Any >>> send() call applies to a user message. So this does not really >>> fit. >>> * The sendv() is a convenience function, so you can't do everything >>> with it. The generic way is by using CMSGs. >>> * The DCSP stuff is related to the IP layer, not the SCTP layer. >>> * I'm also not sure if you can easily map PR-SCTP policies to >>> DCSP code points. You might want to do that for particular >>> usages of particular policies, but in general a mapping seems >>> to be hard. >>> * For IPv6 you can do that by using the IPV6_TCLASS CMSG. >>> * For IPv4 there is no CMSG for specifying the TOS (as far >>> as I know). But adding such a CMSG at the IPv4 layer would >>> be the way to address this. >>=20 >> To me this seems necessary, or else SCTP's ability to carry >> multiple streams (of different application delivery precedence, e.g., >> partial reliability) cannot influence the network's drop precedence. > If you want a per user message DSCP, that is required. However, > we don't define any IPv[46] layer socket option or CMSG in the > SCTP socket API ID. >> Without this capability the only workable alternative, if someone=20 >> wants the network to know the drop precedence for a packet, is=20 >> to create two separate SCTP associations and carry the reliable = stream=20 >> in one association and the unreliable stream in the other = association. >> Creating a separate connection with certain DSCP values is what we=20 >> do with UDP and TCP today. This limitation seems the antithesis of=20= >> SCTP's design which allows a single SCTP association to carry several=20= >> streams where each stream can have different retransmit = characteristics. > Hmm. Assuming you would send user messages with a limited lifetime of, > let's say, 5 seconds. What DSCP would you use? >=20 > For different PR-SCTP policies, this might be clearer. For example, > FreeBSD allows to limit the number of retransmissions. For limiting > it to 0, it might be clear, but what would be an appropriate DSCP > with you allow, let's say, 3 retransmissions? >=20 > Or do you have a different PR-SCTP policy in mind? >=20 > In general I'm wondering how SCTP behaves if you use different > DSCP within the same SCTP association. Not that it might break > the association, but I'm not sure about interactions with the > CC. There was a group when I worked at Cisco that wanted to do this, I don't remember the reasons, but I pointed out that: 1) Each flow packet using a different DSCP or flow-label will appear in the network as having a different path (who knows how much different they will be .. but they will be different) 2) Since they travel different "paths" in the network, they will have varying RTT times. 3) They will also arrive in completely different order. The result of this is: a) You will get false fast retransmits b) You MAY get unexpected HOL c) You will generate a lot more SACK's (since holes would be common which normally do not do delayed sack in=20 the case of a hole). So bottom line is its probably a bad idea.. better to setup separate = associations and just go ahead and route the traffic on the different associations = for the different priorities. I guess if you can live with the drawbacks, it would be ok. You could always do the sort of CMT like things that are done when CMT is on and keep a psuedo cumulative ack on each of your separate paths.. this would be a *LOT* of work.. but it could be done >>=20 >>=20 >>>> 2. When modifying an association (e.g., to have different DSCP >>>> value), I could not find text in draft-ietf-tsvwg-sctpsocket-30 = that >>>> indicates if the modification applies immediately (including to >>>> packets queued and to packets not yet acknowledged by the >>>> receiver) or if the modification applies to subsequent calls >>>> to send(). >>>>=20 >>>> This means that to attempt to work around (1), it isn't clear >>>> if the API would permit me to modify the association's DSCP >>>> value, call send(), and know that payload will be sent with >>>> the desired DSCP value. >>> At least for the FreeBSD implementation this applies to all >>> packets (transmitted or retransmitted) sent after the socket option >>> has been set. The values do NOT stick to user messages. >>=20 >> This seems significant, and means an application cannot work >> around the missing functionality in the API. Can this be=20 >> added to the document? > Up to the chairs... >>=20 >>=20 >>>> 3. Related to (1), it is desirable that full reliable packets not >>>> be bundled with partial reliability packets, so that they can have >>>> different DSCP markings. >>> ... which means the workaround doesn't really work... >>>>=20 >>>> http://tools.ietf.org/html/rfc4960#section-10.1 mentions a = no-bundle >>>> flag. However, I could not find in draft-ietf-tsvwg-sctpsocket-30 >>>> where this is controlled; it appears the API lacks this ability. >>> The functionality is provide by the SCTP_NODELAY socket option. >>=20 >> Can the word "bundle" be added somewhere in the description of >> SCTP_NODELAY? Such consistency of terminology eases searching for >> things like this. >>=20 >>=20 >>>> 4. draft-ietf-tsvwg-sctpsocket-30 uses the archaic term ToS >>>> rather than DSCP. At a minimum, to ease string searching, please >>>> add text near spp_ipv4_tos something like "This is also called the >>>> DSCP field [RFC2474]". I would prefer, though, that >>>> draft-ietf-tsvwg-sctpsocket-30 use the term DSCP in compliance >>>> with RFC3260 and other DiffServ documents. >>> I'm happy to change this text. However, the document has passed >>> the WG LC. Not sure how to handle this? WG chairs? >>> We can either reissue he document with the small changes discussed >>> in this mail or handle it as comments during the IESG review. >>> Up to the chairs. >>>=20 >>>> 5. I believe it is an oversight that draft-ietf-tsvwg-sctpsocket-30 >>>> provides a way to adjust the IPv4 ToS (spp_ipv4_tos) and the IPv6 >>>> flow label (spp_ipv6_flowlabel), but lacks a way to query or adjust >>>> the IPv6 Traffic Class field. Please correct this oversight or >>>> add text justifying the inability to adjust the IPv6 Traffic Class >>>> field. >>> Hmmm. You have a point here... >>> It is hard to change he structure anymore since implementations are >>> out... However, the spp_ipv6_flowlabel is 32-bit, enough space to >>> contain the flowlabel and the DSCP. We could add text how to [sg]et >>> the DSCP. >>=20 >> That seems a reasonable solution which makes only a small change >> to existing code. > However, this does not solve your problem of being able to provide a > per packet DSCP. You can do this with the IPV6_TCLASS cmsg for > IPv6, but I'm not aware of something similar for IPv4.=20 > Maybe the reason is that for UDP you can do this my using a = setsockopt() > call before each send() call. I'm not sure if it makes sense for TCP > to use multiple DSCPs per TCP connection. Which would have the same effects for it that I list above for SCTP.. only worse, since HOL would be set in all the time... SCTP would escape some of it depending on what streams were used and if unordered is thrown in the mix here too.. Also, thinking on this, how SCTP sends its FWD-TSN (what codepoint/path = is used) would become an interesting mixer to the items I listed above. R >=20 > Best regards > Michael >>=20 >> -d >>=20 >>> Kacheong: Do you have some suggestions here? >>>>=20 >>>> -d >>>>=20 >>>>=20 >>>>=20 >>=20 >>=20 >=20 ----- Randall Stewart randall@lakerest.net From qiaobing.xie@gmail.com Mon Aug 8 09:49:17 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 702DC21F8B40 for ; Mon, 8 Aug 2011 09:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.389 X-Spam-Level: X-Spam-Status: No, score=0.389 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRY4MiYjlmeZ for ; Mon, 8 Aug 2011 09:49:16 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1B321F8B3E for ; Mon, 8 Aug 2011 09:49:16 -0700 (PDT) Received: by iye1 with SMTP id 1so8975032iye.27 for ; Mon, 08 Aug 2011 09:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=EbkXLq5kG0VrNey+IPeYcgora1R4QmnLN8NgfRni0q4=; b=tqIM0hmE2GUJZ+KEtL9S2gzBzQs5KUszGi/CosqfArqQfuSMln9fj0gziTto3z10ko SyfPMpRAgYmpRinS1T+Bi9e8PfSbMOl+eMz4eOtC2Odjd4rREgFfg9WJuCFNBJJM/3JC NyjRq1vpxAFhypHWcHAyz/Chg8pGZ9kG3FW2M= Received: by 10.42.180.200 with SMTP id bv8mr5896943icb.21.1312822182590; Mon, 08 Aug 2011 09:49:42 -0700 (PDT) Received: from Qiaobing-Xies-Mac-Pro.local (97-91-147-26.dhcp.stls.mo.charter.com [97.91.147.26]) by mx.google.com with ESMTPS id v3sm4343449ibh.33.2011.08.08.09.49.34 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Aug 2011 09:49:39 -0700 (PDT) Message-ID: <4E40139C.4060300@gmail.com> Date: Mon, 08 Aug 2011 11:49:32 -0500 From: Qiaobing Xie User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Randy Stewart Subject: Re: Apparent SCTP API oversights, draft-ietf-tsvwg-sctpsocket-30 References: <026301cc5303$611e3a40$235aaec0$@com> <7A0DE9E5-DE21-49BB-B75E-8150A2068334@fh-muenster.de> <028f01cc53c8$7f665800$7e330800$@com> <4D71CA28-A424-4524-91EB-E269509DEE64@lakerest.net> In-Reply-To: <4D71CA28-A424-4524-91EB-E269509DEE64@lakerest.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ka-cheong.poon@oracle.com, tsvwg@ietf.org, vladislav.yasevich@hp.com, Michael Tuexen , draft-ietf-tsvwg-sctpsocket@tools.ietf.org, "'Peter Lei \(peterlei\)'" , Dan Wing , "'James M. Polk'" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 16:49:17 -0000 Dan, A different way to look at this is - the overall data delivery reliability between two SCTP endpoints has two control points; 1) selectively dropping packets along the path (ie, per-hop control), and 2) selectively retransmitting lost packets by the sending endpoint (ie, end-to-end control). As a transport layer protocol, SCTP naturally is designed to only do the latter. To ask SCTP to manage both would be architecturally awkward IMO. -Q On 8/8/11 6:27 AM, Randy Stewart wrote: > Comments in-line... > > On Aug 7, 2011, at 10:50 AM, Michael Tuexen wrote: > >> On Aug 6, 2011, at 1:36 AM, Dan Wing wrote: >> >>>> -----Original Message----- >>>> From: Michael Tuexen [mailto:tuexen@fh-muenster.de] >>>> Sent: Friday, August 05, 2011 1:59 PM >>>> To: Dan Wing; ka-cheong.poon@oracle.com; James M. Polk >>>> Cc: draft-ietf-tsvwg-sctpsocket@tools.ietf.org; tsvwg@ietf.org; >>>> randall@lakerest.net; Peter Lei (peterlei); vladislav.yasevich@hp.com >>>> Subject: Re: Apparent SCTP API oversights, draft-ietf-tsvwg-sctpsocket- >>>> 30 >>>> >>>> Hi Dan, >>>> >>>> thank you very much for your comments. >>>> See my answers in-line. >>>> >>>> Best regards >>>> Michael >>>> >>>> On Aug 5, 2011, at 2:05 AM, Dan Wing wrote: >>>> >>>>> I would like clarification on my misunderstanding, or changes >>>>> to draft-ietf-tsvwg-sctpsocket, to accommodate what appear to >>>>> be some oversights in the SCTP API: >>>>> >>>>> 1. The infotype parameter of sctp_sendv() allows indicating if the >>>>> data should be sent with partial reliability or full reliability >>>>> using sctp_prinfo. However, there does not appear to be a way to >>>>> adjust the IPv4 or IPv6 DSCP bits when switching between >>>>> full/partial reliablity, except by modifying the entire >>>>> association itself (using spp_ipv4_tos). This is quite limiting. >>>> A couple of points: >>>> * The DSCP stuff applies to packets, not to user messages. Any >>>> send() call applies to a user message. So this does not really >>>> fit. >>>> * The sendv() is a convenience function, so you can't do everything >>>> with it. The generic way is by using CMSGs. >>>> * The DCSP stuff is related to the IP layer, not the SCTP layer. >>>> * I'm also not sure if you can easily map PR-SCTP policies to >>>> DCSP code points. You might want to do that for particular >>>> usages of particular policies, but in general a mapping seems >>>> to be hard. >>>> * For IPv6 you can do that by using the IPV6_TCLASS CMSG. >>>> * For IPv4 there is no CMSG for specifying the TOS (as far >>>> as I know). But adding such a CMSG at the IPv4 layer would >>>> be the way to address this. >>> To me this seems necessary, or else SCTP's ability to carry >>> multiple streams (of different application delivery precedence, e.g., >>> partial reliability) cannot influence the network's drop precedence. >> If you want a per user message DSCP, that is required. However, >> we don't define any IPv[46] layer socket option or CMSG in the >> SCTP socket API ID. >>> Without this capability the only workable alternative, if someone >>> wants the network to know the drop precedence for a packet, is >>> to create two separate SCTP associations and carry the reliable stream >>> in one association and the unreliable stream in the other association. >>> Creating a separate connection with certain DSCP values is what we >>> do with UDP and TCP today. This limitation seems the antithesis of >>> SCTP's design which allows a single SCTP association to carry several >>> streams where each stream can have different retransmit characteristics. >> Hmm. Assuming you would send user messages with a limited lifetime of, >> let's say, 5 seconds. What DSCP would you use? >> >> For different PR-SCTP policies, this might be clearer. For example, >> FreeBSD allows to limit the number of retransmissions. For limiting >> it to 0, it might be clear, but what would be an appropriate DSCP >> with you allow, let's say, 3 retransmissions? >> >> Or do you have a different PR-SCTP policy in mind? >> >> In general I'm wondering how SCTP behaves if you use different >> DSCP within the same SCTP association. Not that it might break >> the association, but I'm not sure about interactions with the >> CC. > > There was a group when I worked at Cisco that wanted to do this, I don't > remember the reasons, but I pointed out that: > > 1) Each flow packet using a different DSCP or flow-label will appear > in the network as having a different path (who knows how much > different they will be .. but they will be different) > > 2) Since they travel different "paths" in the network, they will have > varying RTT times. > > 3) They will also arrive in completely different order. > > The result of this is: > > a) You will get false fast retransmits > b) You MAY get unexpected HOL > c) You will generate a lot more SACK's (since holes would > be common which normally do not do delayed sack in > the case of a hole). > > So bottom line is its probably a bad idea.. better to setup separate associations > and just go ahead and route the traffic on the different associations for > the different priorities. > > I guess if you can live with the drawbacks, it would be ok. You could > always do the sort of CMT like things that are done when CMT is on and > keep a psuedo cumulative ack on each of your separate paths.. this would > be a *LOT* of work.. but it could be done > > > >>> >>>>> 2. When modifying an association (e.g., to have different DSCP >>>>> value), I could not find text in draft-ietf-tsvwg-sctpsocket-30 that >>>>> indicates if the modification applies immediately (including to >>>>> packets queued and to packets not yet acknowledged by the >>>>> receiver) or if the modification applies to subsequent calls >>>>> to send(). >>>>> >>>>> This means that to attempt to work around (1), it isn't clear >>>>> if the API would permit me to modify the association's DSCP >>>>> value, call send(), and know that payload will be sent with >>>>> the desired DSCP value. >>>> At least for the FreeBSD implementation this applies to all >>>> packets (transmitted or retransmitted) sent after the socket option >>>> has been set. The values do NOT stick to user messages. >>> This seems significant, and means an application cannot work >>> around the missing functionality in the API. Can this be >>> added to the document? >> Up to the chairs... >>> >>>>> 3. Related to (1), it is desirable that full reliable packets not >>>>> be bundled with partial reliability packets, so that they can have >>>>> different DSCP markings. >>>> ... which means the workaround doesn't really work... >>>>> http://tools.ietf.org/html/rfc4960#section-10.1 mentions a no-bundle >>>>> flag. However, I could not find in draft-ietf-tsvwg-sctpsocket-30 >>>>> where this is controlled; it appears the API lacks this ability. >>>> The functionality is provide by the SCTP_NODELAY socket option. >>> Can the word "bundle" be added somewhere in the description of >>> SCTP_NODELAY? Such consistency of terminology eases searching for >>> things like this. >>> >>> >>>>> 4. draft-ietf-tsvwg-sctpsocket-30 uses the archaic term ToS >>>>> rather than DSCP. At a minimum, to ease string searching, please >>>>> add text near spp_ipv4_tos something like "This is also called the >>>>> DSCP field [RFC2474]". I would prefer, though, that >>>>> draft-ietf-tsvwg-sctpsocket-30 use the term DSCP in compliance >>>>> with RFC3260 and other DiffServ documents. >>>> I'm happy to change this text. However, the document has passed >>>> the WG LC. Not sure how to handle this? WG chairs? >>>> We can either reissue he document with the small changes discussed >>>> in this mail or handle it as comments during the IESG review. >>>> Up to the chairs. >>>> >>>>> 5. I believe it is an oversight that draft-ietf-tsvwg-sctpsocket-30 >>>>> provides a way to adjust the IPv4 ToS (spp_ipv4_tos) and the IPv6 >>>>> flow label (spp_ipv6_flowlabel), but lacks a way to query or adjust >>>>> the IPv6 Traffic Class field. Please correct this oversight or >>>>> add text justifying the inability to adjust the IPv6 Traffic Class >>>>> field. >>>> Hmmm. You have a point here... >>>> It is hard to change he structure anymore since implementations are >>>> out... However, the spp_ipv6_flowlabel is 32-bit, enough space to >>>> contain the flowlabel and the DSCP. We could add text how to [sg]et >>>> the DSCP. >>> That seems a reasonable solution which makes only a small change >>> to existing code. >> However, this does not solve your problem of being able to provide a >> per packet DSCP. You can do this with the IPV6_TCLASS cmsg for >> IPv6, but I'm not aware of something similar for IPv4. >> Maybe the reason is that for UDP you can do this my using a setsockopt() >> call before each send() call. I'm not sure if it makes sense for TCP >> to use multiple DSCPs per TCP connection. > > Which would have the same effects for it that I list above > for SCTP.. only worse, since HOL would be set in all the > time... SCTP would escape some of it depending on what streams > were used and if unordered is thrown in the mix here too.. > > Also, thinking on this, how SCTP sends its FWD-TSN (what codepoint/path is > used) would become an interesting mixer to the items I listed above. > > R > >> Best regards >> Michael >>> -d >>> >>>> Kacheong: Do you have some suggestions here? >>>>> -d >>>>> >>>>> >>>>> >>> > ----- > Randall Stewart > randall@lakerest.net > > > > > From dwing@cisco.com Mon Aug 8 11:21:24 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACDA821F8B5E for ; Mon, 8 Aug 2011 11:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.615 X-Spam-Level: X-Spam-Status: No, score=-101.615 tagged_above=-999 required=5 tests=[AWL=-3.004, BAYES_00=-2.599, FRT_STOCK2=3.988, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXrd6uY8QcRE for ; Mon, 8 Aug 2011 11:21:23 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8492A21F8B5C for ; Mon, 8 Aug 2011 11:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=8227; q=dns/txt; s=iport; t=1312827710; x=1314037310; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=TO9k1UZnGjN6Yn/flaCrnkjDw4LKuTgF+XIYgS4Wb4s=; b=SR5G1wsbxUD9PvIrTCYp1v3neJ568Kuwl80V0jdhGwvNTbOAzoTsQ6Gc Xg8UJ6OPz9p1rLd93VfBCAMaMlZsDwtytaS3Rpj0lr8TqYtOfg8wwnZG2 l8JVE2WgC2k4YdO6ft6AIDpjD9VOAm/OzCs+7TImhqJ3GBOy0/ySdz49u U=; X-IronPort-AV: E=Sophos;i="4.67,338,1309737600"; d="scan'208";a="10920351" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-3.cisco.com with ESMTP; 08 Aug 2011 18:21:49 +0000 Received: from dwingWS (sjc-vpn2-837.cisco.com [10.21.115.69]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p78ILmbe005588; Mon, 8 Aug 2011 18:21:48 GMT From: "Dan Wing" To: "'Michael Tuexen'" References: <026301cc5303$611e3a40$235aaec0$@com> <7A0DE9E5-DE21-49BB-B75E-8150A2068334@fh-muenster.de> <028f01cc53c8$7f665800$7e330800$@com> In-Reply-To: Subject: RE: Apparent SCTP API oversights, draft-ietf-tsvwg-sctpsocket-30 Date: Mon, 8 Aug 2011 11:21:48 -0700 Message-ID: <00a001cc55f8$09b810d0$1d283270$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxVEVqdZ0xKTikPRAKXz3Y9IkPabgA5iZjw Content-Language: en-us Cc: ka-cheong.poon@oracle.com, tsvwg@ietf.org, vladislav.yasevich@hp.com, draft-ietf-tsvwg-sctpsocket@tools.ietf.org, "'Peter Lei \(peterlei\)'" , randall@lakerest.net, "'James M. Polk'" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 18:21:24 -0000 > -----Original Message----- > From: Michael Tuexen [mailto:tuexen@fh-muenster.de] > Sent: Sunday, August 07, 2011 7:50 AM > To: Dan Wing > Cc: ka-cheong.poon@oracle.com; 'James M. Polk'; draft-ietf-tsvwg- > sctpsocket@tools.ietf.org; tsvwg@ietf.org; randall@lakerest.net; 'Peter > Lei (peterlei)'; vladislav.yasevich@hp.com > Subject: Re: Apparent SCTP API oversights, draft-ietf-tsvwg-sctpsocket- > 30 > > On Aug 6, 2011, at 1:36 AM, Dan Wing wrote: > > >> -----Original Message----- > >> From: Michael Tuexen [mailto:tuexen@fh-muenster.de] > >> Sent: Friday, August 05, 2011 1:59 PM > >> To: Dan Wing; ka-cheong.poon@oracle.com; James M. Polk > >> Cc: draft-ietf-tsvwg-sctpsocket@tools.ietf.org; tsvwg@ietf.org; > >> randall@lakerest.net; Peter Lei (peterlei); > vladislav.yasevich@hp.com > >> Subject: Re: Apparent SCTP API oversights, draft-ietf-tsvwg- > sctpsocket- > >> 30 > >> > >> Hi Dan, > >> > >> thank you very much for your comments. > >> See my answers in-line. > >> > >> Best regards > >> Michael > >> > >> On Aug 5, 2011, at 2:05 AM, Dan Wing wrote: > >> > >>> I would like clarification on my misunderstanding, or changes > >>> to draft-ietf-tsvwg-sctpsocket, to accommodate what appear to > >>> be some oversights in the SCTP API: > >>> > >>> 1. The infotype parameter of sctp_sendv() allows indicating if the > >>> data should be sent with partial reliability or full reliability > >>> using sctp_prinfo. However, there does not appear to be a way to > >>> adjust the IPv4 or IPv6 DSCP bits when switching between > >>> full/partial reliablity, except by modifying the entire > >>> association itself (using spp_ipv4_tos). This is quite limiting. > >> A couple of points: > >> * The DSCP stuff applies to packets, not to user messages. Any > >> send() call applies to a user message. So this does not really > >> fit. > >> * The sendv() is a convenience function, so you can't do everything > >> with it. The generic way is by using CMSGs. > >> * The DCSP stuff is related to the IP layer, not the SCTP layer. > >> * I'm also not sure if you can easily map PR-SCTP policies to > >> DCSP code points. You might want to do that for particular > >> usages of particular policies, but in general a mapping seems > >> to be hard. > >> * For IPv6 you can do that by using the IPV6_TCLASS CMSG. > >> * For IPv4 there is no CMSG for specifying the TOS (as far > >> as I know). But adding such a CMSG at the IPv4 layer would > >> be the way to address this. > > > > To me this seems necessary, or else SCTP's ability to carry > > multiple streams (of different application delivery precedence, e.g., > > partial reliability) cannot influence the network's drop precedence. > If you want a per user message DSCP, that is required. However, > we don't define any IPv[46] layer socket option or CMSG in the > SCTP socket API ID. > > Without this capability the only workable alternative, if someone > > wants the network to know the drop precedence for a packet, is > > to create two separate SCTP associations and carry the reliable > stream > > in one association and the unreliable stream in the other > association. > > Creating a separate connection with certain DSCP values is what we > > do with UDP and TCP today. This limitation seems the antithesis of > > SCTP's design which allows a single SCTP association to carry several > > streams where each stream can have different retransmit > > characteristics. > Hmm. Assuming you would send user messages with a limited lifetime of, > let's say, 5 seconds. What DSCP would you use? The value depends on that network's configuration. RFC4594 provides some guidance on different values. > For different PR-SCTP policies, this might be clearer. For example, > FreeBSD allows to limit the number of retransmissions. For limiting > it to 0, it might be clear, but what would be an appropriate DSCP > with you allow, let's say, 3 retransmissions? > > Or do you have a different PR-SCTP policy in mind? > > In general I'm wondering how SCTP behaves if you use different > DSCP within the same SCTP association. Not that it might break > the association, but I'm not sure about interactions with the > CC. > > > > > >>> 2. When modifying an association (e.g., to have different DSCP > >>> value), I could not find text in draft-ietf-tsvwg-sctpsocket-30 > that > >>> indicates if the modification applies immediately (including to > >>> packets queued and to packets not yet acknowledged by the > >>> receiver) or if the modification applies to subsequent calls > >>> to send(). > >>> > >>> This means that to attempt to work around (1), it isn't clear > >>> if the API would permit me to modify the association's DSCP > >>> value, call send(), and know that payload will be sent with > >>> the desired DSCP value. > >> At least for the FreeBSD implementation this applies to all > >> packets (transmitted or retransmitted) sent after the socket option > >> has been set. The values do NOT stick to user messages. > > > > This seems significant, and means an application cannot work > > around the missing functionality in the API. Can this be > > added to the document? > Up to the chairs... ? As in, this vagueness in the API is acceptable to you? > >>> 3. Related to (1), it is desirable that full reliable packets not > >>> be bundled with partial reliability packets, so that they can have > >>> different DSCP markings. > >> ... which means the workaround doesn't really work... > >>> > >>> http://tools.ietf.org/html/rfc4960#section-10.1 mentions a no- > bundle > >>> flag. However, I could not find in draft-ietf-tsvwg-sctpsocket-30 > >>> where this is controlled; it appears the API lacks this ability. > >> The functionality is provide by the SCTP_NODELAY socket option. > > > > Can the word "bundle" be added somewhere in the description of > > SCTP_NODELAY? Such consistency of terminology eases searching for > > things like this. > > > > > >>> 4. draft-ietf-tsvwg-sctpsocket-30 uses the archaic term ToS > >>> rather than DSCP. At a minimum, to ease string searching, please > >>> add text near spp_ipv4_tos something like "This is also called the > >>> DSCP field [RFC2474]". I would prefer, though, that > >>> draft-ietf-tsvwg-sctpsocket-30 use the term DSCP in compliance > >>> with RFC3260 and other DiffServ documents. > >> I'm happy to change this text. However, the document has passed > >> the WG LC. Not sure how to handle this? WG chairs? > >> We can either reissue he document with the small changes discussed > >> in this mail or handle it as comments during the IESG review. > >> Up to the chairs. > >> > >>> 5. I believe it is an oversight that draft-ietf-tsvwg-sctpsocket-30 > >>> provides a way to adjust the IPv4 ToS (spp_ipv4_tos) and the IPv6 > >>> flow label (spp_ipv6_flowlabel), but lacks a way to query or adjust > >>> the IPv6 Traffic Class field. Please correct this oversight or > >>> add text justifying the inability to adjust the IPv6 Traffic Class > >>> field. > >> Hmmm. You have a point here... > >> It is hard to change he structure anymore since implementations are > >> out... However, the spp_ipv6_flowlabel is 32-bit, enough space to > >> contain the flowlabel and the DSCP. We could add text how to [sg]et > >> the DSCP. > > > > That seems a reasonable solution which makes only a small change > > to existing code. > However, this does not solve your problem of being able to provide a > per packet DSCP. Agreed. But at least it brings IPv6 on par with IPv4. > You can do this with the IPV6_TCLASS cmsg for > IPv6, but I'm not aware of something similar for IPv4. > Maybe the reason is that for UDP you can do this my using a > setsockopt() > call before each send() call. I'm not sure if it makes sense for TCP > to use multiple DSCPs per TCP connection. I agree it makes little sense for TCP to change DSCP values of a flow. But SCTP isn't TCP, of course. -d > Best regards > Michael > > > > -d > > > >> Kacheong: Do you have some suggestions here? > >>> > >>> -d > >>> > >>> > >>> > > > > From tuexen@fh-muenster.de Tue Aug 9 02:31:53 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158F121F8B21 for ; Tue, 9 Aug 2011 02:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.606 X-Spam-Level: X-Spam-Status: No, score=-0.606 tagged_above=-999 required=5 tests=[AWL=-1.994, BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2O9SxEliS72 for ; Tue, 9 Aug 2011 02:31:42 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 881E821F89C1 for ; Tue, 9 Aug 2011 02:31:40 -0700 (PDT) Received: from [10.0.1.104] (unknown [212.201.121.94]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 726551C0C0BD6; Tue, 9 Aug 2011 11:32:06 +0200 (CEST) Subject: Re: Apparent SCTP API oversights, draft-ietf-tsvwg-sctpsocket-30 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <00a001cc55f8$09b810d0$1d283270$@com> Date: Tue, 9 Aug 2011 11:32:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <28C32C10-212C-4629-9296-D3D4D75BD649@fh-muenster.de> References: <026301cc5303$611e3a40$235aaec0$@com> <7A0DE9E5-DE21-49BB-B75E-8150A2068334@fh-muenster.de> <028f01cc53c8$7f665800$7e330800$@com> <00a001cc55f8$09b810d0$1d283270$@com> To: Dan Wing X-Mailer: Apple Mail (2.1084) Cc: ka-cheong.poon@oracle.com, tsvwg@ietf.org, vladislav.yasevich@hp.com, draft-ietf-tsvwg-sctpsocket@tools.ietf.org, "'Peter Lei \(peterlei\)'" , randall@lakerest.net, "'James M. Polk'" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 09:31:53 -0000 On Aug 8, 2011, at 8:21 PM, Dan Wing wrote: >> -----Original Message----- >> From: Michael Tuexen [mailto:tuexen@fh-muenster.de] >> Sent: Sunday, August 07, 2011 7:50 AM >> To: Dan Wing >> Cc: ka-cheong.poon@oracle.com; 'James M. Polk'; draft-ietf-tsvwg- >> sctpsocket@tools.ietf.org; tsvwg@ietf.org; randall@lakerest.net; = 'Peter >> Lei (peterlei)'; vladislav.yasevich@hp.com >> Subject: Re: Apparent SCTP API oversights, = draft-ietf-tsvwg-sctpsocket- >> 30 >>=20 >> On Aug 6, 2011, at 1:36 AM, Dan Wing wrote: >>=20 >>>> -----Original Message----- >>>> From: Michael Tuexen [mailto:tuexen@fh-muenster.de] >>>> Sent: Friday, August 05, 2011 1:59 PM >>>> To: Dan Wing; ka-cheong.poon@oracle.com; James M. Polk >>>> Cc: draft-ietf-tsvwg-sctpsocket@tools.ietf.org; tsvwg@ietf.org; >>>> randall@lakerest.net; Peter Lei (peterlei); >> vladislav.yasevich@hp.com >>>> Subject: Re: Apparent SCTP API oversights, draft-ietf-tsvwg- >> sctpsocket- >>>> 30 >>>>=20 >>>> Hi Dan, >>>>=20 >>>> thank you very much for your comments. >>>> See my answers in-line. >>>>=20 >>>> Best regards >>>> Michael >>>>=20 >>>> On Aug 5, 2011, at 2:05 AM, Dan Wing wrote: >>>>=20 >>>>> I would like clarification on my misunderstanding, or changes >>>>> to draft-ietf-tsvwg-sctpsocket, to accommodate what appear to >>>>> be some oversights in the SCTP API: >>>>>=20 >>>>> 1. The infotype parameter of sctp_sendv() allows indicating if the >>>>> data should be sent with partial reliability or full reliability >>>>> using sctp_prinfo. However, there does not appear to be a way to >>>>> adjust the IPv4 or IPv6 DSCP bits when switching between >>>>> full/partial reliablity, except by modifying the entire >>>>> association itself (using spp_ipv4_tos). This is quite limiting. >>>> A couple of points: >>>> * The DSCP stuff applies to packets, not to user messages. Any >>>> send() call applies to a user message. So this does not really >>>> fit. >>>> * The sendv() is a convenience function, so you can't do everything >>>> with it. The generic way is by using CMSGs. >>>> * The DCSP stuff is related to the IP layer, not the SCTP layer. >>>> * I'm also not sure if you can easily map PR-SCTP policies to >>>> DCSP code points. You might want to do that for particular >>>> usages of particular policies, but in general a mapping seems >>>> to be hard. >>>> * For IPv6 you can do that by using the IPV6_TCLASS CMSG. >>>> * For IPv4 there is no CMSG for specifying the TOS (as far >>>> as I know). But adding such a CMSG at the IPv4 layer would >>>> be the way to address this. >>>=20 >>> To me this seems necessary, or else SCTP's ability to carry >>> multiple streams (of different application delivery precedence, = e.g., >>> partial reliability) cannot influence the network's drop precedence. >> If you want a per user message DSCP, that is required. However, >> we don't define any IPv[46] layer socket option or CMSG in the >> SCTP socket API ID. >>> Without this capability the only workable alternative, if someone >>> wants the network to know the drop precedence for a packet, is >>> to create two separate SCTP associations and carry the reliable >> stream >>> in one association and the unreliable stream in the other >> association. >>> Creating a separate connection with certain DSCP values is what we >>> do with UDP and TCP today. This limitation seems the antithesis of >>> SCTP's design which allows a single SCTP association to carry = several >>> streams where each stream can have different retransmit >>> characteristics. >> Hmm. Assuming you would send user messages with a limited lifetime = of, >> let's say, 5 seconds. What DSCP would you use? >=20 > The value depends on that network's configuration. RFC4594 provides > some guidance on different values. Hmmm. I could not find enough guidance to choose the right value if the timeout is 5 seconds compared to 1 second compared to 10 seconds. But as I said and Randy wrote in more detail. I'm not sure if it is wise to use multiple DSCP per path. So fixing the sctp_paddrparams is helpful and within the scope of the document. I'll prepare a proposed change of text. If you want per user message behavior you need an IP level cmsg which is not within the scope of this document. >=20 >> For different PR-SCTP policies, this might be clearer. For example, >> FreeBSD allows to limit the number of retransmissions. For limiting >> it to 0, it might be clear, but what would be an appropriate DSCP >> with you allow, let's say, 3 retransmissions? >>=20 >> Or do you have a different PR-SCTP policy in mind? >>=20 >> In general I'm wondering how SCTP behaves if you use different >> DSCP within the same SCTP association. Not that it might break >> the association, but I'm not sure about interactions with the >> CC. >>>=20 >>>=20 >>>>> 2. When modifying an association (e.g., to have different DSCP >>>>> value), I could not find text in draft-ietf-tsvwg-sctpsocket-30 >> that >>>>> indicates if the modification applies immediately (including to >>>>> packets queued and to packets not yet acknowledged by the >>>>> receiver) or if the modification applies to subsequent calls >>>>> to send(). >>>>>=20 >>>>> This means that to attempt to work around (1), it isn't clear >>>>> if the API would permit me to modify the association's DSCP >>>>> value, call send(), and know that payload will be sent with >>>>> the desired DSCP value. >>>> At least for the FreeBSD implementation this applies to all >>>> packets (transmitted or retransmitted) sent after the socket option >>>> has been set. The values do NOT stick to user messages. >>>=20 >>> This seems significant, and means an application cannot work >>> around the missing functionality in the API. Can this be >>> added to the document? >> Up to the chairs... >=20 > ? As in, this vagueness in the API is acceptable to you? I'll send out a proposed text change later. But the document is *after* = WG LC. So we have two choices: 1. After agreeing that the suggested text resolves your issues, resubmit the ID. Progress the new version to the IESG. 2. Handle your comments as comments received within the IESG review. I have done both (with different documents) depending on what the WG = chairs prefer. >=20 >>>>> 3. Related to (1), it is desirable that full reliable packets not >>>>> be bundled with partial reliability packets, so that they can have >>>>> different DSCP markings. >>>> ... which means the workaround doesn't really work... >>>>>=20 >>>>> http://tools.ietf.org/html/rfc4960#section-10.1 mentions a no- >> bundle >>>>> flag. However, I could not find in draft-ietf-tsvwg-sctpsocket-30 >>>>> where this is controlled; it appears the API lacks this ability. >>>> The functionality is provide by the SCTP_NODELAY socket option. >>>=20 >>> Can the word "bundle" be added somewhere in the description of >>> SCTP_NODELAY? Such consistency of terminology eases searching for >>> things like this. >>>=20 >>>=20 >>>>> 4. draft-ietf-tsvwg-sctpsocket-30 uses the archaic term ToS >>>>> rather than DSCP. At a minimum, to ease string searching, please >>>>> add text near spp_ipv4_tos something like "This is also called the >>>>> DSCP field [RFC2474]". I would prefer, though, that >>>>> draft-ietf-tsvwg-sctpsocket-30 use the term DSCP in compliance >>>>> with RFC3260 and other DiffServ documents. >>>> I'm happy to change this text. However, the document has passed >>>> the WG LC. Not sure how to handle this? WG chairs? >>>> We can either reissue he document with the small changes discussed >>>> in this mail or handle it as comments during the IESG review. >>>> Up to the chairs. >>>>=20 >>>>> 5. I believe it is an oversight that = draft-ietf-tsvwg-sctpsocket-30 >>>>> provides a way to adjust the IPv4 ToS (spp_ipv4_tos) and the IPv6 >>>>> flow label (spp_ipv6_flowlabel), but lacks a way to query or = adjust >>>>> the IPv6 Traffic Class field. Please correct this oversight or >>>>> add text justifying the inability to adjust the IPv6 Traffic Class >>>>> field. >>>> Hmmm. You have a point here... >>>> It is hard to change he structure anymore since implementations are >>>> out... However, the spp_ipv6_flowlabel is 32-bit, enough space to >>>> contain the flowlabel and the DSCP. We could add text how to [sg]et >>>> the DSCP. >>>=20 >>> That seems a reasonable solution which makes only a small change >>> to existing code. >> However, this does not solve your problem of being able to provide a >> per packet DSCP. >=20 > Agreed. But at least it brings IPv6 on par with IPv4. Yes. >=20 >> You can do this with the IPV6_TCLASS cmsg for >> IPv6, but I'm not aware of something similar for IPv4. >> Maybe the reason is that for UDP you can do this my using a >> setsockopt() >> call before each send() call. I'm not sure if it makes sense for TCP >> to use multiple DSCPs per TCP connection. >=20 > I agree it makes little sense for TCP to change DSCP values of > a flow. But SCTP isn't TCP, of course. >=20 > -d >=20 >=20 >> Best regards >> Michael >>>=20 >>> -d >>>=20 >>>> Kacheong: Do you have some suggestions here? >>>>>=20 >>>>> -d >>>>>=20 >>>>>=20 >>>>>=20 >>>=20 >>>=20 >=20 >=20 From tuexen@fh-muenster.de Tue Aug 9 14:06:44 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A0421F8B81 for ; Tue, 9 Aug 2011 14:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXk7AtIBXR-p for ; Tue, 9 Aug 2011 14:06:43 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC0021F8B7C for ; Tue, 9 Aug 2011 14:06:42 -0700 (PDT) Received: from [192.168.1.195] (p508FCB5B.dip.t-dialin.net [80.143.203.91]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 5266D1C0C0BE9; Tue, 9 Aug 2011 23:07:10 +0200 (CEST) Subject: Re: Apparent SCTP API oversights, draft-ietf-tsvwg-sctpsocket-30 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <026301cc5303$611e3a40$235aaec0$@com> Date: Tue, 9 Aug 2011 23:07:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <026301cc5303$611e3a40$235aaec0$@com> To: Dan Wing X-Mailer: Apple Mail (2.1084) Cc: ka-cheong.poon@oracle.com, tsvwg@ietf.org, vladislav.yasevich@hp.com, draft-ietf-tsvwg-sctpsocket@tools.ietf.org, "'Peter Lei \(peterlei\)'" , randall@lakerest.net X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 21:06:44 -0000 Hi Dan, based on the discussion, I suggest the following text changes: On Aug 5, 2011, at 2:05 AM, Dan Wing wrote: > I would like clarification on my misunderstanding, or changes > to draft-ietf-tsvwg-sctpsocket, to accommodate what appear to > be some oversights in the SCTP API: >=20 > 1. The infotype parameter of sctp_sendv() allows indicating if the=20 > data should be sent with partial reliability or full reliability > using sctp_prinfo. However, there does not appear to be a way to=20 > adjust the IPv4 or IPv6 DSCP bits when switching between=20 > full/partial reliablity, except by modifying the entire > association itself (using spp_ipv4_tos). This is quite limiting. No changes. >=20 >=20 > 2. When modifying an association (e.g., to have different DSCP > value), I could not find text in draft-ietf-tsvwg-sctpsocket-30 that > indicates if the modification applies immediately (including to=20 > packets queued and to packets not yet acknowledged by the=20 > receiver) or if the modification applies to subsequent calls > to send(). >=20 > This means that to attempt to work around (1), it isn't clear > if the API would permit me to modify the association's DSCP > value, call send(), and know that payload will be sent with > the desired DSCP value. I added at the end of section 8.1.12: Please note that changing the flowlabel or DSCP value will affect all packets sent by the SCTP stack after setting these parameters. The flowlabel might also be set via the sin6_flowinfo field of the struct socketaddr_in6 structure. >=20 >=20 > 3. Related to (1), it is desirable that full reliable packets not > be bundled with partial reliability packets, so that they can have > different DSCP markings. =20 >=20 > http://tools.ietf.org/html/rfc4960#section-10.1 mentions a no-bundle > flag. However, I could not find in draft-ietf-tsvwg-sctpsocket-30=20 > where this is controlled; it appears the API lacks this ability. I added to section 8.1.5: In particular, not using any Nagle-like algorithm might reduce the bundling of small user messages in cases where this would require an additional delay. >=20 >=20 > 4. draft-ietf-tsvwg-sctpsocket-30 uses the archaic term ToS > rather than DSCP. At a minimum, to ease string searching, please=20 > add text near spp_ipv4_tos something like "This is also called the > DSCP field [RFC2474]". I would prefer, though, that=20 > draft-ietf-tsvwg-sctpsocket-30 use the term DSCP in compliance=20 > with RFC3260 and other DiffServ documents. >=20 >=20 > 5. I believe it is an oversight that draft-ietf-tsvwg-sctpsocket-30=20 > provides a way to adjust the IPv4 ToS (spp_ipv4_tos) and the IPv6 > flow label (spp_ipv6_flowlabel), but lacks a way to query or adjust > the IPv6 Traffic Class field. Please correct this oversight or > add text justifying the inability to adjust the IPv6 Traffic Class > field. The stuff now reads: struct sctp_paddrparams { sctp_assoc_t spp_assoc_id; struct sockaddr_storage spp_address; uint32_t spp_hbinterval; uint16_t spp_pathmaxrxt; uint32_t spp_pathmtu; uint32_t spp_flags; uint32_t spp_ipv6_flowlabel; uint8_t spp_dscp; }; This field is used in conjunction with the SPP_IPV6_FLOWLABEL flag and contains the IPv6 flowlabel. The 20 least significant bits are used for the flowlabel. This setting has precedence over any IPv6 layer setting. This field is used in conjunction with the SPP_DSCP flag and contains the Differentiated Services Code Point (DSCP). The 6 least significant bits are used for the DSCP. This setting has precedence over any IPv4 or IPv6 layer setting. ... Setting this flag enables the setting of the IPV6 flowlabel value. The value is contained in the spp_ipv6_flowlabel field. Upon retrieval, this flag will be set to indicate that the = spp_ipv6_flowlabel field has a valid value returned. If a specific destination address is set (in the spp_address field), then the value returned is that of the address. If just an association is specified (and no address), = then the association's default flowlabel is returned. If neither an = association nor a destination is specified, then the socket's default flowlabel is = returned. For non IPv6 sockets, this flag will be left cleared. Setting this flag enables the setting of the DSCP value associated with either the association or a specific address. The value is obtained in the spp_dscp field. Upon retrieval, this flag will be set to indicate that the spp_dscp = field has a valid value returned. If a specific destination address is set = when called (in the spp_address field) then that specific destination = address' DSCP value is returned. If just an association is specified then the association default DSCP is returned. If neither an association nor = a destination is specified, then the sockets default DSCP is returned. Does this address your issues? Best regards Michael >=20 > -d >=20 >=20 >=20 From dwing@cisco.com Tue Aug 9 15:35:03 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADF821F8C35 for ; Tue, 9 Aug 2011 15:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.503 X-Spam-Level: X-Spam-Status: No, score=-103.503 tagged_above=-999 required=5 tests=[AWL=-0.904, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYHhoiAVzFwi for ; Tue, 9 Aug 2011 15:35:02 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 12FCE21F8C3A for ; Tue, 9 Aug 2011 15:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=6704; q=dns/txt; s=iport; t=1312929332; x=1314138932; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=eHgp3xfTuFaCNrCKwEnM/Xw28HqMwxB7A/r3OyfLWn0=; b=N/+9WMBljutq59xayiXdVqj8guLOSPQuwn8X9Sx3V+xgi0bHgs/Yo2Uv RluI/O7XSdhtHD6chtzivy0lnWceHkjOmIosUKj/0/EJYzqN8E3xhaO3O QS5TT3lwr9EaaCgVNtzfvGLGrEv9A+QuC8Kn+cfkO9VVt3bsOgsVJwTZb I=; X-IronPort-AV: E=Sophos;i="4.67,345,1309737600"; d="scan'208";a="11514674" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-4.cisco.com with ESMTP; 09 Aug 2011 22:35:31 +0000 Received: from dwingWS ([10.21.76.82]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p79MZUV9012649; Tue, 9 Aug 2011 22:35:30 GMT From: "Dan Wing" To: "'Michael Tuexen'" References: <026301cc5303$611e3a40$235aaec0$@com> In-Reply-To: Subject: RE: Apparent SCTP API oversights, draft-ietf-tsvwg-sctpsocket-30 Date: Tue, 9 Aug 2011 15:35:30 -0700 Message-ID: <051901cc56e4$a52a5950$ef7f0bf0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxW2FB6VFH+9BF1RpuI8lqNTobAcAAC9RFg Content-Language: en-us Cc: ka-cheong.poon@oracle.com, tsvwg@ietf.org, vladislav.yasevich@hp.com, draft-ietf-tsvwg-sctpsocket@tools.ietf.org, "'Peter Lei \(peterlei\)'" , randall@lakerest.net X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 22:35:03 -0000 Yes, thanks. With the datastructure renamed from spp_ipv4_tos to spp_dscp, I assume you would also change prose from ToS to DSCP? #grep -nE "tos|ToS|TOS" draft-ietf-tsvwg-sctpsocket-30.txt 3825: uint8_t spp_ipv4_tos; 3872: spp_ipv4_tos: This field is used in conjunction with the 3873: SPP_IPV4_TOS flag. This setting has precedence over any IPv4 3924: SPP_IPV4_TOS: Setting this flag enables the setting of the IPV4 3925: TOS value associated with either the association or a specific 3926: address. The value is obtained in the spp_ipv4_tos field. 3929: spp_ipv4_tos field has a valid value returned. If a specific 3931: field) then that specific destination address' TOS value is 3933: association default TOS is returned. If neither an association 3934: nor a destination is specified, then the sockets default TOS is -d > -----Original Message----- > From: Michael Tuexen [mailto:tuexen@fh-muenster.de] > Sent: Tuesday, August 09, 2011 2:07 PM > To: Dan Wing > Cc: draft-ietf-tsvwg-sctpsocket@tools.ietf.org; tsvwg@ietf.org; > randall@lakerest.net; ka-cheong.poon@oracle.com; 'Peter Lei > (peterlei)'; vladislav.yasevich@hp.com > Subject: Re: Apparent SCTP API oversights, draft-ietf-tsvwg-sctpsocket- > 30 > > Hi Dan, > > based on the discussion, I suggest the following text changes: > On Aug 5, 2011, at 2:05 AM, Dan Wing wrote: > > > I would like clarification on my misunderstanding, or changes > > to draft-ietf-tsvwg-sctpsocket, to accommodate what appear to > > be some oversights in the SCTP API: > > > > 1. The infotype parameter of sctp_sendv() allows indicating if the > > data should be sent with partial reliability or full reliability > > using sctp_prinfo. However, there does not appear to be a way to > > adjust the IPv4 or IPv6 DSCP bits when switching between > > full/partial reliablity, except by modifying the entire > > association itself (using spp_ipv4_tos). This is quite limiting. > No changes. > > > > > > 2. When modifying an association (e.g., to have different DSCP > > value), I could not find text in draft-ietf-tsvwg-sctpsocket-30 that > > indicates if the modification applies immediately (including to > > packets queued and to packets not yet acknowledged by the > > receiver) or if the modification applies to subsequent calls > > to send(). > > > > This means that to attempt to work around (1), it isn't clear > > if the API would permit me to modify the association's DSCP > > value, call send(), and know that payload will be sent with > > the desired DSCP value. > I added at the end of section 8.1.12: > Please note that changing the flowlabel or DSCP value will affect > all packets sent by the SCTP stack after setting these parameters. > The flowlabel might also be set via the sin6_flowinfo field of the > struct socketaddr_in6 structure. > > > > > > 3. Related to (1), it is desirable that full reliable packets not > > be bundled with partial reliability packets, so that they can have > > different DSCP markings. > > > > http://tools.ietf.org/html/rfc4960#section-10.1 mentions a no-bundle > > flag. However, I could not find in draft-ietf-tsvwg-sctpsocket-30 > > where this is controlled; it appears the API lacks this ability. > I added to section 8.1.5: > In particular, not using any Nagle-like algorithm might > reduce the bundling of small user messages in cases where this > would require an additional delay. > > > > > > 4. draft-ietf-tsvwg-sctpsocket-30 uses the archaic term ToS > > rather than DSCP. At a minimum, to ease string searching, please > > add text near spp_ipv4_tos something like "This is also called the > > DSCP field [RFC2474]". I would prefer, though, that > > draft-ietf-tsvwg-sctpsocket-30 use the term DSCP in compliance > > with RFC3260 and other DiffServ documents. > > > > > > 5. I believe it is an oversight that draft-ietf-tsvwg-sctpsocket-30 > > provides a way to adjust the IPv4 ToS (spp_ipv4_tos) and the IPv6 > > flow label (spp_ipv6_flowlabel), but lacks a way to query or adjust > > the IPv6 Traffic Class field. Please correct this oversight or > > add text justifying the inability to adjust the IPv6 Traffic Class > > field. > The stuff now reads: > struct sctp_paddrparams { > sctp_assoc_t spp_assoc_id; > struct sockaddr_storage spp_address; > uint32_t spp_hbinterval; > uint16_t spp_pathmaxrxt; > uint32_t spp_pathmtu; > uint32_t spp_flags; > uint32_t spp_ipv6_flowlabel; > uint8_t spp_dscp; > }; > > > This field is used in conjunction with the SPP_IPV6_FLOWLABEL flag > and contains the IPv6 flowlabel. The 20 least significant bits are > used for the flowlabel. > This setting has precedence over any IPv6 layer setting. > > This field is used in conjunction with the SPP_DSCP flag and > contains the Differentiated Services Code Point (DSCP). > The 6 least significant bits are used for the DSCP. > This setting has precedence over any IPv4 or IPv6 layer setting. > > ... > > Setting this flag enables the setting of the IPV6 flowlabel value. > The value is contained in the spp_ipv6_flowlabel field. > > Upon retrieval, this flag will be set to indicate that the > spp_ipv6_flowlabel > field has a valid value returned. If a specific destination address is > set (in the spp_address field), then the value returned is that > of the address. If just an association is specified (and no address), > then > the association's default flowlabel is returned. If neither an > association nor a > destination is specified, then the socket's default flowlabel is > returned. > For non IPv6 sockets, this flag will be left cleared. > Setting this flag enables the setting of > the DSCP value associated with > either the association or a specific address. > The value is obtained in the spp_dscp field. > > Upon retrieval, this flag will be set to indicate that the spp_dscp > field > has a valid value returned. If a specific destination address is set > when > called (in the spp_address field) then that specific destination > address' > DSCP value is returned. If just an association is specified then > the association default DSCP is returned. If neither an association nor > a > destination is specified, then the sockets default DSCP is > returned. > > Does this address your issues? > > Best regards > Michael > > > > -d > > > > > > From tuexen@fh-muenster.de Tue Aug 9 21:57:29 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C7D21F8509 for ; Tue, 9 Aug 2011 21:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3t6eQa0iPx7P for ; Tue, 9 Aug 2011 21:57:28 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id EE08921F8500 for ; Tue, 9 Aug 2011 21:57:26 -0700 (PDT) Received: from [192.168.1.195] (p508FCB5B.dip.t-dialin.net [80.143.203.91]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 60D051C0C0BE9; Wed, 10 Aug 2011 06:57:52 +0200 (CEST) Subject: Re: Apparent SCTP API oversights, draft-ietf-tsvwg-sctpsocket-30 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <051901cc56e4$a52a5950$ef7f0bf0$@com> Date: Wed, 10 Aug 2011 06:57:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5E45876B-FE88-4B75-9E7D-1C8225E289A0@fh-muenster.de> References: <026301cc5303$611e3a40$235aaec0$@com> <051901cc56e4$a52a5950$ef7f0bf0$@com> To: "Dan Wing" X-Mailer: Apple Mail (2.1084) Cc: ka-cheong.poon@oracle.com, tsvwg@ietf.org, vladislav.yasevich@hp.com, draft-ietf-tsvwg-sctpsocket@tools.ietf.org, "'Peter Lei \(peterlei\)'" , randall@lakerest.net X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 04:57:29 -0000 On Aug 10, 2011, at 12:35 AM, Dan Wing wrote: > Yes, thanks. =20 >=20 > With the datastructure renamed from spp_ipv4_tos to spp_dscp, I assume = you > would also change prose from ToS to DSCP? >=20 > #grep -nE "tos|ToS|TOS" draft-ietf-tsvwg-sctpsocket-30.txt > 3825: uint8_t spp_ipv4_tos; > 3872: spp_ipv4_tos: This field is used in conjunction with the > 3873: SPP_IPV4_TOS flag. This setting has precedence over any = IPv4 > 3924: SPP_IPV4_TOS: Setting this flag enables the setting of the = IPV4 > 3925: TOS value associated with either the association or a = specific > 3926: address. The value is obtained in the spp_ipv4_tos = field. > 3929: spp_ipv4_tos field has a valid value returned. If a = specific > 3931: field) then that specific destination address' TOS value = is > 3933: association default TOS is returned. If neither an > association > 3934: nor a destination is specified, then the sockets default = TOS > is Yes, that is the text at the end of my e-mail... Best regards Michael >=20 > -d >=20 >> -----Original Message----- >> From: Michael Tuexen [mailto:tuexen@fh-muenster.de] >> Sent: Tuesday, August 09, 2011 2:07 PM >> To: Dan Wing >> Cc: draft-ietf-tsvwg-sctpsocket@tools.ietf.org; tsvwg@ietf.org; >> randall@lakerest.net; ka-cheong.poon@oracle.com; 'Peter Lei >> (peterlei)'; vladislav.yasevich@hp.com >> Subject: Re: Apparent SCTP API oversights, = draft-ietf-tsvwg-sctpsocket- >> 30 >>=20 >> Hi Dan, >>=20 >> based on the discussion, I suggest the following text changes: >> On Aug 5, 2011, at 2:05 AM, Dan Wing wrote: >>=20 >>> I would like clarification on my misunderstanding, or changes >>> to draft-ietf-tsvwg-sctpsocket, to accommodate what appear to >>> be some oversights in the SCTP API: >>>=20 >>> 1. The infotype parameter of sctp_sendv() allows indicating if the >>> data should be sent with partial reliability or full reliability >>> using sctp_prinfo. However, there does not appear to be a way to >>> adjust the IPv4 or IPv6 DSCP bits when switching between >>> full/partial reliablity, except by modifying the entire >>> association itself (using spp_ipv4_tos). This is quite limiting. >> No changes. >>>=20 >>>=20 >>> 2. When modifying an association (e.g., to have different DSCP >>> value), I could not find text in draft-ietf-tsvwg-sctpsocket-30 that >>> indicates if the modification applies immediately (including to >>> packets queued and to packets not yet acknowledged by the >>> receiver) or if the modification applies to subsequent calls >>> to send(). >>>=20 >>> This means that to attempt to work around (1), it isn't clear >>> if the API would permit me to modify the association's DSCP >>> value, call send(), and know that payload will be sent with >>> the desired DSCP value. >> I added at the end of section 8.1.12: >> Please note that changing the flowlabel or DSCP value will affect >> all packets sent by the SCTP stack after setting these parameters. >> The flowlabel might also be set via the sin6_flowinfo field of the >> struct socketaddr_in6 structure. >>>=20 >>>=20 >>> 3. Related to (1), it is desirable that full reliable packets not >>> be bundled with partial reliability packets, so that they can have >>> different DSCP markings. >>>=20 >>> http://tools.ietf.org/html/rfc4960#section-10.1 mentions a no-bundle >>> flag. However, I could not find in draft-ietf-tsvwg-sctpsocket-30 >>> where this is controlled; it appears the API lacks this ability. >> I added to section 8.1.5: >> In particular, not using any Nagle-like algorithm might >> reduce the bundling of small user messages in cases where this >> would require an additional delay. >>>=20 >>>=20 >>> 4. draft-ietf-tsvwg-sctpsocket-30 uses the archaic term ToS >>> rather than DSCP. At a minimum, to ease string searching, please >>> add text near spp_ipv4_tos something like "This is also called the >>> DSCP field [RFC2474]". I would prefer, though, that >>> draft-ietf-tsvwg-sctpsocket-30 use the term DSCP in compliance >>> with RFC3260 and other DiffServ documents. >>>=20 >>>=20 >>> 5. I believe it is an oversight that draft-ietf-tsvwg-sctpsocket-30 >>> provides a way to adjust the IPv4 ToS (spp_ipv4_tos) and the IPv6 >>> flow label (spp_ipv6_flowlabel), but lacks a way to query or adjust >>> the IPv6 Traffic Class field. Please correct this oversight or >>> add text justifying the inability to adjust the IPv6 Traffic Class >>> field. >> The stuff now reads: >> struct sctp_paddrparams { >> sctp_assoc_t spp_assoc_id; >> struct sockaddr_storage spp_address; >> uint32_t spp_hbinterval; >> uint16_t spp_pathmaxrxt; >> uint32_t spp_pathmtu; >> uint32_t spp_flags; >> uint32_t spp_ipv6_flowlabel; >> uint8_t spp_dscp; >> }; >>=20 >> >> This field is used in conjunction with the SPP_IPV6_FLOWLABEL flag >> and contains the IPv6 flowlabel. The 20 least significant bits are >> used for the flowlabel. >> This setting has precedence over any IPv6 layer setting. >> >> This field is used in conjunction with the SPP_DSCP flag and >> contains the Differentiated Services Code Point (DSCP). >> The 6 least significant bits are used for the DSCP. >> This setting has precedence over any IPv4 or IPv6 layer setting. >>=20 >> ... >> >> Setting this flag enables the setting of the IPV6 flowlabel value. >> The value is contained in the spp_ipv6_flowlabel field. >> >> Upon retrieval, this flag will be set to indicate that the >> spp_ipv6_flowlabel >> field has a valid value returned. If a specific destination address = is >> set (in the spp_address field), then the value returned is that >> of the address. If just an association is specified (and no address), >> then >> the association's default flowlabel is returned. If neither an >> association nor a >> destination is specified, then the socket's default flowlabel is >> returned. >> For non IPv6 sockets, this flag will be left cleared. >> Setting this flag enables the setting of >> the DSCP value associated with >> either the association or a specific address. >> The value is obtained in the spp_dscp field. >> >> Upon retrieval, this flag will be set to indicate that the spp_dscp >> field >> has a valid value returned. If a specific destination address is set >> when >> called (in the spp_address field) then that specific destination >> address' >> DSCP value is returned. If just an association is specified then >> the association default DSCP is returned. If neither an association = nor >> a >> destination is specified, then the sockets default DSCP is >> returned. >>=20 >> Does this address your issues? >>=20 >> Best regards >> Michael >>>=20 >>> -d >>>=20 >>>=20 >>>=20 >=20 >=20 From internet-drafts@ietf.org Tue Aug 9 22:17:41 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB62421F874A; Tue, 9 Aug 2011 22:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tn1WC0YZFRiC; Tue, 9 Aug 2011 22:17:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CE721F86DD; Tue, 9 Aug 2011 22:17:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-tsvwg-sctpsocket-31.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110810051741.4239.39214.idtracker@ietfa.amsl.com> Date: Tue, 09 Aug 2011 22:17:41 -0700 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 05:17:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working = Group of the IETF. Title : Sockets API Extensions for Stream Control Transmission P= rotocol (SCTP) Author(s) : Randall R. Stewart Michael Tuexen Kacheong Poon Peter Lei Vladislav Yasevich Filename : draft-ietf-tsvwg-sctpsocket-31.txt Pages : 112 Date : 2011-08-09 This document describes a mapping of the Stream Control Transmission Protocol (SCTP) into a sockets API. The benefits of this mapping include compatibility for TCP applications, access to new SCTP features and a consolidated error and event notification scheme. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-31.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-31.txt From Michael.Tuexen@lurchi.franken.de Tue Aug 9 22:36:05 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83975E8007 for ; Tue, 9 Aug 2011 22:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.005 X-Spam-Level: X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1z-knL-xwbGB for ; Tue, 9 Aug 2011 22:36:05 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 266955E8005 for ; Tue, 9 Aug 2011 22:36:04 -0700 (PDT) Received: from [192.168.1.195] (p508FCB5B.dip.t-dialin.net [80.143.203.91]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 159E51C0C0BCE for ; Wed, 10 Aug 2011 07:36:35 +0200 (CEST) From: =?iso-8859-1?Q?Michael_T=FCxen?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: draft-ietf-tsvwg-sctpsocket-31.txt Date: Wed, 10 Aug 2011 07:36:34 +0200 Message-Id: <966D548E-228A-4E04-AA5D-E1E604ED38EA@lurchi.franken.de> To: tsvwg list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 05:36:05 -0000 Dear all, based on the comments posted by Dan earlier this week I've update the Socket API ID: 1. Add a clarification to SCTP_NODELAY 2. Replace TOS by DSCP in the struct sctp_paddrparams 3. Improve text describing the fields spp_ipv6_flowlabel and spp_dscp You can see the differences at http://tools.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctpsocket-31.txt If you have any comments regarding this change, please drop an e-mail within the next 48 hours. Best reagards Michael From jmpolk@cisco.com Mon Aug 15 17:55:23 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA3A21F8B22 for ; Mon, 15 Aug 2011 17:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.49 X-Spam-Level: X-Spam-Status: No, score=-103.49 tagged_above=-999 required=5 tests=[AWL=-1.247, BAYES_00=-2.599, SARE_SUB_6CONS_WORD=0.356, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6a8ioPC+i9+S for ; Mon, 15 Aug 2011 17:55:23 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED8221F8B0D for ; Mon, 15 Aug 2011 17:55:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1942; q=dns/txt; s=iport; t=1313456170; x=1314665770; h=message-id:date:to:from:subject:mime-version; bh=KjwNR2Vb6P8WMXTPKc/h8ONmn/3XgJEb5WsrBp2rtrU=; b=P69z/cFarXlxGEz0E1/p8VspWrEDA2bjG4le+s/eFwlxKmrLQwo231SK TnSJCulZ40CSoQ8WMkXFFMG8o3W1jHwed59c3OYxTv38ZeTRybfQyDRga dNn5OC1JsEVi2Vh4hZ3d1rmFiPuk+ysLgNkQLK20kFzB3zxinJMbwmJRC E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOK+SU6rRDoG/2dsb2JhbABBqBZ3gVkBJQJWOilEHBmHUpoSgSMBnxOGRwSHX5xF X-IronPort-AV: E=Sophos;i="4.67,377,1309737600"; d="scan'208";a="13389945" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-3.cisco.com with ESMTP; 16 Aug 2011 00:56:09 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8717.cisco.com [10.99.80.24]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7G0u9Zh000534 for ; Tue, 16 Aug 2011 00:56:09 GMT Message-Id: <201108160056.p7G0u9Zh000534@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 15 Aug 2011 19:56:07 -0500 To: tsvwg From: "James M. Polk" Subject: WGLC closed for draft-ietf-tsvwg-sctp-strrst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 00:55:23 -0000 As the chair who initiated the WGLC for SCTP Stream Reconfiguration, I have waited long enough for those that expressed issues in the distant past to come forward with specific suggestions on what to change. The authors having received none, their proposed changes are considered accepted by TSVWG. The WGLC is now closed for this draft. Anyone having an issue with this decision can come find me. James TSVWG co-chair 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 : Stream Control Transmission Protocol (SCTP) Stream Reconfiguration Author(s) : Randall R. Stewart Michael Tuexen Peter Lei Filename : draft-ietf-tsvwg-sctp-strrst-12.txt Pages : 33 Date : 2011-08-06 Many applications that use SCTP want the ability to "reset" a stream. The intention of resetting a stream is to set the numbering sequence of the stream back to 'zero' with a corresponding notification to the upper layer that this has been performed. The applications that want this feature want it so that they can "re-use" streams for different purposes but still utilize the stream sequence number so that the application can track the message flows. Thus, without this feature, a new use of an old stream would result in message numbers greater than expected unless there is a protocol mechanism to "reset the streams back to zero". This document also includes methods for resetting the transport sequence numbers, adding additional streams and resetting all stream sequence numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-strrst-12.txt From gorry@erg.abdn.ac.uk Tue Aug 16 02:06:14 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0AD21F8BE8 for ; Tue, 16 Aug 2011 02:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omx6D0wqjxAK for ; Tue, 16 Aug 2011 02:06:13 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id 534B921F8BC5 for ; Tue, 16 Aug 2011 02:06:12 -0700 (PDT) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p7G96hIJ027819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 16 Aug 2011 10:06:43 +0100 (BST) Message-ID: <4E4A3323.1030309@erg.abdn.ac.uk> Date: Tue, 16 Aug 2011 10:06:43 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: tsvwg WG Subject: Adopting draft-tuexen-tsvwg-sctp-sack-immediately as WG item? - 29-Aug-2011 References: <4E40E36A.6010307@erg.abdn.ac.uk> In-Reply-To: <4E40E36A.6010307@erg.abdn.ac.uk> X-Forwarded-Message-Id: <4E40E36A.6010307@erg.abdn.ac.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: Michael Tuexen X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 09:06:14 -0000 The authors of "SACK-IMMEDIATELY extension for the Stream Control Transmission Protocol draft-tuexen-tsvwg-sctp-sack-immediately-06.txt" requests that this is adopted as WG item. This document defines a method for a sender of a DATA chunk to indicate that the corresponding SACK chunk should be sent back immediately. There was hum indicating general WG support for this at the last IETF in Quebec City, and the document appears mature to complete quickly. This email is to allow people to confirm that there is sufficient energy to complete this work in TSVWG. * PLEASE send an email to this list if you think this work needs to be done in the IETF (even if you previously noted this at the IETF). * PLEASE send an email to this list if you think adopting this document in TSVWG is a good *OR* a bad idea. * Please also indicate if you are willing to REVIEW such a document during its development - our AD has indicated that we expect to have at least 4 people who commit to review WG outputs. If you can promise to do this please say! Please provide any comments at the latest by 29th August 2011. Best regards Gorry & James (TSVWG Co-Chairs) From gorry@erg.abdn.ac.uk Tue Aug 9 00:35:47 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0E321F89BE for ; Tue, 9 Aug 2011 00:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJ20r+B2mRjP for ; Tue, 9 Aug 2011 00:35:46 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1C621F89C1 for ; Tue, 9 Aug 2011 00:35:45 -0700 (PDT) Received: from Gorry.local (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p797aA6k006064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 9 Aug 2011 08:36:11 +0100 (BST) Message-ID: <4E40E36A.6010307@erg.abdn.ac.uk> Date: Tue, 09 Aug 2011 08:36:10 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: tsvwg chair Subject: Adopting draft-tuexen-tsvwg-sctp-sack-immediately as WG item? References: <4628A17A.7050503@ericsson.com> In-Reply-To: <4628A17A.7050503@ericsson.com> X-Forwarded-Message-Id: <4628A17A.7050503@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-Mailman-Approved-At: Tue, 16 Aug 2011 08:05:34 -0700 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 07:35:47 -0000 The authors of "SACK-IMMEDIATELY extension for the Stream Control Transmission Protocol draft-tuexen-tsvwg-sctp-sack-immediately-06.txt" requests that this is adopted as WG item. This document defines a method for a sender of a DATA chunk to indicate that the corresponding SACK chunk should be sent back immediately. There was hum indicating general WG support for this at the last IETF in Quebec City, and the document appears mature to complete quickly. This email is to allow people to confirm that there is sufficient energy to complete this work in TSVWG. * PLEASE send an email to this list if you think this work needs to be done in the IETF (even if you previously noted this at the IETF). * PLEASE send an email to this list if you think adopting this document in TSVWG is a good *OR* a bad idea. * Please also indicate if you are willing to REVIEW such a document during its development - our AD has indicated that we expect to have at least 4 people who commit to review WG outputs. If you can promise to do this please say! Please provide any comments at the latest by 23rd August 2011. Best regards Gorry & James (TSVWG Co-Chairs) From dreibh@iem.uni-due.de Tue Aug 16 12:30:03 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E8121F8B67 for ; Tue, 16 Aug 2011 12:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgDC+etwWM3Z for ; Tue, 16 Aug 2011 12:30:02 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2D61A21F8B73 for ; Tue, 16 Aug 2011 12:30:02 -0700 (PDT) Received: from lupo.localnet ([46.115.11.59]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id p7GJUdVJ000702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Aug 2011 21:30:42 +0200 From: Thomas Dreibholz Organization: University of Duisburg-Essen, Institute for Experimental Mathematics To: tsvwg@ietf.org, gorry@erg.abdn.ac.uk Subject: Re: Adopting draft-tuexen-tsvwg-sctp-sack-immediately as WG item? Date: Tue, 16 Aug 2011 21:30:22 +0200 User-Agent: KMail/1.13.6 (Linux/3.0.0dreibholz; KDE/4.6.5; x86_64; ; ) References: <4628A17A.7050503@ericsson.com> <4E40E36A.6010307@erg.abdn.ac.uk> In-Reply-To: <4E40E36A.6010307@erg.abdn.ac.uk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2120312.4eMNIFNLsR"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201108162130.26572.dreibh@iem.uni-due.de> X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 Cc: tsvwg chair X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 19:30:03 -0000 --nextPart2120312.4eMNIFNLsR Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Dear Gorry, I have read the document and think it is a very useful extension to SCTP. I= =20 also work with the SACK Immediately implementation within the OMNeT++ INET= =20 framework. Of course, I am also willing to review this document during further=20 development.=20 On Dienstag 09 August 2011, Gorry Fairhurst wrote: > The authors of "SACK-IMMEDIATELY extension for the Stream Control > Transmission Protocol draft-tuexen-tsvwg-sctp-sack-immediately-06.txt" > requests that this is adopted as WG item. >=20 > This document defines a method for a sender of a DATA chunk to > indicate that the corresponding SACK chunk should be sent back > immediately. >=20 > There was hum indicating general WG support for this at the last IETF in > Quebec City, and the document appears mature to complete quickly. This > email is to allow people to confirm that there is sufficient energy to > complete this work in TSVWG. >=20 > * PLEASE send an email to this list if you think this work needs to be > done in the IETF (even if you previously noted this at the IETF). >=20 > * PLEASE send an email to this list if you think adopting this document > in TSVWG is a good *OR* a bad idea. >=20 > * Please also indicate if you are willing to REVIEW such a document > during its development - our AD has indicated that we expect to have at > least 4 people who commit to review WG outputs. If you can promise to do > this please say! >=20 > Please provide any comments at the latest by 23rd August 2011. >=20 > Best regards >=20 > Gorry & James > (TSVWG Co-Chairs) Best regards =2D-=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. Thomas Dreibholz University of Duisburg-Essen, Room ES210 Inst. for Experimental Mathematics Ellernstra=C3=9Fe 29 Computer Networking Technology Group D-45326 Essen/Germany =2D---------------------------------------------------------------------- E-Mail: dreibh@iem.uni-due.de Homepage: http://www.iem.uni-due.de/~dreibh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --nextPart2120312.4eMNIFNLsR Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk5KxU8ACgkQ32BbsHYPLWX1rwCfSpP2fR6U9XpiNVi71QMEyXVG 8vcAn0UkPchHv8jTiw2fr8/MoNKPOebc =w9Cn -----END PGP SIGNATURE----- --nextPart2120312.4eMNIFNLsR-- From martin.becke@uni-due.de Wed Aug 17 00:45:08 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E61E21F8B2F for ; Wed, 17 Aug 2011 00:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqNOzDaTqrmu for ; Wed, 17 Aug 2011 00:45:07 -0700 (PDT) Received: from mailoutzim.uni-due.de (mailoutzim.uni-due.de [132.252.185.16]) by ietfa.amsl.com (Postfix) with ESMTP id E6DCD21F8556 for ; Wed, 17 Aug 2011 00:45:06 -0700 (PDT) Received: from HT02.win.uni-due.de (virt098.zim.uni-duisburg-essen.de [132.252.185.98]) by mailoutzim.uni-due.de (8.13.1/8.13.1) with ESMTP id p7H7jlTQ024580; Wed, 17 Aug 2011 09:45:47 +0200 Received: from ccr01.win.uni-due.de ([169.254.1.36]) by HT02.win.uni-due.de ([132.252.190.234]) with mapi id 14.01.0289.001; Wed, 17 Aug 2011 09:45:47 +0200 From: "Becke, Martin" To: "tsvwg@ietf.org" , "gorry@erg.abdn.ac.uk" Subject: AW: Adopting draft-tuexen-tsvwg-sctp-sack-immediately as WG item? Thread-Topic: Adopting draft-tuexen-tsvwg-sctp-sack-immediately as WG item? Thread-Index: AQHMXCYdYNmlx0iqQUmvmD0TlIcY15UfvA0AgADtUrA= Date: Wed, 17 Aug 2011 07:45:46 +0000 Message-ID: References: <4628A17A.7050503@ericsson.com> <4E40E36A.6010307@erg.abdn.ac.uk> <201108162130.26572.dreibh@iem.uni-due.de> In-Reply-To: <201108162130.26572.dreibh@iem.uni-due.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.252.151.70] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.16 Cc: tsvwg chair X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 07:45:08 -0000 PiAqIFBMRUFTRSBzZW5kIGFuIGVtYWlsIHRvIHRoaXMgbGlzdCBpZiB5b3UgdGhpbmsgYWRvcHRp bmcgdGhpcyBkb2N1bWVudCBpbg0KPiAgVFNWV0cgaXMgYSBnb29kICpPUiogYSBiYWQgaWRlYS4N Cg0KSSB0aGluayBpdCBpcyBhIGdvb2QgaWRlYSBhbmQgSSdtIHZlcnkgaW50ZXJlc3RlZCBpbiB0 aGlzIGRyYWZ0Lg0KDQo+ICogUGxlYXNlIGFsc28gaW5kaWNhdGUgaWYgeW91IGFyZSB3aWxsaW5n IHRvIFJFVklFVyBzdWNoIGEgZG9jdW1lbnQgZHVyaW5nIGl0cw0KPiBkZXZlbG9wbWVudA0KDQpJ IGNhbiBiZSBhIHJldmlld2VyLg0KDQpCZXN0IHJlZ2FyZHMNCg0KTWFydGluIEJlY2tlDQoNCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQrCoE1hcnRpbiBCZWNrZQ0KDQrCoFVuaXZlcnNpdHkgb2YgRHVpc2J1cmct RXNzZW4swqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFJvb20gMzA4YQ0KwqBJ bnN0LiBmb3IgRXhwZXJpbWVudGFsIE1hdGhlbWF0aWNzwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgRWxsZXJuc3RyYcOfZSAyOQ0KwqBDb21wdXRlciBOZXR3b3JraW5nIFRlY2hub2xvZ3kgR3Jv dXDCoMKgwqAgwqDCoMKgwqDCoMKgwqDCoEQtNDUzMjYgRXNzZW4vR2VybWFueQ0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCsKgUGhvbmUgOsKgwqDCoMKgICs0OS0yMDEtMTgzLTc2NjcNCsKgRS1NYWlsOsKgwqDC oMKgIG1hcnRpbi5iZWNrZUB1bmktZHVlLmRlDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQoNCg== From mallman@icir.org Wed Aug 17 05:04:01 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8696E21F8783 for ; Wed, 17 Aug 2011 05:04:01 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqqk3amR16kb for ; Wed, 17 Aug 2011 05:04:01 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0080A21F8754 for ; Wed, 17 Aug 2011 05:04:00 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p7HC4fnp010680; Wed, 17 Aug 2011 05:04:41 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 82D6747CA6B; Wed, 17 Aug 2011 08:04:41 -0400 (EDT) To: gorry@erg.abdn.ac.uk From: Mark Allman Subject: Re: Adopting draft-tuexen-tsvwg-sctp-sack-immediately as WG item? In-Reply-To: <4E40E36A.6010307@erg.abdn.ac.uk> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Cadillac Ranch X-URL-0: http://www.icir.org/mallman-files/Document65180.docx X-URL-1: http://www.icir.org/mallman-files/Document37630.html MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma44630-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 17 Aug 2011 08:04:41 -0400 Sender: mallman@icir.org Message-Id: <20110817120441.82D6747CA6B@lawyers.icir.org> Cc: tsvwg chair , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 12:04:01 -0000 ----------ma44630-1 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > The authors of "SACK-IMMEDIATELY extension for the Stream Control > Transmission Protocol > draft-tuexen-tsvwg-sctp-sack-immediately-06.txt" requests that this > is adopted as WG item. >=20 > This document defines a method for a sender of a DATA chunk to > indicate that the corresponding SACK chunk should be sent back > immediately. Well, I don't quite understand the motivation. I read the draft quickly and still I don't quite get it. The reasons given are ... > o The sender has not enough queued user data to send the remaining > DATA chunks due to the Nagle algorithm. OK. But, why then is it important to get a quick ACK? It isn't like the sender is waiting to do anything. > o The sending of a DATA chunk fills the congestion or receiver > window. Again, why is an immediate ACK important here? In steady state if you, say, fill the congestion window then packets on the left side of the window will free up space in the window well before some tagged packet all the way on the right side of the window is processed. > o The sender is in the SHUTDOWN-PENDING state. I don't recall my SCTP state diagram very well. But, can't the receiver detect this and switch to an immediately ACKing strategy at that point? > o The sender has reduced its RTO.Min such that a retransmission > timeout will occur if the receiver delays its SACK. This is self-fulfilling. The RTO *should* include the delayed ACK time. The RTO is not an RTT of some sort, but rather the time until something should be *retransmitted*. So, the samples you get will be naturally taking into account any delay in the ACKing process and the RTO should then accommodate that extra delay. > o The application requests to set the I-bit of the last DATA chunk > of a user message when providing the user message to the SCTP > implementation. Again, why does this really matter? You can't get a message from A to B faster if you flip a magic bit. And, it isn't clear to me that the ACK From=20B to A really matters that much to apps or users. Surely it has to come, but I don't think we're generally sitting on the edge of our seat awaiting it, right? If there is data to be sent by B in response then that'll get sent by B according to the rules and an ACK will get piggybacked. So, basically: (1) I don't think this proposal for a bit is particularly harmful or burdensome or will cause big problems in some way. (2) I don't understand the need and it seems the draft could at least do a much better job explaining why this functionality is desirable (if in fact it is). FWIW, allman ----------ma44630-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk5LrlkACgkQWyrrWs4yIs5cewCdF4/LJ0IStwoDJCVfu22KRKKF HwIAoJBeiy6spH/D9FjAj6Zssh/p9U3N =A5Pj -----END PGP SIGNATURE----- ----------ma44630-1-- From Michael.Tuexen@lurchi.franken.de Wed Aug 17 12:29:03 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E765721F8B12 for ; Wed, 17 Aug 2011 12:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9tw0K4j1oyl for ; Wed, 17 Aug 2011 12:29:03 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 975CA21F8A80 for ; Wed, 17 Aug 2011 12:29:01 -0700 (PDT) Received: from [10.0.1.217] (server.nplab.fh-muenster.de [212.201.121.79]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 7ECF91C0C0BE9; Wed, 17 Aug 2011 21:29:50 +0200 (CEST) Subject: Re: Adopting draft-tuexen-tsvwg-sctp-sack-immediately as WG item? Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <20110817120441.82D6747CA6B@lawyers.icir.org> Date: Wed, 17 Aug 2011 21:29:49 +0200 Content-Transfer-Encoding: 7bit Message-Id: <112A2FE7-D88A-41CB-A82E-7473A008A888@lurchi.franken.de> References: <20110817120441.82D6747CA6B@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.1084) Cc: gorry@erg.abdn.ac.uk, tsvwg chair , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 19:29:04 -0000 On Aug 17, 2011, at 2:04 PM, Mark Allman wrote: > >> The authors of "SACK-IMMEDIATELY extension for the Stream Control >> Transmission Protocol >> draft-tuexen-tsvwg-sctp-sack-immediately-06.txt" requests that this >> is adopted as WG item. >> >> This document defines a method for a sender of a DATA chunk to >> indicate that the corresponding SACK chunk should be sent back >> immediately. > > Well, I don't quite understand the motivation. I read the draft quickly > and still I don't quite get it. > > The reasons given are ... > >> o The sender has not enough queued user data to send the remaining >> DATA chunks due to the Nagle algorithm. > > OK. But, why then is it important to get a quick ACK? It isn't like > the sender is waiting to do anything. Well, it depends. One particular example which comes up to my mind is a simple request/response protocol running on top of SCTP. Without pipelining the request (which is a good thing) you would expect a rate of 1 response per RTT. What people run into is the following. They test with small request size (small means that it fits into an MTU) and get the expected behavior. When the request size is larger than an MTU but smaller than two MTUs they get 5 responses per second. Why? Because the SCTP stack sends the first fragment to the peer, but delays sending the second fragment since there is outstanding data due to the Nagle algorithm. The peer does delay the SACK for 200ms. After sending the SACK, the second fragment of the request gets sent and the response comes back. The use can avoid this by: 1. Disabling Nagle at all. 2. Pipelining multiple requests. The first is doable in any case, the second depends on the application. However, the problem shows up only if the number of packets for the request is even. Based on questions I got in the past, it is not clear for the app writer to deal with these problems. So letting the stack doing it seems useful. We could also disable Nagle by default, but this is a bad idea I think. > >> o The sending of a DATA chunk fills the congestion or receiver >> window. > > Again, why is an immediate ACK important here? In steady state if you, > say, fill the congestion window then packets on the left side of the > window will free up space in the window well before some tagged packet > all the way on the right side of the window is processed. We ran some tests where we had two competing SCTP associations. One sending a SACK for every packet, one sending it for every other with a delay ACK timer. We varied the timer. The result was that the bandwidth was not shared equally. The association sending a SACK for every packet got the higher throughput. Using the I-Bit as described above mitigates this. You can find more details in a paper with the title: Improving the Acknowledgment Handling of SCTP > >> o The sender is in the SHUTDOWN-PENDING state. > > I don't recall my SCTP state diagram very well. But, can't the receiver > detect this and switch to an immediately ACKing strategy at that point? No, the receiver doesn't know. When the sender calls close() the sender waits until there is no outstanding data anymore and then sends a SHUTDOWN. So the sender has to wait for the SACK and the receiver has no idea. > >> o The sender has reduced its RTO.Min such that a retransmission >> timeout will occur if the receiver delays its SACK. > > This is self-fulfilling. The RTO *should* include the delayed ACK > time. The RTO is not an RTT of some sort, but rather the time until > something should be *retransmitted*. So, the samples you get will be > naturally taking into account any delay in the ACKing process and the > RTO should then accommodate that extra delay. I agree with you, it is a misconfiguration here. But I have seen this being deployed... The sender can detect this but can't do anything. Using the I-Bit it has a chance... > >> o The application requests to set the I-bit of the last DATA chunk >> of a user message when providing the user message to the SCTP >> implementation. > > Again, why does this really matter? You can't get a message from A to B > faster if you flip a magic bit. And, it isn't clear to me that the ACK > From B to A really matters that much to apps or users. Surely it has to > come, but I don't think we're generally sitting on the edge of our seat > awaiting it, right? If there is data to be sent by B in response then > that'll get sent by B according to the rules and an ACK will get > piggybacked. The point you are missing here is that there are cases in which the sender delays a message until is has no outstanding data anymore. This happens, for example, in the DTLS/SCTP handshake. SCTP even provides an API for getting notified when there is no outstanding data anymore. I consider DTLS/SCTP the best way of using transport layer security over SCTP (see http://tools.ietf.org/html/rfc6083 ). In the OpenSSL implementation we make use of the I-Bit and this reduces the time to perform the initial handshake by 1 second (5 SACK timeouts). Without the delay it takes about 3 RTTs. So saving 1 second is a huge gain. > > So, basically: > > (1) I don't think this proposal for a bit is particularly harmful or > burdensome or will cause big problems in some way. I agree. In the worst case you get the same behavior as the receive having switched off the delaying of SACKs. So it does't hurt, but you gain something. How much, depends on the particular scenario. > > (2) I don't understand the need and it seems the draft could at least > do a much better job explaining why this functionality is > desirable (if in fact it is). Maybe I was able to clarify it a bit. It it is clearer for you, I can try to integrate some of the above into the ID to make it clearer. Thanks you very much for your comments. Best regards Michael > > FWIW, > allman > > > > From hakim.adhari@uni-due.de Sat Aug 20 04:23:54 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB0C21F86BF for ; Sat, 20 Aug 2011 04:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtBmCcwTes6h for ; Sat, 20 Aug 2011 04:23:53 -0700 (PDT) Received: from mailoutzim.uni-due.de (mailoutzim.uni-due.de [132.252.185.16]) by ietfa.amsl.com (Postfix) with ESMTP id 3164921F86B3 for ; Sat, 20 Aug 2011 04:23:52 -0700 (PDT) Received: from EXCHANGE01.win.uni-due.de (ex02.win.uni-due.de [132.252.180.21]) by mailoutzim.uni-due.de (8.13.1/8.13.1) with ESMTP id p7KBOjfh006805 for ; Sat, 20 Aug 2011 13:24:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: WG: Adopting draft-tuexen-tsvwg-sctp-sack-immediately as WG item? Date: Sat, 20 Aug 2011 13:25:18 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Adopting draft-tuexen-tsvwg-sctp-sack-immediately as WG item? Thread-Index: AcxegW52iYpdxIAeSoiavcpHwwkaggABCovA From: "Adhari, Hakim" To: X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2011 11:23:54 -0000 Hi all, I have worked with the FreeBSD implementation of SACK-IMMEDIATELY and I think it is quite useful to improve the performance. I would review this document. Best wishes, Hakim Adhari Research Assistant at the Computer Networking Technology Group, University of Duisburg-Essen http://www.tdr.wiwi.uni-due.de/team/hakim-adhari/ ---------- Weitergeleitete Nachricht ---------- Betreff: Adopting draft-tuexen-tsvwg-sctp-sack-immediately as WG item? Datum: Dienstag 09 August 2011, 09:36:10 Von: Gorry Fairhurst An: tsvwg chair The authors of "SACK-IMMEDIATELY extension for the Stream Control Transmission Protocol draft-tuexen-tsvwg-sctp-sack-immediately-06.txt"=20 requests that this is adopted as WG item. This document defines a method for a sender of a DATA chunk to indicate that the corresponding SACK chunk should be sent back immediately. There was hum indicating general WG support for this at the last IETF in Quebec City, and the document appears mature to complete quickly. This email is to allow people to confirm that there is sufficient energy to complete this work in TSVWG. * PLEASE send an email to this list if you think this work needs to be done in the IETF (even if you previously noted this at the IETF). * PLEASE send an email to this list if you think adopting this document in TSVWG is a good *OR* a bad idea. * Please also indicate if you are willing to REVIEW such a document during its development - our AD has indicated that we expect to have at least 4 people who commit to review WG outputs. If you can promise to do this please say! Please provide any comments at the latest by 23rd August 2011. Best regards Gorry & James (TSVWG Co-Chairs) From jana.iyengar@gmail.com Sat Aug 20 15:44:08 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78CA421F85BB for ; Sat, 20 Aug 2011 15:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thSznqfkzTj9 for ; Sat, 20 Aug 2011 15:44:07 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id CB40221F85B9 for ; Sat, 20 Aug 2011 15:44:07 -0700 (PDT) Received: by qwc23 with SMTP id 23so3112478qwc.31 for ; Sat, 20 Aug 2011 15:45:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=tvmAneAOcEsrLx1HOe+fNep9g3Ej3VEzU+8l/k1TRww=; b=Vv+4jmx3PFuM7C3/FQiSK8z4aYHJb0TR6Wwn8ejuQ2f6kgh6lctA1gLNmGCpRJOwhl lZtpziuIXK8W0WqFZD0zl7PjOSsmdei395jo9x09hAjKipIwVo5JuxMK0XxgZavSAJqA 7DzxPcYNFJmb6P3NmSlzvO4siSeTf5SGIO1/g= Received: by 10.229.50.71 with SMTP id y7mr420497qcf.180.1313880307095; Sat, 20 Aug 2011 15:45:07 -0700 (PDT) Received: from surutti.fandm.edu (c-174-54-212-80.hsd1.pa.comcast.net [174.54.212.80]) by mx.google.com with ESMTPS id f17sm279271qct.42.2011.08.20.15.45.05 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 20 Aug 2011 15:45:06 -0700 (PDT) Message-ID: <4E5038F0.6050202@fandm.edu> Date: Sat, 20 Aug 2011 18:45:04 -0400 From: Janardhan Iyengar Organization: Franklin & Marshall College User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk Subject: Re: Adopting draft-tuexen-tsvwg-sctp-sack-immediately as WG item? - 29-Aug-2011 References: <4E40E36A.6010307@erg.abdn.ac.uk> <4E4A3323.1030309@erg.abdn.ac.uk> In-Reply-To: <4E4A3323.1030309@erg.abdn.ac.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Michael Tuexen , tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: janardhan.iyengar@fandm.edu List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2011 22:44:08 -0000 Gorry, James, > * Please also indicate if you are willing to REVIEW such a document > during its development - our AD has indicated that we expect to have at > least 4 people who commit to review WG outputs. If you can promise to do this please say! As promised in Quebec City, I will read and review the document soon. Thanks, - jana -- Janardhan Iyengar Assistant Professor, Computer Science Franklin & Marshall College http://www.fandm.edu/jiyengar From ka-cheong.poon@oracle.com Mon Aug 22 09:55:21 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3A421F8BE8 for ; Mon, 22 Aug 2011 09:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7q7RKoCj8yU for ; Mon, 22 Aug 2011 09:55:20 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 5B87521F8BE5 for ; Mon, 22 Aug 2011 09:55:20 -0700 (PDT) Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p7MGuNZu017381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 22 Aug 2011 16:56:25 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p7MGuMxT006270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 22 Aug 2011 16:56:22 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p7MGuGrW006956 for ; Mon, 22 Aug 2011 11:56:16 -0500 Received: from [10.159.208.62] (/10.159.208.62) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 22 Aug 2011 09:56:16 -0700 Message-ID: <4E528957.3040509@oracle.com> Date: Tue, 23 Aug 2011 00:52:39 +0800 From: Kacheong Poon Organization: Oracle Corporation User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:5.0) Gecko/20110629 Thunderbird/5.0 MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: Adopting draft-tuexen-tsvwg-sctp-sack-immediately as WG item? References: <20110817120441.82D6747CA6B@lawyers.icir.org> <112A2FE7-D88A-41CB-A82E-7473A008A888@lurchi.franken.de> In-Reply-To: <112A2FE7-D88A-41CB-A82E-7473A008A888@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A020207.4E528A39.0081,ss=1,re=0.000,fgs=0 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 16:55:21 -0000 On 08/18/11 03:29 AM, Michael Tüxen wrote: > Well, it depends. One particular example which comes up to my mind is > a simple request/response protocol running on top of SCTP. > Without pipelining the request (which is a good thing) you would > expect a rate of 1 response per RTT. What people run into is the > following. They test with small request size (small means that > it fits into an MTU) and get the expected behavior. When the request > size is larger than an MTU but smaller than two MTUs they get > 5 responses per second. Why? Because the SCTP stack sends the first > fragment to the peer, but delays sending the second fragment since > there is outstanding data due to the Nagle algorithm. The peer > does delay the SACK for 200ms. After sending the SACK, the second > fragment of the request gets sent and the response comes back. > The use can avoid this by: > 1. Disabling Nagle at all. > 2. Pipelining multiple requests. > The first is doable in any case, the second depends on the application. > However, the problem shows up only if the number of packets for the > request is even. Based on questions I got in the past, it is not > clear for the app writer to deal with these problems. So letting the > stack doing it seems useful. > We could also disable Nagle by default, but this is a bad idea I think. The above scenario was discussed in the context of TCP many years ago. And AFAIK, most current TCP stacks do not have this issue anymore because the aforementioned way to implement Nagle algorithm has been determined to be the wrong way. There is now no delay in sending the second TCP segment in the above scenario. There is no need to modify the TCP protocol. It is just an implementation issue. If there is no issue in TCP, I guess there should also be no issue in SCTP. In fact, it is much easier to fix the SCTP implementation than to deploy a protocol level change. The former only requires the sender SCTP stack to be fixed while the latter requires both sides to support it plus app level changes. Is a protocol level change really needed? -- K. Poon. ka-cheong.poon@oracle.com From Michael.Tuexen@lurchi.franken.de Mon Aug 22 10:28:55 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6018921F8BA7 for ; Mon, 22 Aug 2011 10:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4v3yaZYnshuq for ; Mon, 22 Aug 2011 10:28:54 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC3821F8BA6 for ; Mon, 22 Aug 2011 10:28:54 -0700 (PDT) Received: from [192.168.1.103] (p5481B166.dip.t-dialin.net [84.129.177.102]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 9802A1C0C0BD8; Mon, 22 Aug 2011 19:29:58 +0200 (CEST) Subject: Re: Adopting draft-tuexen-tsvwg-sctp-sack-immediately as WG item? Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <4E528957.3040509@oracle.com> Date: Mon, 22 Aug 2011 19:29:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <59C5CC47-9251-426A-A6F4-B02D227EE6A3@lurchi.franken.de> References: <20110817120441.82D6747CA6B@lawyers.icir.org> <112A2FE7-D88A-41CB-A82E-7473A008A888@lurchi.franken.de> <4E528957.3040509@oracle.com> To: Kacheong Poon X-Mailer: Apple Mail (2.1084) Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 17:28:55 -0000 On Aug 22, 2011, at 6:52 PM, Kacheong Poon wrote: > On 08/18/11 03:29 AM, Michael T=FCxen wrote: >=20 >> Well, it depends. One particular example which comes up to my mind is >> a simple request/response protocol running on top of SCTP. >> Without pipelining the request (which is a good thing) you would >> expect a rate of 1 response per RTT. What people run into is the >> following. They test with small request size (small means that >> it fits into an MTU) and get the expected behavior. When the request >> size is larger than an MTU but smaller than two MTUs they get >> 5 responses per second. Why? Because the SCTP stack sends the first >> fragment to the peer, but delays sending the second fragment since >> there is outstanding data due to the Nagle algorithm. The peer >> does delay the SACK for 200ms. After sending the SACK, the second >> fragment of the request gets sent and the response comes back. >> The use can avoid this by: >> 1. Disabling Nagle at all. >> 2. Pipelining multiple requests. >> The first is doable in any case, the second depends on the = application. >> However, the problem shows up only if the number of packets for the >> request is even. Based on questions I got in the past, it is not >> clear for the app writer to deal with these problems. So letting the >> stack doing it seems useful. >> We could also disable Nagle by default, but this is a bad idea I = think. >=20 >=20 > The above scenario was discussed in the context of TCP > many years ago. And AFAIK, most current TCP stacks do > not have this issue anymore because the aforementioned > way to implement Nagle algorithm has been determined to > be the wrong way. There is now no delay in sending the > second TCP segment in the above scenario. There is no > need to modify the TCP protocol. It is just an > implementation issue. If there is no issue in TCP, I > guess there should also be no issue in SCTP. So you are arguing that you can change the implementation of the Nagle algorithm. That is correct. However, that does not help in the other scenarios: 1. You need to delay the sending of a SHUTDOWN chunk until you received a SACK, which might be delayed. 2. You need to wait for a possibly delayed SACK timer if you ware waiting for a SENDER_DRY event. 3. You have no chance to deal with misconfigured peers in case the RTO values have been lowered on your side, but the SACK delay on the peer not. Unfortunately, I have seen this multiple times in production networks. >=20 > In fact, it is much easier to fix the SCTP implementation > than to deploy a protocol level change. The former As said above: This only helps if the Nagle algorithm is involved. BTW: Is there a description (ID/RFC) available on the Nagle algorithm you describe? At least on FreeBSD we don't use that, but the old one. > only requires the sender SCTP stack to be fixed while the > latter requires both sides to support it plus app level > changes. >=20 > Is a protocol level change really needed? "Needed" is the crucial point here. Needed in the sense that the protocol is broken without the change: No. Needed in the sense the the protocol shows a good performance in some situations: Yes. In particular taking the complexity of the change involved: 1. For the receiver: trivial. 2. For the sender: very easy. Best regards Michael >=20 >=20 > --=20 >=20 > K. Poon. > ka-cheong.poon@oracle.com >=20 From Michael.Tuexen@lurchi.franken.de Mon Aug 22 12:03:39 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E4721F87D9 for ; Mon, 22 Aug 2011 12:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_28=0.6, J_CHICKENPOX_48=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIGV8ux2VFlw for ; Mon, 22 Aug 2011 12:03:38 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id D55D221F85FE for ; Mon, 22 Aug 2011 12:03:37 -0700 (PDT) Received: from [192.168.1.103] (p5481B166.dip.t-dialin.net [84.129.177.102]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 9C1511C0C0BD8 for ; Mon, 22 Aug 2011 21:04:42 +0200 (CEST) From: =?iso-8859-1?Q?Michael_T=FCxen?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Comments regarding draft-nishida-tsvwg-sctp-failover-03.txt Date: Mon, 22 Aug 2011 21:04:41 +0200 Message-Id: To: tsvwg list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 19:03:39 -0000 Dear all, as promised at the last TSVWG session I would like to bring up some comments regarding draft-nishida-tsvwg-sctp-failover-03.txt. Randy and myself implemented the ID during the last IETF, so these comments are based on some implementation experience. Editorial comments: * I would suggest to have a section 4 which describes existing stuff. Basically it should contain only what is now in section 4.1 and 4.2. * In another section I would describe the the suggested method. This would cover section 4.3, 5.1 and 5.2. This would result in having the suggested method and its discussion in one section. The rules given in 4.3 should be enumerated. Then one can easily refer to them. For the following comments, I will paste them for simpler reading of this e-mail: o The sender maintains a new tunable parameter called Potentially- failed.Max.Retrans (PFMR). An association's PFMR value MUST be lower than the association's PMR value. The recommended value of PFMR =3D 0. I think "MUST be lower" is not the appropriate formulation. What you want to say is that if PFMR >=3D PMR, than quick failover is basically switched off. This is a valid choice of parameters. In FreeBSD, we have used this as the default (PFMR =3D 0xffff). o The sender never transmits data to a PF destination. However, when all destinations are in either PF or Inactive state, the sender SHOULD transition a destination marked PF to the active state and transmit data to this destination. The destination's error counter MUST NOT be cleared during this state transition. It is recommended that the sender transitions the PF destination with least error count (fewest consecutive timeouts) to the active state. In case of a tie (multiple PF destinations with same error count), the sender MAY choose the last active destination. I would prefer to make a weaker formulation than "never transmits data to a PF destination" and not take destinations out of PF. This is = because I would prefer doing it similar to the handling of the unreachable state and there taking it out would result in sending up notifications. So choose a formulation that you want to avoid sending to PF = destinations, but do it if no non PF and reachable destinations are available. o Only heartbeats MUST be sent to PF destination(s) once per RTO. This means the sender SHOULD ignore HB.interval for PF destinations. If an heartbeat is unanswered, the sender increments the error counter and exponentially backs off the RTO value. If error counter is less than PMR, the sender SHOULD transmit another heartbeat immediately after T3-timer expiration. An implementation MAY use protocol parameter 'PFHB.interval' for the interval of heartbeat transmissions. If PFHB.interval is non- zero, a heartbeat packet is sent once per RTO of each destination address plus PFHB.interval with jittering of +/- 50% of the RTO value. Use of PFHB.interval can reduce the frequency of failover, which might be useful where the characteristic of the paths are mostly equal. I'm not sure if it is worth to have a PFHB.interval. At least in FreeBSD we just use 0... So maybe just get rid of it. o When the sender receives an heartbeat ACK from a PF destination, the sender clears the destination's error counter and transitions the PF destination back to active state. This state transition MUST NOT be notified to the ULP unless it is explicitly requested. This destination's cwnd is set to 1 MTU (TODO: or 2? Needs more text discussing rationale; can revisit later?) We don't have defined a notification. I don't see the value of it. So maybe you want to get rid of it? o When all destinations are in the Inactive state, the sender transitions one of the destinations back to the Active state and continues data transmission to this destination. This proposal recommends that the sender transitions the Inactive destination with least error count (fewest consecutive timeouts) to the active state. In case of a tie (multiple Inactive destinations with same error count), the sender MAY choose the last active destination. As said above: Moving one to the active state would require sending up notifications. At least the FreeBSD stack does not move the state to active, it just uses an unreachable (but confirmed) destination address. I think it would also be good for the application to control the = thresholds involved. So I suggest to add a socket API section. The following describes what FreeBSD does:

This section describes how the socket API defined in is extended to provide a way for the application to control the quick failover behavior. Please note that this section is informational only. A socket API implementation based on is extended by adding a new read/write socket option for the level IPPROTO_SCTP and the name SCTP_PEER_ADDR_THLDS as described below. Support for the SCTP_PEER_ADDR_THLDS socket option needs also to be added to the function sctp_opt_info().
Applications can control the quick failover behavior by getting or setting the number of timeouts before a peer address is considered potentially failed or unreachable. The following structure is used to access and modify the thresholds:
struct sctp_paddrthlds { sctp_assoc_t spt_assoc_id; struct sockaddr_storage spt_address; uint16_t spt_pathmaxrxt; uint16_t spt_pathpfthld; };
This parameter is ignored for one-to-one style sockets. For one-to-many style sockets the application may fill in an association identifier or SCTP_FUTURE_ASSOC for this query. It is an error to use SCTP_{CURRENT|ALL}_ASSOC in spt_assoc_id. This specifies which peer address is of interest. If a wildcard address is provided, this socket option applies to all current and future peer = addresses. Each peer address of interest is considered unreachable, if its path error counter exceeds spt_pathmaxrxt. Each peer address of interest is considered potentially failed, if its path error counter exceeds spt_pathpfthld.
Feel free to use this text or change it... Best regards Michael From ka-cheong.poon@oracle.com Tue Aug 23 00:43:30 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9BB21F889A for ; Tue, 23 Aug 2011 00:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhw2T4gZSgbn for ; Tue, 23 Aug 2011 00:43:30 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id F37E121F886D for ; Tue, 23 Aug 2011 00:43:29 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p7N7iXZh004997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Aug 2011 07:44:35 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p7N7iW64020955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Aug 2011 07:44:33 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p7N7iRjN014712; Tue, 23 Aug 2011 02:44:27 -0500 Received: from [10.159.208.62] (/10.159.208.62) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 23 Aug 2011 00:44:27 -0700 Message-ID: <4E53597F.8080100@oracle.com> Date: Tue, 23 Aug 2011 15:40:47 +0800 From: Kacheong Poon Organization: Oracle Corporation User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:5.0) Gecko/20110629 Thunderbird/5.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_T=FCxen?= Subject: Re: Adopting draft-tuexen-tsvwg-sctp-sack-immediately as WG item? References: <20110817120441.82D6747CA6B@lawyers.icir.org> <112A2FE7-D88A-41CB-A82E-7473A008A888@lurchi.franken.de> <4E528957.3040509@oracle.com> <59C5CC47-9251-426A-A6F4-B02D227EE6A3@lurchi.franken.de> In-Reply-To: <59C5CC47-9251-426A-A6F4-B02D227EE6A3@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4E535A63.018F:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 07:43:30 -0000 On 08/23/11 01:29 AM, Michael Tüxen wrote: > So you are arguing that you can change the implementation > of the Nagle algorithm. That is correct. However, that > does not help in the other scenarios: > 1. You need to delay the sending of a SHUTDOWN chunk until > you received a SACK, which might be delayed. What is the rationale of "optimizing" the closing of an association? An app should not need to be involved in the shutdown sequence. For example, an app just call close() and can forget about the association. > 2. You need to wait for a possibly delayed SACK timer if > you ware waiting for a SENDER_DRY event. Can you explain why this is actually important? > 3. You have no chance to deal with misconfigured peers > in case the RTO values have been lowered on your side, > but the SACK delay on the peer not. Unfortunately, > I have seen this multiple times in production networks. As Mark has pointed out, this is not a reason. In fact, if the peer has an implementation or configuration problem, how can you be sure that the peer implements the quick ACK correctly? Adding more features won't help fix misconfiguration or implementation error. I'd argue that adding more features actually make things worse as things are getting even more complicated. Quick ACK is going to hurt instead of helping at all. > As said above: This only helps if the Nagle algorithm is > involved. But it seems to be the single reasonable use of this mechanism given so far. > BTW: Is there a description (ID/RFC) available on the > Nagle algorithm you describe? At least on FreeBSD we > don't use that, but the old one. I think you can search the tcpm or the old tcp-impl mailing list. IMHO, it is just a simple implementation issue which does not really need an ID... > "Needed" is the crucial point here. > Needed in the sense that the protocol is broken without > the change: No. > Needed in the sense the the protocol shows a good performance > in some situations: Yes. The performance issue mentioned can be solved by fixing the implementation. It is not a protocol level issue. > In particular taking the complexity of the change involved: > 1. For the receiver: trivial. > 2. For the sender: very easy. No, a transport protocol level change is never a trivial thing. IMHO, this is a very dangerous thinking. Anyway, just my $0.02. -- K. Poon. ka-cheong.poon@oracle.com From Michael.Tuexen@lurchi.franken.de Tue Aug 23 03:11:07 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A876C21F8AC3 for ; Tue, 23 Aug 2011 03:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtnWo0pgtVEv for ; Tue, 23 Aug 2011 03:11:06 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 0369921F8862 for ; Tue, 23 Aug 2011 03:11:06 -0700 (PDT) Received: from [192.168.1.104] (p5481D90F.dip.t-dialin.net [84.129.217.15]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 830961C0C0BD8; Tue, 23 Aug 2011 12:12:12 +0200 (CEST) Subject: Re: Adopting draft-tuexen-tsvwg-sctp-sack-immediately as WG item? Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen In-Reply-To: <4E53597F.8080100@oracle.com> Date: Tue, 23 Aug 2011 12:12:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8EECA8A0-CBFB-40BA-A504-33F8A11DE536@lurchi.franken.de> References: <20110817120441.82D6747CA6B@lawyers.icir.org> <112A2FE7-D88A-41CB-A82E-7473A008A888@lurchi.franken.de> <4E528957.3040509@oracle.com> <59C5CC47-9251-426A-A6F4-B02D227EE6A3@lurchi.franken.de> <4E53597F.8080100@oracle.com> To: Kacheong Poon X-Mailer: Apple Mail (2.1244.3) Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 10:11:07 -0000 On Aug 23, 2011, at 9:40 AM, Kacheong Poon wrote: > On 08/23/11 01:29 AM, Michael T=FCxen wrote: >=20 >> So you are arguing that you can change the implementation >> of the Nagle algorithm. That is correct. However, that >> does not help in the other scenarios: >> 1. You need to delay the sending of a SHUTDOWN chunk until >> you received a SACK, which might be delayed. >=20 >=20 > What is the rationale of "optimizing" the closing of an > association? An app should not need to be involved in > the shutdown sequence. For example, an app just call > close() and can forget about the association. That is the client side. Think about the server side. This 200ms delay will require the server to keep the assoc around for additional 200ms for just nothing. If you have a server with lots of short living associations, you might want to get rid of them as soon as possible. >=20 >=20 >> 2. You need to wait for a possibly delayed SACK timer if >> you ware waiting for a SENDER_DRY event. >=20 >=20 > Can you explain why this is actually important? If an applications wants to make sure that everything is received by the peer SCTP stack, it will enable the subscribe to the sender dry event and wait for it. If the peer is delaying the SACK for 200ms, it has to wait RTT + 200ms instead of just the RTT. For small RTTs this is a difference. The is used for example in the DTLS handshake. The delays can add up to 1 second. >=20 >=20 >> 3. You have no chance to deal with misconfigured peers >> in case the RTO values have been lowered on your side, >> but the SACK delay on the peer not. Unfortunately, >> I have seen this multiple times in production networks. >=20 >=20 > As Mark has pointed out, this is not a reason. In fact, > if the peer has an implementation or configuration > problem, how can you be sure that the peer implements the > quick ACK correctly? Adding more features won't help fix > misconfiguration or implementation error. I'd argue that > adding more features actually make things worse as things > are getting even more complicated. Quick ACK is going to > hurt instead of helping at all. Hmmm. At least in the scenarios I was able to look at trace files, the receiver was running Linux, which supports the I-Bit. So getting it implemented was not a problem (FreeBSD also supports it, Solaris don't, I guess). I agree, fixing the configuration problem is the solution. But in the traces contained the following pattern: Transmit data, retransmit it, get a SACK with a dup report. Over and over. So the sender can detect that there is some problem, could set the I-bit and at least reduce the traffic on the network. It can also notify the user that there is a problem. >=20 >=20 >> As said above: This only helps if the Nagle algorithm is >> involved. >=20 >=20 > But it seems to be the single reasonable use of this > mechanism given so far. >=20 >=20 >> BTW: Is there a description (ID/RFC) available on the >> Nagle algorithm you describe? At least on FreeBSD we >> don't use that, but the old one. >=20 >=20 > I think you can search the tcpm or the old tcp-impl > mailing list. IMHO, it is just a simple implementation > issue which does not really need an ID... ... OK. So simple that it was missed in the SCTP implementation of BSD, I guess the same for Linux, and assume that Solaris does it right... Just to get it clear: You don't delay a DATA chunk if only the E-bit is set, right? >=20 >=20 >> "Needed" is the crucial point here. >> Needed in the sense that the protocol is broken without >> the change: No. >> Needed in the sense the the protocol shows a good performance >> in some situations: Yes. >=20 >=20 > The performance issue mentioned can be solved by fixing > the implementation. It is not a protocol level issue. I don't see this for the server side problem, for the sender dry problem. >=20 >=20 >> In particular taking the complexity of the change involved: >> 1. For the receiver: trivial. >> 2. For the sender: very easy. >=20 >=20 > No, a transport protocol level change is never a trivial > thing. IMHO, this is a very dangerous thinking. Anyway, > just my $0.02. I did the implementation in FreeBSD and saw the diff for Linux. It is simple. I agree with you, that one has to consider what a user can do with it if it is not used as intended. But you can't be worse than you can already be now by sending back a SACK for each packet... Best regards Michael >=20 >=20 >=20 > --=20 >=20 > K. Poon. > ka-cheong.poon@oracle.com >=20 From preethi.cis@gmail.com Tue Aug 23 16:45:50 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE6621F8BCB for ; Tue, 23 Aug 2011 16:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_28=0.6, J_CHICKENPOX_48=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKsvV0BoSukE for ; Tue, 23 Aug 2011 16:45:49 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id BFDF821F8B40 for ; Tue, 23 Aug 2011 16:45:49 -0700 (PDT) Received: by yxj17 with SMTP id 17so600757yxj.31 for ; Tue, 23 Aug 2011 16:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=08ei5T5izG+8TzYnz2VaUsDsykAcIKPaSbuEpQufRTU=; b=hBQIhJ46CklcmHZIb9kCVHpItF6IxN7X/FRBZx+GxvQBmb3LJeSb4ecAyA513uLY7y 6yDZJCd/XgyJ+Jf5fCDk31NomYcmWskAVthd/o3X9yjdG5CNIvEKYeNQl5hckvxk+TWx UcWh9EpZkdYV6bzpjC9RljsSJKUrvQLeykZHs= Received: by 10.100.246.35 with SMTP id t35mr4197253anh.11.1314143216257; Tue, 23 Aug 2011 16:46:56 -0700 (PDT) Received: from [128.107.112.252] (dhcp-128-107-112-252.cisco.com [128.107.112.252]) by mx.google.com with ESMTPS id v6sm365924anq.2.2011.08.23.16.46.52 (version=SSLv3 cipher=OTHER); Tue, 23 Aug 2011 16:46:55 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Tue, 23 Aug 2011 16:46:49 -0700 Subject: Re: Comments regarding draft-nishida-tsvwg-sctp-failover-03.txt From: Preethi Natarajan To: Michael =?ISO-8859-1?B?VPx4ZW4=?= , tsvwg list Message-ID: Thread-Topic: Comments regarding draft-nishida-tsvwg-sctp-failover-03.txt Thread-Index: Acxh7uzOEzD8eRgfGUmsUJsyt2Wk9g== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 23:45:50 -0000 Hi Michael, Thanks a lot for the comments/suggestions. Please find our response below. On 8/22/11 12:04 PM, "Michael T=FCxen" wrote: > Dear all, >=20 > as promised at the last TSVWG session I would like to bring up > some comments regarding draft-nishida-tsvwg-sctp-failover-03.txt. >=20 > Randy and myself implemented the ID during the last IETF, so > these comments are based on some implementation experience. >=20 > Editorial comments: >=20 > * I would suggest to have a section 4 which describes existing > stuff. Basically it should contain only what is now in section 4.1 > and 4.2. > * In another section I would describe the the suggested method. > This would cover section 4.3, 5.1 and 5.2. >=20 > This would result in having the suggested method and its discussion > in one section. Agree. >=20 > The rules given in 4.3 should be enumerated. Then one can easily refer > to them. OK. >=20 > For the following comments, I will paste them for simpler reading > of this e-mail: >=20 > o The sender maintains a new tunable parameter called Potentially- > failed.Max.Retrans (PFMR). An association's PFMR value MUST be > lower than the association's PMR value. The recommended value of > PFMR =3D 0. >=20 > I think "MUST be lower" is not the appropriate formulation. What you > want to say is that if PFMR >=3D PMR, than quick failover is basically > switched off. This is a valid choice of parameters. > In FreeBSD, we have used this as the default (PFMR =3D 0xffff). >=20 OK. > o The sender never transmits data to a PF destination. However, > when all destinations are in either PF or Inactive state, the > sender SHOULD transition a destination marked PF to the active > state and transmit data to this destination. The destination's > error counter MUST NOT be cleared during this state transition. > It is recommended that the sender transitions the PF destination > with least error count (fewest consecutive timeouts) to the active > state. In case of a tie (multiple PF destinations with same error > count), the sender MAY choose the last active destination. >=20 > I would prefer to make a weaker formulation than "never transmits data > to a PF destination" and not take destinations out of PF. This is because > I would prefer doing it similar to the handling of the unreachable state > and there taking it out would result in sending up notifications. > So choose a formulation that you want to avoid sending to PF destinations= , > but do it if no non PF and reachable destinations are available. Yes, agree that transition from PF to Active shouldn't result in notifications to the ULP. We are fine with a weaker formulation for the first sentence. However, it may be a good idea to decouple ULP notification and destination state transition. What do you think? How about the followin= g to replace the first few sentences above -- "The sender SHOULD avoid data transmission to PF destinations. When all destinations are in either PF or Inactive state, the sender MAY move the destination from PF to active state (and transmit data to the active destination) or the sender MAY transmit data to a PF destination. >=20 > o Only heartbeats MUST be sent to PF destination(s) once per RTO. > This means the sender SHOULD ignore HB.interval for PF > destinations. If an heartbeat is unanswered, the sender > increments the error counter and exponentially backs off the RTO > value. If error counter is less than PMR, the sender SHOULD > transmit another heartbeat immediately after T3-timer expiration. > An implementation MAY use protocol parameter 'PFHB.interval' for > the interval of heartbeat transmissions. If PFHB.interval is non- > zero, a heartbeat packet is sent once per RTO of each destination > address plus PFHB.interval with jittering of +/- 50% of the RTO > value. Use of PFHB.interval can reduce the frequency of failover, > which might be useful where the characteristic of the paths are > mostly equal. >=20 > I'm not sure if it is worth to have a PFHB.interval. At least in FreeBSD > we just use 0... So maybe just get rid of it. We'll discuss and get back on this one. >=20 > o When the sender receives an heartbeat ACK from a PF destination, > the sender clears the destination's error counter and transitions > the PF destination back to active state. This state transition > MUST NOT be notified to the ULP unless it is explicitly requested. > This destination's cwnd is set to 1 MTU (TODO: or 2? Needs more > text discussing rationale; can revisit later?) >=20 > We don't have defined a notification. I don't see the value > of it. So maybe you want to get rid of it? OK.=20 >=20 > o When all destinations are in the Inactive state, the sender > transitions one of the destinations back to the Active state and > continues data transmission to this destination. This proposal > recommends that the sender transitions the Inactive destination > with least error count (fewest consecutive timeouts) to the active > state. In case of a tie (multiple Inactive destinations with same > error count), the sender MAY choose the last active destination. >=20 > As said above: Moving one to the active state would require sending > up notifications. At least the FreeBSD stack does not move the > state to active, it just uses an unreachable (but confirmed) destination > address. OK.=20 >=20 >=20 > I think it would also be good for the application to control the threshol= ds > involved. So I suggest to add a socket API section. Agree. We'll add text describing such a socket API as you suggested. Preethi From yoshifumi.nishida@gmail.com Wed Aug 24 03:23:07 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCAB21F8B35 for ; Wed, 24 Aug 2011 03:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.769 X-Spam-Level: X-Spam-Status: No, score=-102.769 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNWoUzrFrzxZ for ; Wed, 24 Aug 2011 03:23:06 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 50B4C21F8839 for ; Wed, 24 Aug 2011 03:23:06 -0700 (PDT) Received: by pzk33 with SMTP id 33so1646907pzk.18 for ; Wed, 24 Aug 2011 03:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/mRknf0PNDmzFfU/gvKP03ysaLXmZiK08T9mBRDEWL8=; b=N/6GN8AgrlMWPVOTS182OjhYgGBsKcKKg7d/GyoNtqNefEyQdYJRyNc2p2gBeDp54J 8BMp6P7ZWGt2UccG8oI13rYI9x8Omp6dhckQFU0jvrthmeFsTq7gndp7zHw7o2mhKFgu /4NqE6GYJnIMxWwqG7W0h+WIw72Xkmyc/aw5o= MIME-Version: 1.0 Received: by 10.142.208.13 with SMTP id f13mr2784047wfg.146.1314181454622; Wed, 24 Aug 2011 03:24:14 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.142.88.11 with HTTP; Wed, 24 Aug 2011 03:24:14 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Aug 2011 03:24:14 -0700 X-Google-Sender-Auth: Qjn4Ap1W9Q4xjjoHp9BnEgB591g Message-ID: Subject: Re: Comments regarding draft-nishida-tsvwg-sctp-failover-03.txt From: Yoshifumi Nishida To: =?ISO-8859-1?Q?Michael_T=FCxen?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tsvwg list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 10:23:07 -0000 Hi Michael, Thank you so much for the review. Most points were addressed by Preethi. So, I just would like to clarify one point. 2011/8/22 Michael T=FCxen : > > =A0 o =A0When the sender receives an heartbeat ACK from a PF destination, > =A0 =A0 =A0the sender clears the destination's error counter and transiti= ons > =A0 =A0 =A0the PF destination back to active state. =A0This state transit= ion > =A0 =A0 =A0MUST NOT be notified to the ULP unless it is explicitly reques= ted. > =A0 =A0 =A0This destination's cwnd is set to 1 MTU (TODO: or 2? =A0Needs = more > =A0 =A0 =A0text discussing rationale; can revisit later?) > > We don't have defined a notification. I don't see the value > of it. So maybe you want to get rid of it? Hmm. I might miss your point, but I believe we cannot use arbitrary value.. Shall we refer 7.2.1 in RFC4960? -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From Michael.Tuexen@lurchi.franken.de Wed Aug 24 05:23:59 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E27421F8B2D for ; Wed, 24 Aug 2011 05:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, J_CHICKENPOX_28=0.6, J_CHICKENPOX_48=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgIRZ4NaFGsk for ; Wed, 24 Aug 2011 05:23:58 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0D621F87FC for ; Wed, 24 Aug 2011 05:23:57 -0700 (PDT) Received: from [192.168.1.103] (p5481D9CE.dip.t-dialin.net [84.129.217.206]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 0D7811C0C0BD9; Wed, 24 Aug 2011 14:25:05 +0200 (CEST) Subject: Re: Comments regarding draft-nishida-tsvwg-sctp-failover-03.txt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Date: Wed, 24 Aug 2011 14:25:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0F04C1A8-E091-4F87-BF84-768AC2A620E7@lurchi.franken.de> References: To: Preethi Natarajan X-Mailer: Apple Mail (2.1084) Cc: tsvwg list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 12:23:59 -0000 On Aug 24, 2011, at 1:46 AM, Preethi Natarajan wrote: > Hi Michael, >=20 > Thanks a lot for the comments/suggestions. Please find our response = below. >=20 >=20 > On 8/22/11 12:04 PM, "Michael T=FCxen" = > wrote: >=20 >> Dear all, >>=20 >> as promised at the last TSVWG session I would like to bring up >> some comments regarding draft-nishida-tsvwg-sctp-failover-03.txt. >>=20 >> Randy and myself implemented the ID during the last IETF, so >> these comments are based on some implementation experience. >>=20 >> Editorial comments: >>=20 >> * I would suggest to have a section 4 which describes existing >> stuff. Basically it should contain only what is now in section 4.1 >> and 4.2. >> * In another section I would describe the the suggested method. >> This would cover section 4.3, 5.1 and 5.2. >>=20 >> This would result in having the suggested method and its discussion >> in one section. >=20 > Agree. >=20 >>=20 >> The rules given in 4.3 should be enumerated. Then one can easily = refer >> to them. >=20 > OK. >=20 >>=20 >> For the following comments, I will paste them for simpler reading >> of this e-mail: >>=20 >> o The sender maintains a new tunable parameter called Potentially- >> failed.Max.Retrans (PFMR). An association's PFMR value MUST be >> lower than the association's PMR value. The recommended value = of >> PFMR =3D 0. >>=20 >> I think "MUST be lower" is not the appropriate formulation. What you >> want to say is that if PFMR >=3D PMR, than quick failover is = basically >> switched off. This is a valid choice of parameters. >> In FreeBSD, we have used this as the default (PFMR =3D 0xffff). >>=20 >=20 > OK. >=20 >> o The sender never transmits data to a PF destination. However, >> when all destinations are in either PF or Inactive state, the >> sender SHOULD transition a destination marked PF to the active >> state and transmit data to this destination. The destination's >> error counter MUST NOT be cleared during this state transition. >> It is recommended that the sender transitions the PF destination >> with least error count (fewest consecutive timeouts) to the = active >> state. In case of a tie (multiple PF destinations with same = error >> count), the sender MAY choose the last active destination. >>=20 >> I would prefer to make a weaker formulation than "never transmits = data >> to a PF destination" and not take destinations out of PF. This is = because >> I would prefer doing it similar to the handling of the unreachable = state >> and there taking it out would result in sending up notifications. >> So choose a formulation that you want to avoid sending to PF = destinations, >> but do it if no non PF and reachable destinations are available. >=20 > Yes, agree that transition from PF to Active shouldn't result in > notifications to the ULP. We are fine with a weaker formulation for = the > first sentence. However, it may be a good idea to decouple ULP = notification > and destination state transition. What do you think? How about the = following > to replace the first few sentences above -- "The sender SHOULD avoid = data > transmission to PF destinations. When all destinations are in either = PF or > Inactive state, the sender MAY move the destination from PF to active = state > (and transmit data to the active destination) or the sender MAY = transmit > data to a PF destination. The new text is OK, but my reasoning was: 1. You have text describing what to do if all destinations are in PF. This is necessary. 2. You have text describing what to do if all destinations are = unreachable. This is necessary. 3. Both texts are similar. This is good. 4. There should not be a state change required in 2., since this would require notifications which would give the wrong impression to the application. Therefore I would also prefer no state change in 1. >=20 >>=20 >> o Only heartbeats MUST be sent to PF destination(s) once per RTO. >> This means the sender SHOULD ignore HB.interval for PF >> destinations. If an heartbeat is unanswered, the sender >> increments the error counter and exponentially backs off the RTO >> value. If error counter is less than PMR, the sender SHOULD >> transmit another heartbeat immediately after T3-timer = expiration. >> An implementation MAY use protocol parameter 'PFHB.interval' for >> the interval of heartbeat transmissions. If PFHB.interval is = non- >> zero, a heartbeat packet is sent once per RTO of each = destination >> address plus PFHB.interval with jittering of +/- 50% of the RTO >> value. Use of PFHB.interval can reduce the frequency of = failover, >> which might be useful where the characteristic of the paths are >> mostly equal. >>=20 >> I'm not sure if it is worth to have a PFHB.interval. At least in = FreeBSD >> we just use 0... So maybe just get rid of it. >=20 > We'll discuss and get back on this one. >=20 >>=20 >> o When the sender receives an heartbeat ACK from a PF destination, >> the sender clears the destination's error counter and = transitions >> the PF destination back to active state. This state transition >> MUST NOT be notified to the ULP unless it is explicitly = requested. >> This destination's cwnd is set to 1 MTU (TODO: or 2? Needs more >> text discussing rationale; can revisit later?) >>=20 >> We don't have defined a notification. I don't see the value >> of it. So maybe you want to get rid of it? >=20 > OK.=20 >=20 >>=20 >> o When all destinations are in the Inactive state, the sender >> transitions one of the destinations back to the Active state and >> continues data transmission to this destination. This proposal >> recommends that the sender transitions the Inactive destination >> with least error count (fewest consecutive timeouts) to the = active >> state. In case of a tie (multiple Inactive destinations with = same >> error count), the sender MAY choose the last active destination. >>=20 >> As said above: Moving one to the active state would require sending >> up notifications. At least the FreeBSD stack does not move the >> state to active, it just uses an unreachable (but confirmed) = destination >> address. >=20 > OK.=20 >=20 >>=20 >>=20 >> I think it would also be good for the application to control the = thresholds >> involved. So I suggest to add a socket API section. >=20 > Agree. We'll add text describing such a socket API as you suggested. >=20 > Preethi >=20 >=20 >=20 From Michael.Tuexen@lurchi.franken.de Wed Aug 24 05:25:53 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6147F21F86DF for ; Wed, 24 Aug 2011 05:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdXh-f7cvHMD for ; Wed, 24 Aug 2011 05:25:53 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id DAEB521F8584 for ; Wed, 24 Aug 2011 05:25:52 -0700 (PDT) Received: from [192.168.1.103] (p5481D9CE.dip.t-dialin.net [84.129.217.206]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id BCE941C0C0BD9; Wed, 24 Aug 2011 14:27:02 +0200 (CEST) Subject: Re: Comments regarding draft-nishida-tsvwg-sctp-failover-03.txt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Date: Wed, 24 Aug 2011 14:27:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <91A7771A-DFD8-401D-B9E1-BB1199C12CC6@lurchi.franken.de> References: To: Yoshifumi Nishida X-Mailer: Apple Mail (2.1084) Cc: tsvwg list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 12:25:53 -0000 On Aug 24, 2011, at 12:24 PM, Yoshifumi Nishida wrote: > Hi Michael, >=20 > Thank you so much for the review. Most points were addressed by = Preethi. > So, I just would like to clarify one point. >=20 > 2011/8/22 Michael T=FCxen : >=20 >>=20 >> o When the sender receives an heartbeat ACK from a PF destination, >> the sender clears the destination's error counter and = transitions >> the PF destination back to active state. This state transition >> MUST NOT be notified to the ULP unless it is explicitly = requested. >> This destination's cwnd is set to 1 MTU (TODO: or 2? Needs more >> text discussing rationale; can revisit later?) >>=20 >> We don't have defined a notification. I don't see the value >> of it. So maybe you want to get rid of it? >=20 > Hmm. I might miss your point, but I believe we cannot use arbitrary = value.. > Shall we refer 7.2.1 in RFC4960? I was not clear... I'm referring to the sentence: This state transition MUST NOT be notified to the ULP unless it is explicitly requested. Currently we do not have such a notification. That is why I'm asking, if it would be better to remove it. Best regards Michael >=20 > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp >=20 From mallman@icir.org Wed Aug 24 09:51:10 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C61E21F8AEA for ; Wed, 24 Aug 2011 09:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsvfQqEv9TKP for ; Wed, 24 Aug 2011 09:51:08 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 508EA21F8BEF for ; Wed, 24 Aug 2011 09:51:08 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p7OGq7ZA012333; Wed, 24 Aug 2011 09:52:08 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 5B8185374B1; Wed, 24 Aug 2011 12:52:07 -0400 (EDT) To: =?iso-8859-1?Q?Michael_T=FCxen?= From: Mark Allman Subject: Re: Adopting draft-tuexen-tsvwg-sctp-sack-immediately as WG item? In-Reply-To: <112A2FE7-D88A-41CB-A82E-7473A008A888@lurchi.franken.de> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Sweet Home Alabama X-URL-0: http://www.icir.org/mallman-files/Document63396.jpg X-URL-1: http://www.icir.org/mallman-files/Document87938.pdf X-URL-2: http://www.icir.org/mallman-files/Document40428.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma11316-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 24 Aug 2011 12:52:07 -0400 Sender: mallman@icir.org Message-Id: <20110824165207.5B8185374B1@lawyers.icir.org> Cc: gorry@erg.abdn.ac.uk, tsvwg chair , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 16:51:10 -0000 ----------ma11316-1 Content-Type: text/plain Content-Disposition: inline > >> o The sender has not enough queued user data to send the remaining > >> DATA chunks due to the Nagle algorithm. > > > > OK. But, why then is it important to get a quick ACK? It isn't > > like the sender is waiting to do anything. > > Well, it depends. One particular example which comes up to my mind is > a simple request/response protocol running on top of SCTP. Without > pipelining the request (which is a good thing) you would expect a rate > of 1 response per RTT. What people run into is the following. They > test with small request size (small means that it fits into an MTU) > and get the expected behavior. When the request size is larger than an > MTU but smaller than two MTUs they get 5 responses per second. Why? > > [...] > > The use can avoid this by: > 1. Disabling Nagle at all. > 2. Pipelining multiple requests. > > The first is doable in any case, the second depends on the > application. However, the problem shows up only if the number of > packets for the request is even. Based on questions I got in the past, > it is not clear for the app writer to deal with these problems. So > letting the stack doing it seems useful. We could also disable Nagle > by default, but this is a bad idea I think. I understand the case... we write 1.5 packets and one gets sent and the other sits there waiting until the first is ACKed (in the hopes that more data will be sent and it can all be aggregated into a larger packet). And, the ACK is further delayed by delayed ACKs at the receiver. And, so if you could tell the receiver to ACK immediately then that'd save a little time. OK, but that nips at the edge of the problem, right? First and foremost this is an issue of the sender not the acknowledger. I.e., if you have the cwnd why delay the 0.5 packets? Sure, we want to aggregate packets to the extent possible. But, if that notion is getting in the way for some app then lets not do it. Lets either turn Nagle off or let one short write be outstanding or something. It doesn't seem like an "ACK now" bit is really addressing this problem. Put a different way, if the situation is this .... (1) send a full packet, queue half-a-packet (2) full packet arrives 0.5*RTT later (3) receiver sits around waiting for another packet such that it can combine ACKs for some time X (4) after X seconds have elapsed the receiver gives up and ACKs, that ACK arrives at the sender 0.5*RTT later (6) sender gets ACK, sends the half-a-packet (7) the half-a-packet arrives 0.5*RTT later (8) receiver awaits another packet to coalesce ACKs, gives up after Y seconds and sends an ACK (9) ACK arrives 0.5*RTT later So, that whole thing takes 2*RTT + X + Y. With the proposal you are setting X=Y=0. The process still takes 2 RTTs. If you just write the 1.5 packets in step (1) the whole thing will take 1 RTT. And, doing so is something the sender wholly controls without any new protocol machinery. > >> o The sending of a DATA chunk fills the congestion or receiver > >> window. > > > > Again, why is an immediate ACK important here? In steady state if you, > > say, fill the congestion window then packets on the left side of the > > window will free up space in the window well before some tagged packet > > all the way on the right side of the window is processed. > > We ran some tests where we had two competing SCTP associations. One > sending a SACK for every packet, one sending it for every other with a > delay ACK timer. We varied the timer. The result was that the > bandwidth was not shared equally. The association sending a SACK for > every packet got the higher throughput. Using the I-Bit as described > above mitigates this. You can find more details in a paper with the > title: Improving the Acknowledgment Handling of SCTP (I can't find the paper ... can you send me a copy?) The I-Bit mitigates what? If you want the receiver to ACK every segment then make it do so. I don't quite follow this reasoning at all. Delayed ACKs hurt performance, ACK-every helps it. OK. But, what ... ? We want to pretend that the receiver does delayed ACKs, but have the sender over-rule that notion and turn them on? That doesn't make any sense to me. > >> o The sender is in the SHUTDOWN-PENDING state. > > > > I don't recall my SCTP state diagram very well. But, can't the receiver > > detect this and switch to an immediately ACKing strategy at that point? > No, the receiver doesn't know. > When the sender calls close() the sender waits until there is no outstanding > data anymore and then sends a SHUTDOWN. So the sender has to wait for the > SACK and the receiver has no idea. OK- fair enough. I'd call this a corner case that nobody would really care about. Generally speaking nobody sits around waiting on a connection tear-down to move on to their next piece of work. > >> o The sender has reduced its RTO.Min such that a retransmission > >> timeout will occur if the receiver delays its SACK. > > > > This is self-fulfilling. The RTO *should* include the delayed ACK > > time. The RTO is not an RTT of some sort, but rather the time until > > something should be *retransmitted*. So, the samples you get will > > be naturally taking into account any delay in the ACKing process and > > the RTO should then accommodate that extra delay. > > I agree with you, it is a misconfiguration here. But I have seen this > being deployed... The sender can detect this but can't do > anything. Using the I-Bit it has a chance... The sender can detect this and do nothing? What? The sender is **in control of** the RTO! This is completely nonsensical. > >> o The application requests to set the I-bit of the last DATA chunk > >> of a user message when providing the user message to the SCTP > >> implementation. > > > > Again, why does this really matter? You can't get a message from A to B > > faster if you flip a magic bit. And, it isn't clear to me that the ACK > > From B to A really matters that much to apps or users. Surely it has to > > come, but I don't think we're generally sitting on the edge of our seat > > awaiting it, right? If there is data to be sent by B in response then > > that'll get sent by B according to the rules and an ACK will get > > piggybacked. > > The point you are missing here is that there are cases in which the > sender delays a message until is has no outstanding data anymore. > This happens, for example, in the DTLS/SCTP handshake. SCTP even > provides an API for getting notified when there is no outstanding > data anymore. But, you're attacking that problem from the wrong side. You should be working on ways to move that data out of the sender faster, not worrying about a small bit of added delay introduced by the receiver. Or, *at least* worry about the sending first and then if there are still issues with the receiver you can then see about addressing those. But, you're not focused on the fundamental issue here. ACKing immediately can save a little time. A smarter sending pattern can save RTTs. > > (2) I don't understand the need and it seems the draft could at least > > do a much better job explaining why this functionality is > > desirable (if in fact it is). > > Maybe I was able to clarify it a bit. It it is clearer for you, I can > try to integrate some of the above into the ID to make it clearer. Well, no. It is no more clear, IMO. And, yes, you should be able to provide some crisp motivation in the document. It seems to me that without some actual motivation this should not be taken up. allman ----------ma11316-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk5VLDYACgkQWyrrWs4yIs4jDwCfSy6qFmboYXte1bLCDA/wn5Wf WQcAn3xWpItltsq04hJjhu3GK5zUoGoe =yEOG -----END PGP SIGNATURE----- ----------ma11316-1-- From yoshifumi.nishida@gmail.com Wed Aug 24 11:46:39 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1A521F8A58 for ; Wed, 24 Aug 2011 11:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.761 X-Spam-Level: X-Spam-Status: No, score=-102.761 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRGlUd-8xRyC for ; Wed, 24 Aug 2011 11:46:38 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id CA15E21F89B8 for ; Wed, 24 Aug 2011 11:46:38 -0700 (PDT) Received: by iye1 with SMTP id 1so2275805iye.27 for ; Wed, 24 Aug 2011 11:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uJVN4j3wzn50+N2ZDAJq2ecqoOBpeIk3Y+Y3d0odXvQ=; b=Kn+Gtjk+bLdYO98XunXAYQ70v/wyMQQ2piE9cJueJ8HtT/di3GGGn5JDuAfYi6x5wI GT+0aTqOUkahqiXtS0HeFo+qSsunU3eDhBVtjG8DzZXwzWL6cfyCoX8/qS0SClfcsV45 h3Y9QBR7/y1yJQo1dgN4YR+oylFwTsOCRAXEQ= MIME-Version: 1.0 Received: by 10.231.47.17 with SMTP id l17mr6827289ibf.24.1314211669902; Wed, 24 Aug 2011 11:47:49 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.231.199.80 with HTTP; Wed, 24 Aug 2011 11:47:49 -0700 (PDT) In-Reply-To: <91A7771A-DFD8-401D-B9E1-BB1199C12CC6@lurchi.franken.de> References: <91A7771A-DFD8-401D-B9E1-BB1199C12CC6@lurchi.franken.de> Date: Wed, 24 Aug 2011 11:47:49 -0700 X-Google-Sender-Auth: PykZo2XUm6TxCycqfI8Q2QrRfZs Message-ID: Subject: Re: Comments regarding draft-nishida-tsvwg-sctp-failover-03.txt From: Yoshifumi Nishida To: =?ISO-8859-1?Q?Michael_T=FCxen?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tsvwg list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 18:46:39 -0000 2011/8/24 Michael T=FCxen : > On Aug 24, 2011, at 12:24 PM, Yoshifumi Nishida wrote: > >> Hi Michael, >> >> Thank you so much for the review. =A0Most points were addressed by Preet= hi. >> So, I just would like to clarify one point. >> >> 2011/8/22 Michael T=FCxen : >> >>> >>> =A0 o =A0When the sender receives an heartbeat ACK from a PF destinatio= n, >>> =A0 =A0 =A0the sender clears the destination's error counter and transi= tions >>> =A0 =A0 =A0the PF destination back to active state. =A0This state trans= ition >>> =A0 =A0 =A0MUST NOT be notified to the ULP unless it is explicitly requ= ested. >>> =A0 =A0 =A0This destination's cwnd is set to 1 MTU (TODO: or 2? =A0Need= s more >>> =A0 =A0 =A0text discussing rationale; can revisit later?) >>> >>> We don't have defined a notification. I don't see the value >>> of it. So maybe you want to get rid of it? >> >> Hmm. I might miss your point, but I believe we cannot use arbitrary valu= e.. >> Shall we refer 7.2.1 in RFC4960? > I was not clear... I'm referring to the sentence: > > This state transition MUST NOT be notified to the ULP unless it > is explicitly requested. > > Currently we do not have such a notification. That is why I'm asking, > if it would be better to remove it. Oh. I see. Make sense. Thanks for the clarification. Regards, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From Michael.Tuexen@lurchi.franken.de Thu Aug 25 02:56:16 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D124C21F859F for ; Thu, 25 Aug 2011 02:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.587 X-Spam-Level: X-Spam-Status: No, score=-1.587 tagged_above=-999 required=5 tests=[AWL=-0.488, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pz5FZFCOOpVA for ; Thu, 25 Aug 2011 02:56:15 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 4078421F8596 for ; Thu, 25 Aug 2011 02:56:15 -0700 (PDT) Received: from [192.168.1.103] (p5481D3B5.dip.t-dialin.net [84.129.211.181]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 789CD1C0C0BCE; Thu, 25 Aug 2011 11:57:25 +0200 (CEST) Subject: Re: Adopting draft-tuexen-tsvwg-sctp-sack-immediately as WG item? Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <20110824165207.5B8185374B1@lawyers.icir.org> Date: Thu, 25 Aug 2011 11:57:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <585B4D7F-F666-4C4F-8AA4-048CEE19D6DB@lurchi.franken.de> References: <20110824165207.5B8185374B1@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.1084) Cc: gorry@erg.abdn.ac.uk, tsvwg chair , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 09:56:16 -0000 On Aug 24, 2011, at 6:52 PM, Mark Allman wrote: >=20 >>>> o The sender has not enough queued user data to send the remaining >>>> DATA chunks due to the Nagle algorithm. >>>=20 >>> OK. But, why then is it important to get a quick ACK? It isn't >>> like the sender is waiting to do anything. >>=20 >> Well, it depends. One particular example which comes up to my mind is >> a simple request/response protocol running on top of SCTP. Without >> pipelining the request (which is a good thing) you would expect a = rate >> of 1 response per RTT. What people run into is the following. They >> test with small request size (small means that it fits into an MTU) >> and get the expected behavior. When the request size is larger than = an >> MTU but smaller than two MTUs they get 5 responses per second. Why? >>=20 >> [...] >>=20 >> The use can avoid this by: >> 1. Disabling Nagle at all. >> 2. Pipelining multiple requests. >>=20 >> The first is doable in any case, the second depends on the >> application. However, the problem shows up only if the number of >> packets for the request is even. Based on questions I got in the = past, >> it is not clear for the app writer to deal with these problems. So >> letting the stack doing it seems useful. We could also disable Nagle >> by default, but this is a bad idea I think. >=20 > I understand the case... we write 1.5 packets and one gets sent and = the > other sits there waiting until the first is ACKed (in the hopes that > more data will be sent and it can all be aggregated into a larger > packet). And, the ACK is further delayed by delayed ACKs at the > receiver. And, so if you could tell the receiver to ACK immediately > then that'd save a little time. >=20 > OK, but that nips at the edge of the problem, right? First and = foremost > this is an issue of the sender not the acknowledger. I.e., if you = have > the cwnd why delay the 0.5 packets? Sure, we want to aggregate = packets > to the extent possible. But, if that notion is getting in the way for > some app then lets not do it. Lets either turn Nagle off or let one > short write be outstanding or something. =20 >=20 > It doesn't seem like an "ACK now" bit is really addressing this = problem. >=20 > Put a different way, if the situation is this .... >=20 > (1) send a full packet, queue half-a-packet > (2) full packet arrives 0.5*RTT later > (3) receiver sits around waiting for another packet such that it can > combine ACKs for some time X > (4) after X seconds have elapsed the receiver gives up and ACKs, that > ACK arrives at the sender 0.5*RTT later > (6) sender gets ACK, sends the half-a-packet > (7) the half-a-packet arrives 0.5*RTT later > (8) receiver awaits another packet to coalesce ACKs, gives up after Y > seconds and sends an ACK > (9) ACK arrives 0.5*RTT later >=20 > So, that whole thing takes 2*RTT + X + Y. >=20 > With the proposal you are setting X=3DY=3D0. The process still takes = 2 > RTTs. If you just write the 1.5 packets in step (1) the whole thing > will take 1 RTT. And, doing so is something the sender wholly = controls > without any new protocol machinery. I agree. This was pointed out by Kacheong, that using an SCTP specific variant of the Nagle algorithm resolves this issue. Considering B/E bits in the Nagle algorithm is a similar change compared to setting the I bit under that condition and is sender side only. >=20 >>>> o The sending of a DATA chunk fills the congestion or receiver >>>> window. >>>=20 >>> Again, why is an immediate ACK important here? In steady state if = you, >>> say, fill the congestion window then packets on the left side of the >>> window will free up space in the window well before some tagged = packet >>> all the way on the right side of the window is processed. >>=20 >> We ran some tests where we had two competing SCTP associations. One >> sending a SACK for every packet, one sending it for every other with = a >> delay ACK timer. We varied the timer. The result was that the >> bandwidth was not shared equally. The association sending a SACK for >> every packet got the higher throughput. Using the I-Bit as described >> above mitigates this. You can find more details in a paper with the >> title: Improving the Acknowledgment Handling of SCTP >=20 > (I can't find the paper ... can you send me a copy?) I'll send you one in a separate e-mail. >=20 > The I-Bit mitigates what? If you want the receiver to ACK every = segment > then make it do so. I don't quite follow this reasoning at all. > Delayed ACKs hurt performance, ACK-every helps it. OK. But, what ... = ? > We want to pretend that the receiver does delayed ACKs, but have the > sender over-rule that notion and turn them on? That doesn't make any > sense to me. The point is that it improves the situation to not delay *some* SACKs. And only the sender knows which ones are the ones. Simple example: After a timeout the cwnd =3D MTU. So you can send a packet, the peer will delay the SACK, and the sender has to wait for RTT + SACK.delay to send the next one. You can reduce this to RTT. I'm not saying that this makes a huge difference, but the mechanism we are talking about is also not very complex... >=20 >>>> o The sender is in the SHUTDOWN-PENDING state. >>>=20 >>> I don't recall my SCTP state diagram very well. But, can't the = receiver >>> detect this and switch to an immediately ACKing strategy at that = point? >> No, the receiver doesn't know. >> When the sender calls close() the sender waits until there is no = outstanding >> data anymore and then sends a SHUTDOWN. So the sender has to wait for = the >> SACK and the receiver has no idea. >=20 > OK- fair enough. I'd call this a corner case that nobody would really > care about. Generally speaking nobody sits around waiting on a > connection tear-down to move on to their next piece of work. It is a matter of resources allocated at the server. If you are running a server which handles lots of short living (compared to 200 ms) associations, it can reduce the resources substantially. However, I agree, this applies only to specific services. >=20 >>>> o The sender has reduced its RTO.Min such that a retransmission >>>> timeout will occur if the receiver delays its SACK. >>>=20 >>> This is self-fulfilling. The RTO *should* include the delayed ACK >>> time. The RTO is not an RTT of some sort, but rather the time until >>> something should be *retransmitted*. So, the samples you get will >>> be naturally taking into account any delay in the ACKing process and >>> the RTO should then accommodate that extra delay. >>=20 >> I agree with you, it is a misconfiguration here. But I have seen this >> being deployed... The sender can detect this but can't do >> anything. Using the I-Bit it has a chance... >=20 > The sender can detect this and do nothing? What? The sender is **in > control of** the RTO! This is completely nonsensical. Let me be more precisely: What I have seen: RTO.min =3D 50ms, RTO.max =3D = 200ms on the one side. These values are chosen to fulfill some failover requirements. If the peer delays the ACK by 200ms, the pattern could = observe was: Send a packet, retransmit it, get a SACK (with the duplicate TSN = listed). The problem comes up whenever RTT + SACK.delay > RTO.min. You pointed out that the sender measuring the RTT will include the = SACK.delay in its measurements. For SCTP this is only partially true. RTT measurements are done using user data (where it does include the = SACK.delay) and via the heartbeat mechanism (where it does not include it). However, when receiving the SACK with the duplicate report, it can try to improve the situation. However, the solution of the problem is to change the configuration of the receiver. I don't consider this a major reason for introducing the I-Bit. It is just a possibility to improve a bad situation if you have the mechanism in place. >=20 >>>> o The application requests to set the I-bit of the last DATA chunk >>>> of a user message when providing the user message to the SCTP >>>> implementation. >>>=20 >>> Again, why does this really matter? You can't get a message from A = to B >>> faster if you flip a magic bit. And, it isn't clear to me that the = ACK >>> =46rom B to A really matters that much to apps or users. Surely it = has to >>> come, but I don't think we're generally sitting on the edge of our = seat >>> awaiting it, right? If there is data to be sent by B in response = then >>> that'll get sent by B according to the rules and an ACK will get >>> piggybacked. >>=20 >> The point you are missing here is that there are cases in which the >> sender delays a message until is has no outstanding data anymore. >> This happens, for example, in the DTLS/SCTP handshake. SCTP even >> provides an API for getting notified when there is no outstanding >> data anymore. >=20 > But, you're attacking that problem from the wrong side. You should be > working on ways to move that data out of the sender faster, not = worrying > about a small bit of added delay introduced by the receiver. Or, *at > least* worry about the sending first and then if there are still = issues > with the receiver you can then see about addressing those. But, = you're > not focused on the fundamental issue here. ACKing immediately can = save > a little time. A smarter sending pattern can save RTTs. I understand what you are saying. But in the case of DTLS/SCTP we use multiple streams to decouple traffic. However, when it comes to perform a DTLS handshake we have to make sure that all messages fulfill some sequencing constraints, no matter what streams they use. This is done by stopping the sender, draining what it in flight, do the handshake, and continue to send without any constraints anymore. I can go into detail here, but you can also look it up in http://tools.ietf.org/html/rfc6083 The pattern which is used is: Wait for sending the next packet until the peer has acknowledged everything at the transport layer. So you are waiting for the so called SENDER_DRY_EVENT. If the SACK is delayed by 200ms, you wait 200ms longer than needed. And again: The sender knows for which packets delaying the SACK hurts. It would be an alternative to switch delaying SACK off by default, but this would result in more packets. So it might help with the delay but is not optimal in another way. Using delayed SACKs during the handshake really hurts performance wise, since it can add up to a second. >>> (2) I don't understand the need and it seems the draft could at = least >>> do a much better job explaining why this functionality is >>> desirable (if in fact it is). >>=20 >> Maybe I was able to clarify it a bit. It it is clearer for you, I can >> try to integrate some of the above into the ID to make it clearer. >=20 > Well, no. It is no more clear, IMO. And, yes, you should be able to > provide some crisp motivation in the document. It seems to me that > without some actual motivation this should not be taken up. Is it now clearer, that there are situation where * delaying the SACKs hurts for specific packets * only the sender knows for which are these specific packets Best regards Michael >=20 > allman >=20 >=20 >=20 >=20 From mallman@icir.org Thu Aug 25 05:27:08 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFD421F86B3 for ; Thu, 25 Aug 2011 05:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.812 X-Spam-Level: X-Spam-Status: No, score=-105.812 tagged_above=-999 required=5 tests=[AWL=-0.712, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYon+auzWqDt for ; Thu, 25 Aug 2011 05:27:08 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3708A21F86C1 for ; Thu, 25 Aug 2011 05:27:08 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p7PCSB4J011511; Thu, 25 Aug 2011 05:28:11 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 7799058A248; Thu, 25 Aug 2011 08:28:10 -0400 (EDT) To: =?iso-8859-1?Q?Michael_T=FCxen?= From: Mark Allman Subject: Re: Adopting draft-tuexen-tsvwg-sctp-sack-immediately as WG item? In-Reply-To: <585B4D7F-F666-4C4F-8AA4-048CEE19D6DB@lurchi.franken.de> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Werewolves of London X-URL-0: http://www.icir.org/mallman-files/Document23572.html MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma16343-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 25 Aug 2011 08:28:10 -0400 Sender: mallman@icir.org Message-Id: <20110825122810.7799058A248@lawyers.icir.org> Cc: gorry@erg.abdn.ac.uk, tsvwg chair , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 12:27:09 -0000 ----------ma16343-1 Content-Type: text/plain Content-Disposition: inline > > (I can't find the paper ... can you send me a copy?) > I'll send you one in a separate e-mail. (thanks!) > > The I-Bit mitigates what? If you want the receiver to ACK every segment > > then make it do so. I don't quite follow this reasoning at all. > > Delayed ACKs hurt performance, ACK-every helps it. OK. But, what ... ? > > We want to pretend that the receiver does delayed ACKs, but have the > > sender over-rule that notion and turn them on? That doesn't make any > > sense to me. > > The point is that it improves the situation to not delay *some* SACKs. > And only the sender knows which ones are the ones. I might have some sympathy for this approach if you were playing our scenarios where this was clearly the case. But, > Simple example: After a timeout the cwnd = MTU. So you can send > a packet, the peer will delay the SACK, and the sender has to wait > for RTT + SACK.delay to send the next one. You can reduce this > to RTT. > > I'm not saying that this makes a huge difference, but the mechanism we > are talking about is also not very complex... If you're talking about things like "optimizing" the **RTO** (which triggers when the usual loss recovery doesn't work) you'll surely understand why I am skeptical and unimpressed with the motivation, right?! > >>>> o The sender is in the SHUTDOWN-PENDING state. > >>> > >>> I don't recall my SCTP state diagram very well. But, can't the receiver > >>> detect this and switch to an immediately ACKing strategy at that point? > >> No, the receiver doesn't know. > >> When the sender calls close() the sender waits until there is no outstanding > >> data anymore and then sends a SHUTDOWN. So the sender has to wait for the > >> SACK and the receiver has no idea. > > > > OK- fair enough. I'd call this a corner case that nobody would really > > care about. Generally speaking nobody sits around waiting on a > > connection tear-down to move on to their next piece of work. > > It is a matter of resources allocated at the server. If you are > running a server which handles lots of short living (compared to 200 > ms) associations, it can reduce the resources substantially. However, > I agree, this applies only to specific services. We might differ in our definition of "substantially" here. > Let me be more precisely: What I have seen: RTO.min = 50ms, RTO.max = > 200ms on the one side. These values are chosen to fulfill some > failover requirements. If the peer delays the ACK by 200ms, the > pattern could observe was: Send a packet, retransmit it, get a SACK > (with the duplicate TSN listed). The problem comes up whenever RTT + > SACK.delay > RTO.min. > > You pointed out that the sender measuring the RTT will include the > SACK.delay in its measurements. For SCTP this is only partially true. > RTT measurements are done using user data (where it does include the > SACK.delay) and via the heartbeat mechanism (where it does not include > it). > > However, when receiving the SACK with the duplicate report, it can try > to improve the situation. However, the solution of the problem is to > change the configuration of the receiver. Two things: (1) So, to fix the sender's stupidity we're going to introduce not only new machinery, but machinery at both endpoints? I don't think this approach is well thought out. (2) Also, sure, not all RTT samples include the delayed ACK timer. Not all data segments include it either (e.g., the second data segment triggers an immediate ACK and if that is the segment you're timing then you include no delay). TCP has worked this way for a while. We have a variance for such things. > I don't consider this a major reason for introducing the I-Bit. You keep saying such things. What is the major reason? > The pattern which is used is: Wait for sending the next packet until > the peer has acknowledged everything at the transport layer. This seems to be the recurring theme. I.e., we are waiting for an ACK to send something that could otherwise be sent. Well, send it. Why involve the receiver in such situations? > And again: The sender knows for which packets delaying the SACK > hurts. The *application* knows. So, there is more complication here in that the app has to communicate this to SCTP. > It would be an alternative to switch delaying SACK off by default, but > this would result in more packets. So it might help with the delay but > is not optimal in another way. It doesn't seem to me the delay is the problem in the cases you are sketching. It seems the sender's rule for when it is allowed to transmit something are the issue. The bottom line for me is that at the very least you need to actually motivate the mechanism in the document. The current list of motivations is terse and glib. And, I'd suggest you think all this through because it seems to me from your explanations that you're nipping at a symptom of a problem and not addressing the actual problem. IMHO. allman ----------ma16343-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk5WP9oACgkQWyrrWs4yIs6VywCgkUlj+v7jOkLC1u8uMTz8g5Wx n20AnRNawX9xEhQMTn07oJ4KZlMx8BIv =MyBT -----END PGP SIGNATURE----- ----------ma16343-1-- From Michael.Tuexen@lurchi.franken.de Thu Aug 25 06:30:46 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1345721F84D4 for ; Thu, 25 Aug 2011 06:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.532 X-Spam-Level: X-Spam-Status: No, score=-1.532 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqJlh+oRZwmT for ; Thu, 25 Aug 2011 06:30:45 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 864C821F84CB for ; Thu, 25 Aug 2011 06:30:44 -0700 (PDT) Received: from [192.168.1.103] (p5481D3B5.dip.t-dialin.net [84.129.211.181]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 902CD1C0C0BD6; Thu, 25 Aug 2011 15:31:56 +0200 (CEST) Subject: Re: Adopting draft-tuexen-tsvwg-sctp-sack-immediately as WG item? Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <20110825122810.7799058A248@lawyers.icir.org> Date: Thu, 25 Aug 2011 15:31:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <22F4AE7B-23C8-4F32-AB9D-E41484E7A4BC@lurchi.franken.de> References: <20110825122810.7799058A248@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.1084) Cc: gorry@erg.abdn.ac.uk, tsvwg chair , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 13:30:46 -0000 On Aug 25, 2011, at 2:28 PM, Mark Allman wrote: >=20 >>> (I can't find the paper ... can you send me a copy?) >> I'll send you one in a separate e-mail. >=20 > (thanks!) >=20 >>> The I-Bit mitigates what? If you want the receiver to ACK every = segment >>> then make it do so. I don't quite follow this reasoning at all. >>> Delayed ACKs hurt performance, ACK-every helps it. OK. But, what = ... ? >>> We want to pretend that the receiver does delayed ACKs, but have the >>> sender over-rule that notion and turn them on? That doesn't make = any >>> sense to me. >>=20 >> The point is that it improves the situation to not delay *some* = SACKs. >> And only the sender knows which ones are the ones. >=20 > I might have some sympathy for this approach if you were playing our > scenarios where this was clearly the case. But,=20 >=20 >> Simple example: After a timeout the cwnd =3D MTU. So you can send >> a packet, the peer will delay the SACK, and the sender has to wait >> for RTT + SACK.delay to send the next one. You can reduce this >> to RTT. >>=20 >> I'm not saying that this makes a huge difference, but the mechanism = we >> are talking about is also not very complex... >=20 > If you're talking about things like "optimizing" the **RTO** (which > triggers when the usual loss recovery doesn't work) you'll surely > understand why I am skeptical and unimpressed with the motivation, > right?!=20 The above example is not related to any optimization of RTO, it is about the case that the sender has to wait for for an incoming SACK to send the next DATA chunk because the cwnd =3D MTU. >=20 >>>>>> o The sender is in the SHUTDOWN-PENDING state. >>>>>=20 >>>>> I don't recall my SCTP state diagram very well. But, can't the = receiver >>>>> detect this and switch to an immediately ACKing strategy at that = point? >>>> No, the receiver doesn't know. >>>> When the sender calls close() the sender waits until there is no = outstanding >>>> data anymore and then sends a SHUTDOWN. So the sender has to wait = for the >>>> SACK and the receiver has no idea. >>>=20 >>> OK- fair enough. I'd call this a corner case that nobody would = really >>> care about. Generally speaking nobody sits around waiting on a >>> connection tear-down to move on to their next piece of work. >>=20 >> It is a matter of resources allocated at the server. If you are >> running a server which handles lots of short living (compared to 200 >> ms) associations, it can reduce the resources substantially. = However, >> I agree, this applies only to specific services. >=20 > We might differ in our definition of "substantially" here. >=20 >> Let me be more precisely: What I have seen: RTO.min =3D 50ms, RTO.max = =3D >> 200ms on the one side. These values are chosen to fulfill some >> failover requirements. If the peer delays the ACK by 200ms, the >> pattern could observe was: Send a packet, retransmit it, get a SACK >> (with the duplicate TSN listed). The problem comes up whenever RTT + >> SACK.delay > RTO.min. >>=20 >> You pointed out that the sender measuring the RTT will include the >> SACK.delay in its measurements. For SCTP this is only partially true. >> RTT measurements are done using user data (where it does include the >> SACK.delay) and via the heartbeat mechanism (where it does not = include >> it). >>=20 >> However, when receiving the SACK with the duplicate report, it can = try >> to improve the situation. However, the solution of the problem is to >> change the configuration of the receiver. >=20 > Two things: >=20 > (1) So, to fix the sender's stupidity we're going to introduce not = only > new machinery, but machinery at both endpoints? I don't think this > approach is well thought out. Why is the sender stupid if it has been configured with the above values? The problem is that the configuration of the sender and the receiver are not in tune. >=20 > (2) Also, sure, not all RTT samples include the delayed ACK timer. = Not > all data segments include it either (e.g., the second data segment > triggers an immediate ACK and if that is the segment you're timing > then you include no delay). TCP has worked this way for a while. > We have a variance for such things. >=20 >> I don't consider this a major reason for introducing the I-Bit.=20 >=20 > You keep saying such things. What is the major reason? >=20 >> The pattern which is used is: Wait for sending the next packet until >> the peer has acknowledged everything at the transport layer. >=20 > This seems to be the recurring theme. I.e., we are waiting for an ACK > to send something that could otherwise be sent. Well, send it. Why > involve the receiver in such situations? I can't, because it would break the application protocol. But may be I'm overlooking something and you can suggest how I can enforce some ordering over *all* streams without using the SENDER_DRY_EVENT. >=20 >> And again: The sender knows for which packets delaying the SACK >> hurts. >=20 > The *application* knows. So, there is more complication here in that > the app has to communicate this to SCTP. No problem. It uses the SCTP_SACK_IMMEDIATELY flag in the send call. This is implemented in FreeBSD and Linux and described in section 6. >=20 >> It would be an alternative to switch delaying SACK off by default, = but >> this would result in more packets. So it might help with the delay = but >> is not optimal in another way. >=20 > It doesn't seem to me the delay is the problem in the cases you are > sketching. It seems the sender's rule for when it is allowed to > transmit something are the issue. For Nagle interaction: yes. For the association teeardown: no. For the application protocol interaction: I don't know an alternative. That doesn't mean that there is any, but for me this is the main motivation. This problem comes up when you move application protocols running over TCP to SCTP, because they would benefit from multiple streams. Often, you can decouple traffic streams for most of the time, but at specific times, everything has to be synchronized over all streams. Without changing the application protocol (by adding an app level ack), the sender waits for all TSNs to be cum acked, and the receiver has to process all messages. This is normally sender driven. Examples are DTLS and SSH. The times where you need to sync everything are the ones where you do some sort of rekeying. >=20 > The bottom line for me is that at the very least you need to actually > motivate the mechanism in the document. The current list of = motivations > is terse and glib. And, I'd suggest you think all this through = because > it seems to me from your explanations that you're nipping at a symptom > of a problem and not addressing the actual problem. IMHO. I agree that the motivations are not very detailed. This is why you also have only MAYs on the sending side.=20 The crucial point is that the receiver * either ignores the I-Bit (because he isn't implementing it) * or sends a SACK back. As said above, this is implemented in Linux and FreeBSD. The most important usage scenario is the app driven thing. Depending on the service you run a server, the SHUTDOWN thing might be important. But it really depends on the server and is only related to resources. So: Can you come up with a synchronization method which does not use the SENDER_DRY_EVENT? Then one could argue to not use the I-Bit. Except for the case that implementations are out and it would be really bad if the bit will be used from something different in the future. Best regards Michael >=20 > allman >=20 >=20 >=20 From mallman@icir.org Thu Aug 25 12:12:11 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A48921F881C for ; Thu, 25 Aug 2011 12:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.669 X-Spam-Level: X-Spam-Status: No, score=-105.669 tagged_above=-999 required=5 tests=[AWL=-0.570, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgwsFC1JJNJH for ; Thu, 25 Aug 2011 12:12:10 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5698721F86AF for ; Thu, 25 Aug 2011 12:12:10 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p7PJDAuV002762; Thu, 25 Aug 2011 12:13:11 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id BEC1D59403B; Thu, 25 Aug 2011 15:06:19 -0400 (EDT) To: =?iso-8859-1?Q?Michael_T=FCxen?= From: Mark Allman Subject: Re: Adopting draft-tuexen-tsvwg-sctp-sack-immediately as WG item? In-Reply-To: <22F4AE7B-23C8-4F32-AB9D-E41484E7A4BC@lurchi.franken.de> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Big Bang Baby X-URL-0: http://www.icir.org/mallman-files/Document94668.jpg X-URL-1: http://www.icir.org/mallman-files/Document38496.pdf X-URL-2: http://www.icir.org/mallman-files/Document37726.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma40234-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 25 Aug 2011 15:06:19 -0400 Sender: mallman@icir.org Message-Id: <20110825190619.BEC1D59403B@lawyers.icir.org> Cc: gorry@erg.abdn.ac.uk, tsvwg chair , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 19:12:11 -0000 ----------ma40234-1 Content-Type: text/plain Content-Disposition: inline > >> Simple example: After a timeout the cwnd = MTU. So you can send > >> a packet, the peer will delay the SACK, and the sender has to wait > >> for RTT + SACK.delay to send the next one. You can reduce this > >> to RTT. > >> > >> I'm not saying that this makes a huge difference, but the mechanism we > >> are talking about is also not very complex... > > > > If you're talking about things like "optimizing" the **RTO** (which > > triggers when the usual loss recovery doesn't work) you'll surely > > understand why I am skeptical and unimpressed with the motivation, > > right?! > > The above example is not related to any optimization of RTO, it is > about the case that the sender has to wait for for an incoming SACK to > send the next DATA chunk because the cwnd = MTU. I was careless. I understand you are not optimizing the estimator. But, you're trying to optimize the *process* of retransmitting via timeout. I don't find that compelling. > >> Let me be more precisely: What I have seen: RTO.min = 50ms, RTO.max = > >> 200ms on the one side. These values are chosen to fulfill some > >> failover requirements. If the peer delays the ACK by 200ms, the > >> pattern could observe was: Send a packet, retransmit it, get a SACK > >> (with the duplicate TSN listed). The problem comes up whenever RTT + > >> SACK.delay > RTO.min. > >> > >> You pointed out that the sender measuring the RTT will include the > >> SACK.delay in its measurements. For SCTP this is only partially true. > >> RTT measurements are done using user data (where it does include the > >> SACK.delay) and via the heartbeat mechanism (where it does not include > >> it). > >> > >> However, when receiving the SACK with the duplicate report, it can try > >> to improve the situation. However, the solution of the problem is to > >> change the configuration of the receiver. > > > > Two things: > > > > (1) So, to fix the sender's stupidity we're going to introduce not only > > new machinery, but machinery at both endpoints? I don't think this > > approach is well thought out. > > Why is the sender stupid if it has been configured with the above > values? The problem is that the configuration of the sender and the > receiver are not in tune. Thank you for making my point. The sender has whacked things down far enough that it is out of whack with the way a receiver works. That seems stupid to me. > >> The pattern which is used is: Wait for sending the next packet until > >> the peer has acknowledged everything at the transport layer. > > > > This seems to be the recurring theme. I.e., we are waiting for an ACK > > to send something that could otherwise be sent. Well, send it. Why > > involve the receiver in such situations? > > I can't, because it would break the application protocol. But may be > I'm overlooking something and you can suggest how I can enforce some > ordering over *all* streams without using the SENDER_DRY_EVENT. I had to go back and re-read. I mis-understood what you were saying. I see your point here. I guess. I am not entirely sure I understand how this is not a problem you created with the multiplexing. But, I'll certainly agree that I don't quite understand the DTLS process here. > > The bottom line for me is that at the very least you need to actually > > motivate the mechanism in the document. The current list of motivations > > is terse and glib. And, I'd suggest you think all this through because > > it seems to me from your explanations that you're nipping at a symptom > > of a problem and not addressing the actual problem. IMHO. > > I agree that the motivations are not very detailed. This is why you > also have only MAYs on the sending side. > The crucial point is that the receiver > * either ignores the I-Bit (because he isn't implementing it) > * or sends a SACK back. > As said above, this is implemented in Linux and FreeBSD. > > The most important usage scenario is the app driven thing. > Depending on the service you run a server, the SHUTDOWN thing > might be important. But it really depends on the server and > is only related to resources. I don't think it is too much to ask you to develop the motivation crisply in the document (and moreso *before* you think something should be adopted by the WG). > Then one could argue to not use the I-Bit. Except for the case > that implementations are out and it would be really bad if the > bit will be used from something different in the future. Well, bluntly, that is stupid. I could implement a lot of bad ideas and use the "its implemented" excuse to ram it through the standards process? Give me a break. (I mean, I know full well that works sometimes, but its still stupid.) The question came up as to whether the WG should take this or not. If the WG does not and some implementation subsequently gets confused thats its own problem as far as I am concerned. allman ----------ma40234-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk5WnSsACgkQWyrrWs4yIs77egCfXypivCM2hBKSG3D4ig64Eu6+ OsMAoIGwYGBE3I9DOdhe9vOu8sZxfKTa =1F9X -----END PGP SIGNATURE----- ----------ma40234-1-- From Michael.Tuexen@lurchi.franken.de Fri Aug 26 04:59:57 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3759C21F8B33 for ; Fri, 26 Aug 2011 04:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[AWL=-0.390, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HleDS+pBas95 for ; Fri, 26 Aug 2011 04:59:56 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id B4E9D21F8B00 for ; Fri, 26 Aug 2011 04:59:55 -0700 (PDT) Received: from [192.168.1.103] (p5481D39F.dip.t-dialin.net [84.129.211.159]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 284561C0B4619; Fri, 26 Aug 2011 14:00:54 +0200 (CEST) Subject: Re: Adopting draft-tuexen-tsvwg-sctp-sack-immediately as WG item? Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <20110825190619.BEC1D59403B@lawyers.icir.org> Date: Fri, 26 Aug 2011 14:00:53 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <20110825190619.BEC1D59403B@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.1084) Cc: gorry@erg.abdn.ac.uk, tsvwg chair , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 11:59:57 -0000 On Aug 25, 2011, at 9:06 PM, Mark Allman wrote: > >>>> Simple example: After a timeout the cwnd = MTU. So you can send >>>> a packet, the peer will delay the SACK, and the sender has to wait >>>> for RTT + SACK.delay to send the next one. You can reduce this >>>> to RTT. >>>> >>>> I'm not saying that this makes a huge difference, but the mechanism we >>>> are talking about is also not very complex... >>> >>> If you're talking about things like "optimizing" the **RTO** (which >>> triggers when the usual loss recovery doesn't work) you'll surely >>> understand why I am skeptical and unimpressed with the motivation, >>> right?! >> >> The above example is not related to any optimization of RTO, it is >> about the case that the sender has to wait for for an incoming SACK to >> send the next DATA chunk because the cwnd = MTU. > > I was careless. I understand you are not optimizing the estimator. > But, you're trying to optimize the *process* of retransmitting via > timeout. I don't find that compelling. I want to say that there are situations in which only the senders knows that not delaying the SACK helps to improve the protocol behavior. I do not think the we need an exhaustive list in the ID... > >>>> Let me be more precisely: What I have seen: RTO.min = 50ms, RTO.max = >>>> 200ms on the one side. These values are chosen to fulfill some >>>> failover requirements. If the peer delays the ACK by 200ms, the >>>> pattern could observe was: Send a packet, retransmit it, get a SACK >>>> (with the duplicate TSN listed). The problem comes up whenever RTT + >>>> SACK.delay > RTO.min. >>>> >>>> You pointed out that the sender measuring the RTT will include the >>>> SACK.delay in its measurements. For SCTP this is only partially true. >>>> RTT measurements are done using user data (where it does include the >>>> SACK.delay) and via the heartbeat mechanism (where it does not include >>>> it). >>>> >>>> However, when receiving the SACK with the duplicate report, it can try >>>> to improve the situation. However, the solution of the problem is to >>>> change the configuration of the receiver. >>> >>> Two things: >>> >>> (1) So, to fix the sender's stupidity we're going to introduce not only >>> new machinery, but machinery at both endpoints? I don't think this >>> approach is well thought out. >> >> Why is the sender stupid if it has been configured with the above >> values? The problem is that the configuration of the sender and the >> receiver are not in tune. > > Thank you for making my point. The sender has whacked things down far > enough that it is out of whack with the way a receiver works. That > seems stupid to me. The point here is that the values used by the sender are the correct ones (used in some cases for SIGTRAN setups). So it is not stupid that the sender has been configured that way. The problem is the misconfiguration of the receiver. But the sender has no way to change that. You might argue that the sender can change its RTO values to behave well with the receiver. The problem is that the setup can not fulfill the failover requirements for SIGTRAN. That is why the sender is configured that way. Again: The real solution is to configure the receiver correctly. I think we agree on this. My point is only: The sender can not change the config of the receiver (at not by any protocol mechanism / socket API functionality I'm aware of), it can only mitigate the consequences of the misconfiguration. > >>>> The pattern which is used is: Wait for sending the next packet until >>>> the peer has acknowledged everything at the transport layer. >>> >>> This seems to be the recurring theme. I.e., we are waiting for an ACK >>> to send something that could otherwise be sent. Well, send it. Why >>> involve the receiver in such situations? >> >> I can't, because it would break the application protocol. But may be >> I'm overlooking something and you can suggest how I can enforce some >> ordering over *all* streams without using the SENDER_DRY_EVENT. > > I had to go back and re-read. I mis-understood what you were saying. I > see your point here. I guess. I am not entirely sure I understand how > this is not a problem you created with the multiplexing. But, I'll The only way to avoid this is to keep everything in sequence always. But this means not using multiple streams. The DTLS spec allows the DTLS layer to reorder packets to some degree, but throws away packets being too late (either time based after an change of the epoch or numbering based). Since SCTP provides a reliable transport, we have to avoid that the DTLS layer throws away the messages. So yes, the problem is a consequence of using multiple streams. The alternatives: (a) Don't use multiple streams. (b) Use a DTLS connection per bi-directional stream, similar to what http://tools.ietf.org/html/rfc3436 does. We did not choose (a) because we wanted to support multiple streams. The problem with (b) is the same as with the solution described in RFC 3436: Scalability. Setting up a single SCTP association with N bidirectional streams requires setting up N (D)TLS connections, which is (in my sense) a substantial overhead (message wise, CPU resources wise). So if you agree that we should neither do (a) nor (b), you need to suggest a better way to enforce some sequencing constraints, which cover messages from all streams. We made use of the TSN, which numbers all SCTP data chunks. Again: I'm not able to come up with a better solution, but that does not mean that there is nothing better. > certainly agree that I don't quite understand the DTLS process here. > >>> The bottom line for me is that at the very least you need to actually >>> motivate the mechanism in the document. The current list of motivations >>> is terse and glib. And, I'd suggest you think all this through because >>> it seems to me from your explanations that you're nipping at a symptom >>> of a problem and not addressing the actual problem. IMHO. >> >> I agree that the motivations are not very detailed. This is why you >> also have only MAYs on the sending side. >> The crucial point is that the receiver >> * either ignores the I-Bit (because he isn't implementing it) >> * or sends a SACK back. >> As said above, this is implemented in Linux and FreeBSD. >> >> The most important usage scenario is the app driven thing. >> Depending on the service you run a server, the SHUTDOWN thing >> might be important. But it really depends on the server and >> is only related to resources. > > I don't think it is too much to ask you to develop the motivation > crisply in the document (and moreso *before* you think something should > be adopted by the WG). Section 4 lists situations in which you might want to set the I-Bit. I can take out the reason related to the Nagle algorithm since it is much better to improve the Nagle algorithm. Not sure if I would use the I-Bit if it is available on a platform, but the Nagle code does not handle the stuff itself. This is the case with current versions of FreeBSD, not sure about Linux. I can add a section which describes somewhat more detailed what is listed in section 4.1, if that helps. However, I'm not sure if you either want more text describing what is listed in section 4.1 or think adding a flag which makes it possible for the sender to request a SACK to be sent back immediately is an idea which is stupid/bad/worthless/whatever. > >> Then one could argue to not use the I-Bit. Except for the case >> that implementations are out and it would be really bad if the >> bit will be used from something different in the future. > > Well, bluntly, that is stupid. I could implement a lot of bad ideas and > use the "its implemented" excuse to ram it through the standards Hmm. I don't think adding the I-bit is a bad idea. Actually I think it should have been there right from the beginning. But I can be wrong. > process? Give me a break. (I mean, I know full well that works > sometimes, but its still stupid.) The question came up as to whether > the WG should take this or not. If the WG does not and some > implementation subsequently gets confused thats its own problem as far > as I am concerned. I'm concerned about interoperability of the major Unix based implementations. However, it is up to the working group to decided if it is interested in the work or not. Whether or not the working group takes into account if the functionality is available in current versions of OSes is also up to the WG. But I wanted to make sure that it is known that it has been implemented and released. That's why I can make a statement about complexity (based on the FreeBSD implementation). Best regards Michael > > allman > > > From bidulock@openss7.org Fri Aug 26 20:26:45 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E12A21F886A for ; Fri, 26 Aug 2011 20:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[AWL=-0.641, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jlrzf6klRgUV for ; Fri, 26 Aug 2011 20:26:44 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.117.178]) by ietfa.amsl.com (Postfix) with ESMTP id 20CED21F8785 for ; Fri, 26 Aug 2011 20:26:43 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p7R3RhU4003970; Fri, 26 Aug 2011 21:27:43 -0600 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p7R3Rgr8015488; Fri, 26 Aug 2011 21:27:42 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p7R3ReJm015482; Fri, 26 Aug 2011 21:27:40 -0600 Date: Fri, 26 Aug 2011 21:27:40 -0600 From: "Brian F. G. Bidulock" To: Michael =?iso-8859-1?Q?T=FCxen?= Subject: Re: Adopting draft-tuexen-tsvwg-sctp-sack-immediately as WG item? Message-ID: <20110827032740.GA13580@openss7.org> Mail-Followup-To: Michael =?iso-8859-1?Q?T=FCxen?= , mallman@icir.org, gorry@erg.abdn.ac.uk, tsvwg chair , tsvwg@ietf.org References: <20110825190619.BEC1D59403B@lawyers.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: gorry@erg.abdn.ac.uk, tsvwg chair , tsvwg@ietf.org, mallman@icir.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 03:26:45 -0000 Michael, Michael Tüxen wrote: (Fri, 26 Aug 2011 14:00:53) > > Thank you for making my point. The sender has whacked things down far > > enough that it is out of whack with the way a receiver works. That > > seems stupid to me. > The point here is that the values used by the sender are the correct > ones (used in some cases for SIGTRAN setups). So it is not stupid > that the sender has been configured that way. The problem is the > misconfiguration of the receiver. But the sender has no way to change > that. > You might argue that the sender can change its RTO values to behave > well with the receiver. The problem is that the setup can not fulfill > the failover requirements for SIGTRAN. That is why the sender is configured > that way. > > Again: The real solution is to configure the receiver correctly. I think > we agree on this. My point is only: The sender can not change the config > of the receiver (at not by any protocol mechanism / socket API > functionality I'm aware of), it can only mitigate the consequences > of the misconfiguration. I agree with Mark, RTO.max < 200ms without setting SACK.delay at the peer (even to zero) is plain stupid, even for SIGTRAN. Also, there is no need for a per-message SACK immediately mechanism in such a case. At most a mechanism to negotiate maximum SACK.delay on association establishment. Also, it would be better to negotiate the SACK.delay to lower than 200ms, but not to zero. Also, for most SIGTRAN applications, SACK.delay is not often a consideration as many messages are sent back-to-back in a continuous stream and a SACK will be sent every second DATA chunk without SACK.delay expiring at all. It is highly unlikely that even a 50ms quiet period will occur in practice, and the odd suprious retransmission that would result is not a issue. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From Michael.Tuexen@lurchi.franken.de Sat Aug 27 03:23:51 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85CD421F88B6 for ; Sat, 27 Aug 2011 03:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.454 X-Spam-Level: X-Spam-Status: No, score=-1.454 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2W9ms1cU+kWR for ; Sat, 27 Aug 2011 03:23:50 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id ECBAC21F8A58 for ; Sat, 27 Aug 2011 03:23:49 -0700 (PDT) Received: from [192.168.1.103] (p5481B092.dip.t-dialin.net [84.129.176.146]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 981C41C0B4617; Sat, 27 Aug 2011 12:25:05 +0200 (CEST) Subject: Re: Adopting draft-tuexen-tsvwg-sctp-sack-immediately as WG item? Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <20110827032740.GA13580@openss7.org> Date: Sat, 27 Aug 2011 12:25:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <41B08FA9-55B3-4C7E-BE08-2CCD0F418B9B@lurchi.franken.de> References: <20110825190619.BEC1D59403B@lawyers.icir.org> <20110827032740.GA13580@openss7.org> To: bidulock@openss7.org X-Mailer: Apple Mail (2.1084) Cc: gorry@erg.abdn.ac.uk, tsvwg chair , tsvwg@ietf.org, mallman@icir.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 10:23:51 -0000 On Aug 27, 2011, at 5:27 AM, Brian F. G. Bidulock wrote: > Michael, >=20 > Michael T=FCxen wrote: = (Fri, 26 Aug 2011 14:00:53) >>> Thank you for making my point. The sender has whacked things down = far >>> enough that it is out of whack with the way a receiver works. That >>> seems stupid to me. >> The point here is that the values used by the sender are the correct >> ones (used in some cases for SIGTRAN setups). So it is not stupid >> that the sender has been configured that way. The problem is the >> misconfiguration of the receiver. But the sender has no way to change >> that. >> You might argue that the sender can change its RTO values to behave >> well with the receiver. The problem is that the setup can not fulfill >> the failover requirements for SIGTRAN. That is why the sender is = configured >> that way. >>=20 >> Again: The real solution is to configure the receiver correctly. I = think >> we agree on this. My point is only: The sender can not change the = config >> of the receiver (at not by any protocol mechanism / socket API >> functionality I'm aware of), it can only mitigate the consequences >> of the misconfiguration. >=20 > I agree with Mark, RTO.max < 200ms without setting SACK.delay at the > peer (even to zero) is plain stupid, even for SIGTRAN. As said earlier: It is a mis-configuration. The solution to it is the reconfigure the receiver. My only point was that there is currently no way for the sender to change the SACK.delay of the receiver. >=20 > Also, there is no need for a per-message SACK immediately mechanism in > such a case. I don't think that mitigating the consequences is the reason why you want to introduce the I-bit. I just wanted to say, that, if you have it, you can use it to mitigate the consequences. However, there would be no need to do it per-message base, you would set it on all DATA chunks. >=20 > At most a mechanism to negotiate maximum SACK.delay on association > establishment. Also, it would be better to negotiate the SACK.delay > to lower than 200ms, but not to zero. That would be a solution. >=20 > Also, for most SIGTRAN applications, SACK.delay is not often a > consideration as many messages are sent back-to-back in a continuous > stream and a SACK will be sent every second DATA chunk without > SACK.delay expiring at all. It is highly unlikely that even a 50ms > quiet period will occur in practice, and the odd suprious = retransmission > that would result is not a issue. It depends on the upper layer and the service provided. However, I think considering this mis-configuration case adds more confusion than the use of the I-bit on that case might help. I'll remove it in the next rev. of the ID. Best regards Michael >=20 >=20 > --brian >=20 > --=20 > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ >=20 From wwwrun@rfc-editor.org Wed Aug 31 10:11:44 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0332321F85B5; Wed, 31 Aug 2011 10:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bM+xB5UE9Jin; Wed, 31 Aug 2011 10:11:43 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAAA21F8C3D; Wed, 31 Aug 2011 10:11:43 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 532D298C25C; Wed, 31 Aug 2011 10:12:53 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: BCP 165, RFC 6335 on Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry From: rfc-editor@rfc-editor.org Message-Id: <20110831171253.532D298C25C@rfc-editor.org> Date: Wed, 31 Aug 2011 10:12:53 -0700 (PDT) Cc: tsvwg@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 17:11:44 -0000 A new Request for Comments is now available in online RFC libraries. BCP 165 RFC 6335 Title: Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry Author: M. Cotton, L. Eggert, J. Touch, M. Westerlund, S. Cheshire Status: Best Current Practice Stream: IETF Date: August 2011 Mailbox: michelle.cotton@icann.org, lars.eggert@nokia.com, touch@isi.edu, magnus.westerlund@ericsson.com, cheshire@apple.com Pages: 33 Characters: 79088 Updates: RFC2780, RFC2782, RFC3828, RFC4340, RFC4960, RFC5595 See Also: BCP0165 I-D Tag: draft-ietf-tsvwg-iana-ports-10.txt URL: http://www.rfc-editor.org/rfc/rfc6335.txt This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry. This document updates IANA's procedures by obsoleting the previous UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and port assignment procedures for UDP-Lite, the Datagram Congestion Control Protocol (DCCP), and the Stream Control Transmission Protocol (SCTP). It also updates the DNS SRV specification to clarify what a service name is and how it is registered. This memo documents an Internet Best Current Practice. This document is a product of the Transport Area Working Group Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC