From mailnull@www1.ietf.org Wed Apr 2 11:14:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15435 for ; Wed, 2 Apr 2003 11:14:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32Gcvw22081 for tsvwg-archive@odin.ietf.org; Wed, 2 Apr 2003 11:38:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32GcUK22035; Wed, 2 Apr 2003 11:38:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32GbJK21540 for ; Wed, 2 Apr 2003 11:37:20 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15320 for ; Wed, 2 Apr 2003 11:12:31 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h32GIu516004 for ; Wed, 2 Apr 2003 19:18:56 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 2 Apr 2003 19:14:57 +0300 Received: from danh02-nrcws56.americas.nokia.com ([172.19.62.56]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 2 Apr 2003 19:14:56 +0300 From: Yogesh Prem Swami To: tsvwg@ietf.org Content-Type: text/plain Organization: Nokia Research Center, Dallas Message-Id: <1049300095.2394.20.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 02 Apr 2003 10:14:55 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Apr 2003 16:14:57.0386 (UTC) FILETIME=[00EB3CA0:01C2F933] Content-Transfer-Encoding: 7bit Subject: [Tsvwg] DCLOR draft update Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Folks, An update for DCLOR is now available from http://www.ietf.org/internet-drafts/draft-swami-tsvwg-tcp-dclor-01.txt Since we have decoupled the problem of spurious timeout from subnet change using the LMDR draft, we no longer require the sender to go to INIT_WINDOW after a spurious timeout. This draft halves the congestion every RTO. Please provide your feedback. Thanks Yogesh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 2 12:54:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20542 for ; Wed, 2 Apr 2003 12:54:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32IJ2J32028 for tsvwg-archive@odin.ietf.org; Wed, 2 Apr 2003 13:19:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32IIeK31987; Wed, 2 Apr 2003 13:18:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32IHeK31909 for ; Wed, 2 Apr 2003 13:17:40 -0500 Received: from seraph3.grc.nasa.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20484 for ; Wed, 2 Apr 2003 12:52:50 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id D8FDB6B9EC for ; Wed, 2 Apr 2003 12:55:17 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h32HtHKV023869 for ; Wed, 2 Apr 2003 12:55:17 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id MAA19985; Wed, 2 Apr 2003 12:55:17 -0500 (EST) Message-Id: <200304021755.MAA19985@guns.lerc.nasa.gov> To: tsvwg@ietf.org From: Mark Allman Reply-To: mallman@grc.nasa.gov Organization: BBN Technologies/NASA GRC Song-of-the-Day: Just What I Needed Date: Wed, 02 Apr 2003 12:55:17 -0500 Subject: [Tsvwg] pr-sctp Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , In SF I agreed to more beating on PR-SCTP via the mailing list. So... In SF Reiner showed a few slides that basically asked the question: How much "extra" (unnecessary) traffic is acceptable to send? TCP naturally sends some. The coding in some of the RTP protocols constitutes more than the minimum bits required to send. Etc. I have thoughts on that subject, but that is not what this email is about. My point to Randall about PR-SCTP was: should we be thinking about PR-SCTP in the context of thinking about the points that Reiner raised? That is, with PR-SCTP you are sending things into the network that are then (potentially) not used at the other end. My question was/is: If I send some segment X into the network, then detect that it was lost, but also then decide that I don't care if X makes it (so, I send an F-TSN), should that count against this "junk data" counter that Reiner was alluding to? There are two angles... * Phil Conrad and David Black rightly beat me and said something like ... but, PR-SCTP is helping you in this case because you won't *keep* sending this data that is useless. And, that is true. (Although, we know we have sent useless data some number of times.) * But, another question is whether we are providing an incentive for apps to dump things into the network quickly because they can then "supercede" them if necessary. So, the tradeoff might be for the app to be a bit more careful and thoughtful about what is sent versus being quick and careless. Are we providing a mechanism for apps to be more careless about sending data into the network? And, if we are, then I think that thinking about some govenor on PR-SCTP in the context of Reiner's thought might be something to consider. I hope that is a bit more clear. It still may be erroneous thinking ... (so, am I shooting for "clearly erroneous" ... hmmm :). Thoughts? allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 2 15:15:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05672 for ; Wed, 2 Apr 2003 15:15:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32KeLR14328 for tsvwg-archive@odin.ietf.org; Wed, 2 Apr 2003 15:40:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32KdrK14261; Wed, 2 Apr 2003 15:39:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32Kc4K14165 for ; Wed, 2 Apr 2003 15:38:04 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02717 for ; Wed, 2 Apr 2003 15:13:09 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h32KFZ4c022245; Wed, 2 Apr 2003 12:15:35 -0800 (PST) Received: from MRAMALHO-W2K1.cisco.com (dhcp-64-100-135-217.cisco.com [64.100.135.217]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ACW12500; Wed, 2 Apr 2003 12:15:34 -0800 (PST) Message-Id: <4.3.2.7.2.20030402142907.01641590@mira-sjc5-9.cisco.com> X-Sender: mramalho@mira-sjc5-9.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 02 Apr 2003 15:15:33 -0500 To: mallman@grc.nasa.gov, tsvwg@ietf.org From: "Michael A. Ramalho" Subject: Re: [Tsvwg] pr-sctp In-Reply-To: <200304021755.MAA19985@guns.lerc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Mark, I think you have phrased the issues correctly and presented a cohesive story. A comment below on the "second angle". Michael Ramalho At 12:55 PM 4/2/2003 -0500, Mark Allman wrote: > >In SF I agreed to more beating on PR-SCTP via the mailing list. >So... > >In SF Reiner showed a few slides that basically asked the question: >How much "extra" (unnecessary) traffic is acceptable to send? TCP >naturally sends some. The coding in some of the RTP protocols >constitutes more than the minimum bits required to send. Etc. I >have thoughts on that subject, but that is not what this email is >about. > >My point to Randall about PR-SCTP was: should we be thinking about >PR-SCTP in the context of thinking about the points that Reiner >raised? That is, with PR-SCTP you are sending things into the >network that are then (potentially) not used at the other end. My >question was/is: If I send some segment X into the network, then >detect that it was lost, but also then decide that I don't care if X >makes it (so, I send an F-TSN), should that count against this "junk >data" counter that Reiner was alluding to? There are two angles... > > * Phil Conrad and David Black rightly beat me and said something > like ... but, PR-SCTP is helping you in this case because you > won't *keep* sending this data that is useless. And, that is > true. (Although, we know we have sent useless data some number > of times.) [The "useless data" might not be "useless" if it arrived in a timely manner.] You've basically got this point, though. But to be emphatic .... under congestion this is exactly the behavior you want. This is because every bit of information you send that the receiver can't profitably use (because it is stale) is information that is sent *before more useful information*. Therefore the process of re-sending stale information is *delaying* the sending of useful information (potentially making it stale also ... under extended congestion episodes). Thus the setting of the lifetime parameter of the "timed reliability" example in the pr-SCTP draft should be tuned to the application's definition/knowledge of "staleness". I agree that this adds a degree of definition difficulty in metrics like "goodput". Is it good only if it is not stale? Clearly "goodput" defined in such a manner is dependent on the application's definition of "staleness/goodness" and the congestion condition at the time of measurement/simulation. Note: The congestion condition is not simply characterized by loss .... but additionally by duration (in time) of the congestion event (as this has an effect on "staleness"). We need to consider the time/delay element in the congestion episode. > * But, another question is whether we are providing an incentive > for apps to dump things into the network quickly because they > can then "supercede" them if necessary. So, the tradeoff might > be for the app to be a bit more careful and thoughtful about > what is sent versus being quick and careless. One could argue that if transmission bandwidth and app processing power is almost always plentiful, the "quick and careless" approach is OK. But, I'd suggest that making app designers communicate to a PR-SCTP Service Definitions such as "timed reliability" is, in itself, making the app designer think about such things .... and creates an environment whereby the app designer is forced to think about how they desire the app to perform under less-than-ideal operating conditions (like congestion episodes, routing changes that result in much larger nominal delays or high packet loss). Thus, I happen to believe that we are providing an incentive for app designers *not* be careless ... but rather to think about overload/congestion scenarios. >Are we providing > a mechanism for apps to be more careless about sending data into > the network? And, if we are, then I think that thinking about > some govenor on PR-SCTP in the context of Reiner's thought might > be something to consider. In this thought process we might consider other PR-SCTP service definitions that are more appropriate to the applications to consider under overload or congestion scenarios. The creation of other pr-sctp service definition to help "govern" the sending of data would be welcome. However, the F-TSN mechanism is the only thing required "on the wire" for PR-SCTP. >I hope that is a bit more clear. It still may be erroneous thinking >... (so, am I shooting for "clearly erroneous" ... hmmm :). > >Thoughts? > >allman > > >-- >Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg Michael A. Ramalho, Ph.D. Office email: mramalho@cisco.com Personal email: mar42@cornell.edu Office: +1.941.708.4650 Cell: +1.941.544.2844 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 2 18:37:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15781 for ; Wed, 2 Apr 2003 18:37:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32Ndlk01071 for tsvwg-archive@odin.ietf.org; Wed, 2 Apr 2003 18:39:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32NdEK01050; Wed, 2 Apr 2003 18:39:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32NcmK01023 for ; Wed, 2 Apr 2003 18:38:48 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15758 for ; Wed, 2 Apr 2003 18:36:18 -0500 (EST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 41E1332977; Wed, 2 Apr 2003 18:38:46 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 6EB24328AE; Wed, 2 Apr 2003 18:38:45 -0500 (EST) Date: Wed, 2 Apr 2003 18:38:45 -0500 (EST) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: "Michael A. Ramalho" Cc: , Subject: Re: [Tsvwg] pr-sctp In-Reply-To: <4.3.2.7.2.20030402142907.01641590@mira-sjc5-9.cisco.com> Message-ID: X-Spam-Status: No, hits=-5.0 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Wed, 2 Apr 2003, Michael A. Ramalho wrote: > But to be emphatic .... under congestion this is exactly the behavior you want. > This is because every bit of information you send that the receiver can't > profitably > use (because it is stale) is information that is sent *before more useful > information*. > Therefore the process of re-sending stale information is *delaying* the > sending of > useful information (potentially making it stale also ... under extended > congestion > episodes). I agree with the concept of PR-SCTP. I want to emphasize that bundling FTSNs with data should be done whenever possible. I think that sending a FTSN in a packet of its own is not much better than re-sending the stale data. Both will be triggered at the same point. Both will take the same time to reach the receiver. And if lost, both suffer the same consequences. The only improvement is that flightsize gets reduced and new data may be sent. Section 3.5 F2) emphasizes that bundling should be done, but just wondering out loud... should PR-SCTP implementations reserve room for FTSNs in all packets. If data chunks are not fragmented properly when queued, then SCTP cannot refragment them later when bundling is needed. The draft says that a sender MAY wait to bundle FTSNs, but is this wording loose enough to allow SCTP to wait for newly queued data to bundle with. In other words, data already queued may be fragmented too large for bundling, but newly queued data may be fragmented small enough for bundling. ...I don't think I like this idea. Maybe simply reserving room for some minimum FTSN size is good enough. > Note: The congestion condition is not simply characterized by loss .... but > additionally by duration (in time) of the congestion event (as this has an > effect on "staleness"). We need to consider the time/delay element in > the congestion episode. I don't follow how this relates to FTSNs. > In this thought process we might consider other PR-SCTP service definitions > that are more appropriate to the applications to consider under > overload or congestion scenarios. The creation of other pr-sctp service > definition > to help "govern" the sending of data would be welcome. However, the F-TSN > mechanism is the only thing required "on the wire" for PR-SCTP. I like that the PR-SCTP mechanism is independent of the service definition. However, I cannot think of applications that could use anything but timed-reliability. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 2 23:33:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23988 for ; Wed, 2 Apr 2003 23:33:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h334VuY23317 for tsvwg-archive@odin.ietf.org; Wed, 2 Apr 2003 23:31:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h334SCK23148; Wed, 2 Apr 2003 23:28:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h334RYK23101 for ; Wed, 2 Apr 2003 23:27:34 -0500 Received: from pop-2.dnv.wideopenwest.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23916 for ; Wed, 2 Apr 2003 23:24:57 -0500 (EST) Received: from thoth.ir.bbn.com (d53-66-209.clv.wideopenwest.com [64.53.209.66]) by pop-2.dnv.wideopenwest.com (8.11.6/8.11.6) with ESMTP id h334aRF13650; Wed, 2 Apr 2003 22:36:27 -0600 Received: from thoth.ir.bbn.com (localhost [127.0.0.1]) by thoth.ir.bbn.com (8.12.6p2/8.12.6) with ESMTP id h334ZZBG032201; Wed, 2 Apr 2003 23:35:35 -0500 (EST) (envelope-from mallman@thoth.ir.bbn.com) Message-Id: <200304030435.h334ZZBG032201@thoth.ir.bbn.com> To: "Michael A. Ramalho" From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: tsvwg@ietf.org Subject: Re: [Tsvwg] pr-sctp In-Reply-To: <4.3.2.7.2.20030402142907.01641590@mira-sjc5-9.cisco.com> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Just What I Needed Date: Wed, 02 Apr 2003 23:35:35 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Michael- > > * Phil Conrad and David Black rightly beat me and said something > > like ... but, PR-SCTP is helping you in this case because you > > won't *keep* sending this data that is useless. And, that is > > true. (Although, we know we have sent useless data some number > > of times.) > > [The "useless data" might not be "useless" if it arrived in a > timely manner.] (but, if it did then we'd not need to issue an f-tsn for it, either) > But to be emphatic .... under congestion this is exactly the > behavior you want. This is because every bit of information you > send that the receiver can't profitably use (because it is stale) > is information that is sent *before more useful information*. (assuming an endless supply of new information; but I understand your point) > Therefore the process of re-sending stale information is > *delaying* the sending of useful information (potentially making > it stale also ... under extended congestion episodes). I agree. (But, this is orthogonal to my overall point, I think.) > > * But, another question is whether we are providing an incentive > > for apps to dump things into the network quickly because they > > can then "supercede" them if necessary. So, the tradeoff might > > be for the app to be a bit more careful and thoughtful about > > what is sent versus being quick and careless. > > One could argue that if transmission bandwidth and app processing > power is almost always plentiful, the "quick and careless" > approach is OK. But, if resources are always plentiful then one could also argue that there is zero need for *P*R to begin with. > But, I'd suggest that making app designers communicate to a > PR-SCTP Service Definitions such as "timed reliability" is, in > itself, making the app designer think about such things .... and > creates an environment whereby the app designer is forced to think > about how they desire the app to perform under less-than-ideal > operating conditions (like congestion episodes, routing changes > that result in much larger nominal delays or high packet loss). > > Thus, I happen to believe that we are providing an incentive for > app designers *not* be careless ... but rather to think about > overload/congestion scenarios. And, I think that was exactly Phil and David's point -- that PR-SCTP in some ways helps the situation because it allows us to terminate the re-sending of things that are known to be useless. But, as a Cleveland Brown's coach once said, "there are two sides to every piece of bologna". And, I think the flip side very well could be an incentive to be careless in choosing what to send. Think about the app sending the same thing N times and (framed with application layer sequence numbers or something so that the app could deal with dups). Using PR-SCTP there is no incentive against this. Using TCP there is a clear incentive (head-of-line blocking will cause absolutely lousy performance). Using SCTP there is less incentive than with TCP (because we can get unordered delivery), but there is still a cost in terms of retransmissions and cwnd sacrifice. I am not sure what the right answer here is.... But, I think both sides of the piece of bologna need examined. And, I still think that this falls within the realm of the sorts of things that Reiner is trying to get us to think about. Thanks! allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Apr 3 05:08:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12254 for ; Thu, 3 Apr 2003 05:08:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33AB2N29508 for tsvwg-archive@odin.ietf.org; Thu, 3 Apr 2003 05:11:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33AAUK29354; Thu, 3 Apr 2003 05:10:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33A55K28204 for ; Thu, 3 Apr 2003 05:05:05 -0500 Received: from irmgard.exp-math.uni-essen.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12011 for ; Thu, 3 Apr 2003 05:02:20 -0500 (EST) Received: from gina.exp-math.uni-essen.de (gina.exp-math.uni-essen.de [132.252.150.131]) by irmgard.exp-math.uni-essen.de (8.12.8/8.12.2) with ESMTP id h33A4iJF063940; Thu, 3 Apr 2003 12:04:45 +0200 From: Andreas Jungmaier Organization: University Duisburg To: mallman@grc.nasa.gov, tsvwg@ietf.org Subject: Re: [Tsvwg] pr-sctp Date: Thu, 3 Apr 2003 12:03:47 +0200 User-Agent: KMail/1.5 References: <200304021755.MAA19985@guns.lerc.nasa.gov> In-Reply-To: <200304021755.MAA19985@guns.lerc.nasa.gov> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200304031203.51214.ajung@exp-math.uni-essen.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h33A55K28205 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 02 April 2003 19:55, Mark Allman wrote: > In SF I agreed to more beating on PR-SCTP via the mailing list. > So... > > In SF Reiner showed a few slides that basically asked the question: > How much "extra" (unnecessary) traffic is acceptable to send? TCP > naturally sends some. The coding in some of the RTP protocols > constitutes more than the minimum bits required to send. Etc. I > have thoughts on that subject, but that is not what this email is > about. Dear Mark, dear all, it would be very nice if someone could give a brief wrap-up on the discussions/presentations that were held in SF on this topic. (PR-SCTP). Like me, not all people on this list could make it to SF, and especially the PR-SCTP topic is very interesting to us, not only from our implementation point of view. Thanks, best regards, Andreas - -- - --------------------------------------------------------------------------- Dipl.-Ing. Andreas Jungmaier | Stop sending E-POSTCARDS ! Computer Networking Technology Group | Send E-MAILS -- Use PGP ! University of Essen | http://www.exp-math.uni-essen.de/~ajung | http://www.gnupg.org My PGP Key-ID: D3824AC0 | http://wwwkeys.pgp.net - --------------------------------------------------------------------------- My PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 - --------------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+jAcDXAsLBNOCSsARAoUBAKCifD2FW4UjmiD/4e08DBqoXPk0PgCgkXeF GzSiCqr4ITspVu42xovPQKU= =6JyC -----END PGP SIGNATURE----- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Apr 3 12:45:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03468 for ; Thu, 3 Apr 2003 12:45:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33HlUB07453 for tsvwg-archive@odin.ietf.org; Thu, 3 Apr 2003 12:47:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33HkcK07362; Thu, 3 Apr 2003 12:46:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33HjQK07251 for ; Thu, 3 Apr 2003 12:45:26 -0500 Received: from thebe.your-site.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03349 for ; Thu, 3 Apr 2003 12:42:34 -0500 (EST) Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 5FE112448A1 for ; Thu, 3 Apr 2003 12:45:07 -0500 (EST) Date: Thu, 3 Apr 2003 11:47:11 -0600 From: Caitlin Bestler Subject: Re: [Tsvwg] pr-sctp To: tsvwg@ietf.org X-Priority: 3 In-Reply-To: <200304021755.MAA19985@guns.lerc.nasa.gov> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 4/2/03, Mark Allman wrote: > > * Phil Conrad and David Black rightly beat me and said > something like ... but, PR-SCTP is helping you in this > case because you won't *keep* sending this data that is > useless. And, that is true. (Although, we know we have > sent useless data some number of times.) > > * But, another question is whether we are providing an > incentive for apps to dump things into the network > quickly because they can then "supercede" them if > necessary. So, the tradeoff might be for the app to be a > bit more careful and thoughtful about what is sent versus > being quick and careless. Are we providing a mechanism > for apps to be more careless about sending data into the > network? And, if we are, then I think that thinking > about some govenor on PR-SCTP in the context of Reiner's > thought might be something to consider. > The question is whether PR-SCTP aids the applications that it is intended to support (and whether there are enough of those applications). Obviously, any transport protocol can be abused. Consider the still common practice of setting up multiple TCP connections to make a session more fault tolerant, and use of XML for the "benefit" of bypassing firewalls by masquerading as web traffic. And as many application levels have proven, you can build almost anything on top of UDP, including IPv6 networks. The profile that PR-SCTP addresses is any application that has a content-sensitive need to retransmit lost packets. This is most typically related to content that must be delivered by a certain time to be useful. But the need could be related to limited source buffering, rather than a need at the consumer end. A real-time data capture application, for example, may consider only some raw data worth retaining for retransmit when the cost is not capturing new data. In my mind the prime application for PR-SCTP is streaming multimedia. The content must be delivered with time constraints, and it has an inherent structure. Certain data messages (directory information, directives) MUST be recieved, other data messages (I frames) will have a major impact if lost, and the remainder (P,B frames) can be dropped with very little impact. Many streaming media servers do duplicate critical content, but that is more related to support of multicast environments. PR-SCTP is not suitable for multicast delivery, but then almost all streaming media deliveries are really point-to-point anyway. The comparison with plain SCTP or TCP apparently has already been covered. Clearly PR-SCTP reduces network load because it allows content-sensitive prioritization of retransmits. Only the most important data need be retransmitted, and only if it will arrive in time. This is classic triage. Retransmission can be limited to when it is necessary and when it will not be futile. The comparison with totally unreliable delivery is more informative. An application that was merely loss tolerant, but had no need to ever retansmit portions, would be better served by a unreliable transport such as UDP or DCP. The sender can release its buffers after transmitting, and the receiver knows that what it gets is what it gets. There are no extra packets (or network bandwidth) used to convey this information. More typically, loss of some portion of the data is more critical to proper functioning of the receiver. There are two methods to compensate for this: -- Redundant transmission of critical data: The concern being raised seems to fear that PR-SCTP will encourage this practice. Compared to use of an unreliable transport it actually *discourages* it. The applications that would use PR-SCTP will not use TCP or SCTP instead, they will use UDP or DCP. -- Application layer NACKing to selectively request retransmission of critical data. This is part of RTP/RTSP now. For typical streaming media applications, the sender has at least or probably better idea of what data is critical than the receiver does. PR-SCTP allows it to make these determinations without an application level ACK or NACK. With RTP/RTSP there is no need for explicit ACKs, but that also forces congestion control up to the application layer. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Apr 3 13:29:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05715 for ; Thu, 3 Apr 2003 13:29:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33IVu412380 for tsvwg-archive@odin.ietf.org; Thu, 3 Apr 2003 13:31:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33IVOK12361; Thu, 3 Apr 2003 13:31:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33IU5K12236 for ; Thu, 3 Apr 2003 13:30:05 -0500 Received: from motgate5.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05659 for ; Thu, 3 Apr 2003 13:27:12 -0500 (EST) Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h33IT5R7011490; Thu, 3 Apr 2003 11:29:05 -0700 (MST) Received: from Q.Xie (quantix20.cig.mot.com [160.47.58.31]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h33ITFpG032526; Thu, 3 Apr 2003 12:29:16 -0600 Received: from motorola.com (d50-38cd.cig.mot.com [160.47.56.205]) by Q.Xie (8.8.8+Sun/8.8.8) with ESMTP id MAA18699; Thu, 3 Apr 2003 12:31:34 -0600 (CST) Message-ID: <3E8C7D72.3891F8C8@motorola.com> Date: Thu, 03 Apr 2003 12:29:06 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mallman@grc.nasa.gov CC: tsvwg@ietf.org Subject: Re: [Tsvwg] pr-sctp References: <200304021755.MAA19985@guns.lerc.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mark, Mark Allman wrote: ... > In SF Reiner showed a few slides that basically asked the question: > How much "extra" (unnecessary) traffic is acceptable to send? TCP > naturally sends some. The coding in some of the RTP protocols > constitutes more than the minimum bits required to send. Etc. I > have thoughts on that subject, but that is not what this email is > about. Here I have a comment on Reiner's question (which is the base of your concern on PR-SCTP I think): I can see the point of Reiner's comment applying to RTP/UDP traffic, but don't see it as much an issue for TCP or SCTP. For RTP/UDP, people sometimes use forward error correction (FEC) to combat frame loss. Several RFCs have been issued for this in avt. The idea of FEC is simply to send redundant information for some or all data frames. Of cause, if the original frame is not lost, this redundant information becomes "unnecessary", i.e., a waste of network bandwidth. In the case of RTP/UDP traffic, Reiner raised a good point that the amount of redundancy the app can add to the original traffic must be limited since UDP below has no throttle control. For example, a selfish RTP sender may decide to add 1000% FEC redundancy to his traffic to minimize his own data loss, at the cost of everyone else. Things are not the same with TCP or SCTP. The CC in them automatically puts a limit on how much bandwidth one can get. This changes the whole situation. It is now more like that the app is given a set amount of bandwidth and it has to decide *wisely* what portion of this bandwidth to be used for "unnecessary" data, at the cost of the throughput of his own "necessary" data. If he wants to do the same 1000% redundancy, he simply hurts himself badly. regards, -Qiaobing _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Apr 3 13:41:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06262 for ; Thu, 3 Apr 2003 13:41:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33IhtQ14615 for tsvwg-archive@odin.ietf.org; Thu, 3 Apr 2003 13:43:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33IhHK14439; Thu, 3 Apr 2003 13:43:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33IgQK14364 for ; Thu, 3 Apr 2003 13:42:26 -0500 Received: from seraph2.grc.nasa.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06182 for ; Thu, 3 Apr 2003 13:39:33 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id B2984689EE for ; Thu, 3 Apr 2003 13:42:01 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h33Ig1KV016408; Thu, 3 Apr 2003 13:42:01 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id NAA36873; Thu, 3 Apr 2003 13:42:01 -0500 (EST) Message-Id: <200304031842.NAA36873@guns.lerc.nasa.gov> To: Qiaobing Xie From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] redundant data In-Reply-To: <3E8C7D72.3891F8C8@motorola.com> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Little Miss Can't Be Wrong Date: Thu, 03 Apr 2003 13:42:00 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > It is now more like that the app is given a set amount of > bandwidth and it has to decide *wisely* what portion of this > bandwidth to be used for "unnecessary" data, at the cost of the > throughput of his own "necessary" data. If he wants to do the same > 1000% redundancy, he simply hurts himself badly. I don't think he just hurts himself. Say the app runs at some rate X bps. But, for the sake of redundancy the sender runs at 2X bps and sends all the data twice, which may be fine according to the CC rate limit. And, we might even call that "fair" because everyone is getting a rate of 2X bps. But, if this connection didn't send all this needless junk into the network (i.e., only sent at rate X bps) then there would be X bps of new capacity for others to use to transmit useful data and get actual work done. If enough people send enough redundant data into the network then everyone suffers because they could all utilize more bandwidth if all the needless junk was not floating around. That is not to say we need to get rid of FEC in RTP or *all* spurious retransmission in TCP or SCTP. I am just trying to further motivate my concern (& disagree with your statement above). allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Apr 3 16:09:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13994 for ; Thu, 3 Apr 2003 16:09:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33LC0e30316 for tsvwg-archive@odin.ietf.org; Thu, 3 Apr 2003 16:12:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33LBOK30279; Thu, 3 Apr 2003 16:11:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33L9UK30112 for ; Thu, 3 Apr 2003 16:09:30 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13792 for ; Thu, 3 Apr 2003 16:06:33 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h33L92mr026000 for ; Thu, 3 Apr 2003 14:09:02 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id OAA22607 for ; Thu, 3 Apr 2003 14:08:29 -0700 (MST)] Received: from motorola.com (d50-38cd.cig.mot.com [160.47.56.205]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 2DAN2JD5; Thu, 3 Apr 2003 15:08:12 -0600 Message-ID: <3E8CA245.22104F51@motorola.com> Date: Thu, 03 Apr 2003 15:06:14 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mallman@grc.nasa.gov CC: tsvwg@ietf.org Subject: Re: [Tsvwg] redundant data References: <200304031842.NAA36873@guns.lerc.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mark Allman wrote: > > > It is now more like that the app is given a set amount of > > bandwidth and it has to decide *wisely* what portion of this > > bandwidth to be used for "unnecessary" data, at the cost of the > > throughput of his own "necessary" data. If he wants to do the same > > 1000% redundancy, he simply hurts himself badly. > > I don't think he just hurts himself. Say the app runs at some rate > X bps. But, for the sake of redundancy the sender runs at 2X bps > and sends all the data twice, which may be fine according to the CC > rate limit. And, we might even call that "fair" because everyone is > getting a rate of 2X bps. But, if this connection didn't send all > this needless junk into the network (i.e., only sent at rate X bps) > then there would be X bps of new capacity for others to use to > transmit useful data and get actual work done. If enough people > send enough redundant data into the network then everyone suffers > because they could all utilize more bandwidth if all the needless > junk was not floating around. > > That is not to say we need to get rid of FEC in RTP or *all* > spurious retransmission in TCP or SCTP. I am just trying to further > motivate my concern (& disagree with your statement above). Mark, I can see your point. But this is a little tricky and maybe out (or on the edge) of tsvwg scope. To some degree, you are questioning whether some portion of the data passed by the app above is REALLY necessary :-) I've had numerous times watching A/V codec designers (I used to be one) and wondering "do those few extra redundancy bytes in your frame REALLY make a difference?" They tend to say "surely, you can hear/see the difference". So, when the app guys REALLY think that using 2X bps gives them a critical edge, it's hard to argue with them. I guess the best we in tsvwg could do is just to remind them "please please only put *necessary* extra bits and not any *unnecessary* extra bits into the network". regards, -Qiaobing > > allman > > -- > Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Apr 3 16:27:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14901 for ; Thu, 3 Apr 2003 16:27:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33LTUn31841 for tsvwg-archive@odin.ietf.org; Thu, 3 Apr 2003 16:29:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33LT6K31820; Thu, 3 Apr 2003 16:29:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33LSpK31783 for ; Thu, 3 Apr 2003 16:28:51 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14810 for ; Thu, 3 Apr 2003 16:25:54 -0500 (EST) From: Yogesh.Swami@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h33LSIH10798 for ; Thu, 3 Apr 2003 15:28:18 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 3 Apr 2003 15:28:18 -0600 Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 3 Apr 2003 15:28:11 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Tsvwg] redundant data Date: Thu, 3 Apr 2003 15:28:08 -0600 Message-ID: <025E7DD4182874489CC2F61EE0FA19CEC724CE@daebe004.americas.nokia.com> Thread-Topic: [Tsvwg] redundant data Thread-Index: AcL6EOybbOPHSJogSM+hFFJtU1rVsgAFfU+w To: , Cc: X-OriginalArrivalTime: 03 Apr 2003 21:28:11.0269 (UTC) FILETIME=[ED5BF350:01C2FA27] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h33LSpK31784 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > I don't think he just hurts himself. Say the app runs at some rate > X bps. But, for the sake of redundancy the sender runs at 2X bps > and sends all the data twice, which may be fine according to the CC > rate limit. And, we might even call that "fair" because everyone is > getting a rate of 2X bps. But, if this connection didn't send all > this needless junk into the network (i.e., only sent at rate X bps) > then there would be X bps of new capacity for others to use to > transmit useful data and get actual work done. If enough people > send enough redundant data into the network then everyone suffers > because they could all utilize more bandwidth if all the needless > junk was not floating around. A quick question. How is redundancy defined? Is a text (ascii for example) stream redundant--to me it is, since I can always compress it and reduce the network traffic. So should the transport protocol now go about compressing data ... Why do we need application layer protocols then. --yogesh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Apr 3 16:32:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15097 for ; Thu, 3 Apr 2003 16:32:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33LYSW32194 for tsvwg-archive@odin.ietf.org; Thu, 3 Apr 2003 16:34:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33LY5K32181; Thu, 3 Apr 2003 16:34:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33LX6K32115 for ; Thu, 3 Apr 2003 16:33:06 -0500 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15006 for ; Thu, 3 Apr 2003 16:30:08 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h33LWO8Q006918; Thu, 3 Apr 2003 13:32:27 -0800 (PST) Received: from MRAMALHO-W2K1.cisco.com (dhcp-64-100-135-217.cisco.com [64.100.135.217]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ACX24590; Thu, 3 Apr 2003 13:32:23 -0800 (PST) Message-Id: <4.3.2.7.2.20030403145052.0168b268@mira-sjc5-9.cisco.com> X-Sender: mramalho@mira-sjc5-9.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 03 Apr 2003 16:32:22 -0500 To: mallman@grc.nasa.gov From: "Michael A. Ramalho" Subject: Re: [Tsvwg] pr-sctp Cc: tsvwg@ietf.org In-Reply-To: <200304030435.h334ZZBG032201@thoth.ir.bbn.com> References: <4.3.2.7.2.20030402142907.01641590@mira-sjc5-9.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Mark ... Good volley ... Only one significant point below (and a requisite amount of cute comments) ... Michael At 11:35 PM 4/2/2003 -0500, Mark Allman wrote: >Michael- > > > > * Phil Conrad and David Black rightly beat me and said something > > > like ... but, PR-SCTP is helping you in this case because you > > > won't *keep* sending this data that is useless. And, that is > > > true. (Although, we know we have sent useless data some number > > > of times.) > > > > [The "useless data" might not be "useless" if it arrived in a > > timely manner.] > >(but, if it did then we'd not need to issue an f-tsn for it, either) > > > But to be emphatic .... under congestion this is exactly the > > behavior you want. This is because every bit of information you > > send that the receiver can't profitably use (because it is stale) > > is information that is sent *before more useful information*. > >(assuming an endless supply of new information; but I understand >your point) BTW - There are a lot of applications with this property. For example, sensor data applications for roads, factory control, weather info gathering, temperature control systems, network monitoring information, etc. > > Therefore the process of re-sending stale information is > > *delaying* the sending of useful information (potentially making > > it stale also ... under extended congestion episodes). > >I agree. (But, this is orthogonal to my overall point, I think.) > > > > * But, another question is whether we are providing an incentive > > > for apps to dump things into the network quickly because they > > > can then "supercede" them if necessary. So, the tradeoff might > > > be for the app to be a bit more careful and thoughtful about > > > what is sent versus being quick and careless. > > > > One could argue that if transmission bandwidth and app processing > > power is almost always plentiful, the "quick and careless" > > approach is OK. > >But, if resources are always plentiful then one could also argue >that there is zero need for *P*R to begin with. I agree with your statement; but that is not exactly what I said. I said "*almost* always" for a reason. In virtually every data characterization environment I have run into .... the major congestion cases have been designed to be "rare events". But it is exactly when these rare events occur (sometimes characterized by fractal modeling) that you *really want and need* such congestion behavior to work in an intelligent manner. > > But, I'd suggest that making app designers communicate to a > > PR-SCTP Service Definitions such as "timed reliability" is, in > > itself, making the app designer think about such things .... and > > creates an environment whereby the app designer is forced to think > > about how they desire the app to perform under less-than-ideal > > operating conditions (like congestion episodes, routing changes > > that result in much larger nominal delays or high packet loss). > > > > Thus, I happen to believe that we are providing an incentive for > > app designers *not* be careless ... but rather to think about > > overload/congestion scenarios. > >And, I think that was exactly Phil and David's point -- that PR-SCTP >in some ways helps the situation because it allows us to terminate >the re-sending of things that are known to be useless. > >But, as a Cleveland Brown's coach once said, "there are two sides to >every piece of bologna". And, I think the flip side very well could >be an incentive to be careless in choosing what to send. Think >about the app sending the same thing N times and (framed with >application layer sequence numbers or something so that the app >could deal with dups). Using PR-SCTP there is no incentive against >this. OK ... onto the other side of bologna ... as I partially disagree with this point when considering other potential pr-SCTP service definitions. Let me explain. TCP has infinite persistence (it tries until it dies and blocks everything following). PR-SCTP now has a service definition that has a persistence for a timed lifetime. That is, re-transmit until information stale ... then forget about it. The "forgetaboutit" mechanism is the F-TSN. I'd maintain that the app you describe above is begging for another type of PR-SCTP service definition .... the "try N times (persistence) service definition". If these applications are significant ... one could define a PR-SCTP service definition (addressable through an API that supported the definition) that told PR-SCTP to "try to resend this chunk up to N times, then forgetaboutit". Note the mechanism to "forgetaboutit" *ALREADY EXISTS* in the present PR-SCTP draft. No on the wire changes are needed. The PR-SCTP protocol doesn't need modification to accomplish what this application desires ... only a new API to support the new service definition. If such a service definition existed ... there would be *no need* for the application to send N times via APF as you suggest. We then let PR-SCTP (the transport ... not the application) do the "accounting" and it will only send once (if successful) the majority of the times .... and only sends N times when it was actually unsuccessful for [N-1] prior times. Thus this service definition would make PR-SCTP have a "N persistence" property. This, in my book, is an incentive for the app to behave better than sending "N times" in a brute force manner. It only needs to send a message to the transport layer once (it may desire to be informed in the event of unsuccessful transmission ... but that is an issue for the service definition). This would free the app designer to be an app designer and not become a true IETF transport protocol weenie/expert. We could then deprecate a lot of the UDP ALF mechanisms previously defined (which do things like try N times using an exponential backoff mechanism). SIP UDP ALF comes to mind ... but I don't want to open up that can of worms. TCP has "infinite" persistence. UDP has "1 times" persistence. And PR-SCTP can have "variable" (in time or re-try) persistence. All the "persistence cases" for "reliable transport" are then covered. [Aside: My original suggestion for the name for pr-SCTP was lp-SCTP (for "limited persistence") ... but was overruled by co-authors a year ago.] Do we have a PR-SCTP convert yet? Probably not ... but I'll keep trying ;-). >Using TCP there is a clear incentive (head-of-line blocking >will cause absolutely lousy performance). Using SCTP there is less >incentive than with TCP (because we can get unordered delivery), but >there is still a cost in terms of retransmissions and cwnd >sacrifice. > >I am not sure what the right answer here is.... But, I think both >sides of the piece of bologna need examined. And, I still think >that this falls within the realm of the sorts of things that Reiner >is trying to get us to think about. > >Thanks! > >allman > > >-- >Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg Michael A. Ramalho, Ph.D. Office email: mramalho@cisco.com Personal email: mar42@cornell.edu Office: +1.941.708.4650 Cell: +1.941.544.2844 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Apr 3 16:57:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16199 for ; Thu, 3 Apr 2003 16:57:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33LxXq02491 for tsvwg-archive@odin.ietf.org; Thu, 3 Apr 2003 16:59:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33LxBK02447; Thu, 3 Apr 2003 16:59:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33LwCK02332 for ; Thu, 3 Apr 2003 16:58:12 -0500 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16056 for ; Thu, 3 Apr 2003 16:55:14 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h33Lvc8O029874; Thu, 3 Apr 2003 13:57:39 -0800 (PST) Received: from MRAMALHO-W2K1.cisco.com (dhcp-64-100-135-217.cisco.com [64.100.135.217]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ACX27598; Thu, 3 Apr 2003 13:57:37 -0800 (PST) Message-Id: <4.3.2.7.2.20030403165221.016861f0@mira-sjc5-9.cisco.com> X-Sender: mramalho@mira-sjc5-9.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 03 Apr 2003 16:57:36 -0500 To: "Armando L. Caro Jr." From: "Michael A. Ramalho" Subject: Re: [Tsvwg] pr-sctp Cc: , In-Reply-To: References: <4.3.2.7.2.20030402142907.01641590@mira-sjc5-9.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Armando - Two short comments below - Michael Ramalho At 06:38 PM 4/2/2003 -0500, Armando L. Caro Jr. wrote: >On Wed, 2 Apr 2003, Michael A. Ramalho wrote: > > > But to be emphatic .... under congestion this is exactly the behavior > you want. > > This is because every bit of information you send that the receiver can't > > profitably > > use (because it is stale) is information that is sent *before more useful > > information*. > > Therefore the process of re-sending stale information is *delaying* the > > sending of > > useful information (potentially making it stale also ... under extended > > congestion > > episodes). > >I agree with the concept of PR-SCTP. I want to emphasize that bundling >FTSNs with data should be done whenever possible. I think that sending a >FTSN in a packet of its own is not much better than re-sending the stale >data. Both will be triggered at the same point. Both will take the same >time to reach the receiver. And if lost, both suffer the same >consequences. The only improvement is that flightsize gets reduced and new >data may be sent. > >Section 3.5 F2) emphasizes that bundling should be done, but just >wondering out loud... should PR-SCTP implementations reserve room >for FTSNs in all packets. If data chunks are not fragmented properly >when queued, then SCTP cannot refragment them later when bundling >is needed. The draft says that a sender MAY wait to bundle FTSNs, but is >this wording loose enough to allow SCTP to wait for newly queued data to >bundle with. In other words, data already queued may be fragmented too >large for bundling, but newly queued data may be fragmented small enough >for bundling. ...I don't think I like this idea. Maybe simply reserving >room for some minimum FTSN size is good enough. > > > Note: The congestion condition is not simply characterized by loss .... but > > additionally by duration (in time) of the congestion event (as this has an > > effect on "staleness"). We need to consider the time/delay element in > > the congestion episode. > >I don't follow how this relates to FTSNs. It doesn't. It relates to people who like to plot "goodput" vs "packet error rate". My PR-SCTP "goodput" description of this thread (which you cut) suggested that the goodput was a function of staleness ... which was related to the *time duration* of the congestion episode. Thus you need three dimensional surface to describe the PR-SCTP goodput ... one axis "goodput", one axis "packet error rate" and the remaining axis "congestion episode duration". > > In this thought process we might consider other PR-SCTP service definitions > > that are more appropriate to the applications to consider under > > overload or congestion scenarios. The creation of other pr-sctp service > > definition > > to help "govern" the sending of data would be welcome. However, the F-TSN > > mechanism is the only thing required "on the wire" for PR-SCTP. > >I like that the PR-SCTP mechanism is independent of the service >definition. However, I cannot think of applications that could use >anything but timed-reliability. See my most recent email to Allman ... SIP UDP ALF as an example. Michael >~armando > >0-- --0 >| Armando L. Caro Jr. | Protocol Engineering Lab | >| www.cis.udel.edu/~acaro | University of Delaware | >0-- --0 > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg Michael A. Ramalho, Ph.D. Office email: mramalho@cisco.com Personal email: mar42@cornell.edu Office: +1.941.708.4650 Cell: +1.941.544.2844 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 4 03:55:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11532 for ; Fri, 4 Apr 2003 03:55:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h348wa326111 for tsvwg-archive@odin.ietf.org; Fri, 4 Apr 2003 03:58:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h348u9K26034; Fri, 4 Apr 2003 03:56:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h348rhK25937 for ; Fri, 4 Apr 2003 03:53:45 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11472 for ; Fri, 4 Apr 2003 03:50:27 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h348quRs016328 for ; Fri, 4 Apr 2003 10:52:56 +0200 (MEST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A47F096; Fri, 4 Apr 2003 10:52:56 +0200 Received: from res0010384da36.eed.ericsson.se (dhcp5-197.eed.ericsson.se [164.48.135.197]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id KAA23660 for ; Fri, 4 Apr 2003 10:52:55 +0200 (MET DST) Message-Id: <5.2.0.9.0.20030404102651.02c28e28@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 04 Apr 2003 10:52:58 +0200 To: tsvwg@ietf.org From: Reiner Ludwig Subject: Re: [Tsvwg] redundant data - A TFRC Example In-Reply-To: <3E8CA245.22104F51@motorola.com> References: <200304031842.NAA36873@guns.lerc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , I'd like to add an example for people to think about ... If you try to run VoIP over TFRC, you'll most likely be disappointed by the quality. The reason is that when A talks, then (usually) B is silent, and vice versa. I.e., a talkspurt A>B is followed by a talkspurt B>A is followed by a talkspurt A>B, .... While B is silent and if the talkspurt from A is long enough then B's TFRC send rate will decay to zero (or at least often enough below the required coder rate). Andrei Gurtov did this experiment and told me how 'broken' such a voice conversation becomes. The "easy fix" is for B to send dummy data (or even potentially useful data like pictures, ads, calendar sync data, etc.) for the sole purpose of maintain the TFRC rate above the required coder rate. B would be a good Internet citizen in the sense that it is always TCP friendly. Still, B is sending data it does't have to send necessarily. Should the IETF set up rules that would limit the sending of such potentially useless data? Do we have hope that such rules would be obeyed by application and protocol designers? I could imagine VoIP application designers that would let themselves be convinced to move away from uncontrolled UDP to RTP/DCCP, but probably not much further. I.e., their view could be: "We ensure that our flows behave TCP friendly, but what we do with the available bandwidth is our business." I'm not saying that I agree to that, but I would understand that view. ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 4 09:28:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23046 for ; Fri, 4 Apr 2003 09:28:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34EV9819611 for tsvwg-archive@odin.ietf.org; Fri, 4 Apr 2003 09:31:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34ETOK19462; Fri, 4 Apr 2003 09:29:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34ESqK19412 for ; Fri, 4 Apr 2003 09:28:52 -0500 Received: from seraph2.grc.nasa.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22849 for ; Fri, 4 Apr 2003 09:25:35 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 0169B689B0 for ; Fri, 4 Apr 2003 09:28:04 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h34ES4KV028963; Fri, 4 Apr 2003 09:28:04 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id JAA49024; Fri, 4 Apr 2003 09:28:04 -0500 (EST) Message-Id: <200304041428.JAA49024@guns.lerc.nasa.gov> To: Qiaobing Xie From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] redundant data In-Reply-To: <3E8CA245.22104F51@motorola.com> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Lonesome Day Date: Fri, 04 Apr 2003 09:28:04 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > I can see your point. But this is a little tricky and maybe out > (or on the edge) of tsvwg scope. To some degree, you are > questioning whether some portion of the data passed by the app > above is REALLY necessary :-) That is absolutely not the question I was asking. I think that trying to figure out whether the app is passing new or redundant data is likely an NP-hard problem. My wondering is specifically about transports aiding the process of sending redundant data. For instance, early retransmit proposes resending data with less indication that it was lost than fast retransmit. Therefore, ER is less robust to reordering than FR. There are worst cases where ER really wastes network resources by resending data that does not need to be resent. That is not an application->transport issue, rather it is a transport only issue. Another class of problems is whether the transport provides an incentive for the app to send lots of data that may accomplish no useful work. I am not sure if PR-SCTP does this or not. But, thus far, nobody has convinced me that it does not. allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 4 09:34:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23243 for ; Fri, 4 Apr 2003 09:34:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34EbSH20688 for tsvwg-archive@odin.ietf.org; Fri, 4 Apr 2003 09:37:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Ea3K19876; Fri, 4 Apr 2003 09:36:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34EZnK19835 for ; Fri, 4 Apr 2003 09:35:49 -0500 Received: from seraph2.grc.nasa.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23163 for ; Fri, 4 Apr 2003 09:32:32 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id F2BF9689A2 for ; Fri, 4 Apr 2003 09:35:01 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h34EZ1KV000606; Fri, 4 Apr 2003 09:35:01 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id JAA49094; Fri, 4 Apr 2003 09:35:01 -0500 (EST) Message-Id: <200304041435.JAA49094@guns.lerc.nasa.gov> To: "Michael A. Ramalho" From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] pr-sctp In-Reply-To: <4.3.2.7.2.20030403145052.0168b268@mira-sjc5-9.cisco.com> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Lonesome Day Date: Fri, 04 Apr 2003 09:35:01 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > If such a service definition existed ... there would be *no need* > for the application to send N times via APF as you suggest. We > then let PR-SCTP (the transport ... not the application) do the > "accounting" and it will only send once (if successful) the > majority of the times .... and only sends N times when it was > actually unsuccessful for [N-1] prior times. Thus this service > definition would make PR-SCTP have a "N persistence" property. > > This, in my book, is an incentive for the app to behave better > than sending "N times" in a brute force manner. No need, but maybe a desire. If I can send something twice from the app and one arrives at the receiver then by some metrics the performance may be better because we don't have to wait for (at least) an RTT for the transport to figure out that the packet was dropped and retransmit. If we have to waste our own resources (buffer space, cwnd space, etc.) to retransmit this packet that is now useless then I think there is *some* incentive against using such a brute force method. If we can say "oh, nevermind on that first segment" and clean up our own resources then it seems like there is no incentive not to waste network resources if one wanted lots of redundancy. allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 4 10:50:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27208 for ; Fri, 4 Apr 2003 10:50:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34Frfd26524 for tsvwg-archive@odin.ietf.org; Fri, 4 Apr 2003 10:53:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Fqi826393; Fri, 4 Apr 2003 10:52:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Fjo825902 for ; Fri, 4 Apr 2003 10:45:50 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26825 for ; Fri, 4 Apr 2003 10:42:31 -0500 (EST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 92B65328FA; Fri, 4 Apr 2003 10:45:00 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id CBF50328F7; Fri, 4 Apr 2003 10:44:59 -0500 (EST) Date: Fri, 4 Apr 2003 10:44:59 -0500 (EST) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Mark Allman Cc: Subject: Re: [Tsvwg] redundant data In-Reply-To: <200304041428.JAA49024@guns.lerc.nasa.gov> Message-ID: X-Spam-Status: No, hits=-5.3 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Fri, 4 Apr 2003, Mark Allman wrote: > Another class of problems is whether the transport provides an > incentive for the app to send lots of data that may accomplish no > useful work. I am not sure if PR-SCTP does this or not. But, thus > far, nobody has convinced me that it does not. I understand your concern, and I cannot say that I can convince you that PR-SCTP doesn't face this problem. However, doesn't any less-than-fully-reliable transport protocol face the same problem? ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 4 11:55:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29109 for ; Fri, 4 Apr 2003 11:55:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34Gvx830706 for tsvwg-archive@odin.ietf.org; Fri, 4 Apr 2003 11:57:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Gu5830652; Fri, 4 Apr 2003 11:56:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Gs8830581 for ; Fri, 4 Apr 2003 11:54:08 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29024 for ; Fri, 4 Apr 2003 11:50:46 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h34GrAmr025577; Fri, 4 Apr 2003 08:53:10 -0800 (PST) Received: from MRAMALHO-W2K1.cisco.com (dhcp-64-100-135-217.cisco.com [64.100.135.217]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ACX90418; Fri, 4 Apr 2003 08:53:11 -0800 (PST) Message-Id: <4.3.2.7.2.20030404113253.01670798@mira-sjc5-9.cisco.com> X-Sender: mramalho@mira-sjc5-9.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 04 Apr 2003 11:53:10 -0500 To: "Armando L. Caro Jr." , Mark Allman From: "Michael A. Ramalho" Subject: Re: [Tsvwg] redundant data Cc: In-Reply-To: References: <200304041428.JAA49024@guns.lerc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At 10:44 AM 4/4/2003 -0500, Armando L. Caro Jr. wrote: >On Fri, 4 Apr 2003, Mark Allman wrote: > > > Another class of problems is whether the transport provides an > > incentive for the app to send lots of data that may accomplish no > > useful work. I am not sure if PR-SCTP does this or not. But, thus > > far, nobody has convinced me that it does not. > >I understand your concern, and I cannot say that I can convince you that >PR-SCTP doesn't face this problem. However, doesn't any >less-than-fully-reliable transport protocol face the same problem? > >~armando I too see Mark's lament that the transport may allow (I think encourage is too strong) the app to send data to it that - perhaps - will not be sent (or re-sent if not ACKed). But let's look at the alternative (yet another side of bologna). The alternative is to mandate all app designers to be as smart as Mark [or put your favorite tsvwg member name here] in order that they re-transmit "transport friendly" (with correct backoffs, etc.) in "limited persistence" cases. Unfortunately, this is too high a burden for most app designers (although some would be smart enough to do something reasonable). I think some reasonable, course feedback mechanism should be built into applications in order to guide the app on the "course rate" of information sent when the app has significant degrees of rate freedom (most video codecs, for example). However, I think it is an unreasonable expectation that application designers have detailed tsvwg knowledge ... and I think the tradeoff of letting the application send data to the transport with "lifetimes" or "N persistence" mechanisms I described in earlier threads is a reasonable way to let the transport layer take care of the "fine grained" transport dynamics in a "transport friendly" manner. Even if the far-end application doesn't provide feedback, the near end transport can notify the app for chunks it decided to F-TSN over; this is at least some feedback. Lastly, I think providing such mechanisms (via service definitions) actually encourage app designers to give more thought on what they desire to transmit under overload/congestion scenarios. Michael Ramalho _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 4 12:09:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29449 for ; Fri, 4 Apr 2003 12:09:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34HCPh32664 for tsvwg-archive@odin.ietf.org; Fri, 4 Apr 2003 12:12:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34HBA832527; Fri, 4 Apr 2003 12:11:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34H0v830857 for ; Fri, 4 Apr 2003 12:00:57 -0500 Received: from seraph3.grc.nasa.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29157 for ; Fri, 4 Apr 2003 11:57:35 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id D02DD6B9CF for ; Fri, 4 Apr 2003 11:59:15 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h34GxFKV011130; Fri, 4 Apr 2003 11:59:15 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id LAA58477; Fri, 4 Apr 2003 11:59:14 -0500 (EST) Message-Id: <200304041659.LAA58477@guns.lerc.nasa.gov> To: "Michael A. Ramalho" , tsvwg@ietf.org From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: Re: [Tsvwg] pr-sctp Organization: BBN Technologies/NASA GRC Song-of-the-Day: Lonesome Day Date: Fri, 04 Apr 2003 11:59:14 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Michael rightly noted that I wrote a whole lot of ambiguous rubbish the last time around. Durned context senssative languages. So, I am going to try again... > If such a service definition existed ... there would be *no need* > for the application to send N times via APF as you suggest. We > then let PR-SCTP (the transport ... not the application) do the > "accounting" and it will only send once (if successful) the > majority of the times .... and only sends N times when it was > actually unsuccessful for [N-1] prior times. Thus this service > definition would make PR-SCTP have a "N persistence" property. > > This, in my book, is an incentive for the app to behave better > than sending "N times" in a brute force manner. No need, but maybe a desire. Say the app sends the same message to the transport twice. The transport then sends both copies out (in two segments). Now, say one of these segments gets dropped but the other arrives fine and is delivered to the receiving app. By some metrics that offers better performance than the case when the sending app gives the sending transport only one copy and lets the transport retransmit as necessary (which adds an extra ~RTT before the receiving app gets the data). If the sender has to waste its own resources (buffer space, cwnd space, etc.) to retransmit the lost segment (that is now useless) then I think there is *some* incentive against using such a brute force method. If the sender can say "oh, nevermind on that lost segment" and clean up our own resources then it seems like there is no incentive not to waste network resources if one wanted lots of redundancy. I hope that is a bit more clear. Sorry for any confusion I caused. allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 4 12:12:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29625 for ; Fri, 4 Apr 2003 12:12:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34HFgT00447 for tsvwg-archive@odin.ietf.org; Fri, 4 Apr 2003 12:15:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34HF3800374; Fri, 4 Apr 2003 12:15:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34HEH800319 for ; Fri, 4 Apr 2003 12:14:17 -0500 Received: from smtp-out.comcast.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29532 for ; Fri, 4 Apr 2003 12:10:55 -0500 (EST) Received: from livingroom.acm.org (pcp01480554pcs.ncstl01.de.comcast.net [68.82.68.240]) by mtaout08.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HCT00HH0WYPG8@mtaout08.icomcast.net> for tsvwg@ietf.org; Fri, 04 Apr 2003 12:08:50 -0500 (EST) Date: Fri, 04 Apr 2003 12:08:49 -0500 From: Phillip Conrad X-Sender: phillipconrad@mail.comcast.net To: tsvwg@ietf.org Cc: Phillip Conrad Message-id: <5.1.0.14.2.20030404115134.0372e698@joda.cis.temple.edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Subject: [Tsvwg] Application Scenarios where PR-SCTP reduces "junk data" on the net Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Dear Colleagues: As I understand it, (and I might have it wrong) Mark's concern is that PR-SCTP might encourage senders to put information on the wire that is "not very useful"... .what we might call "junk data". After all, if one is willing to "give up" on some message, how important could it have been in the first place? Thus, the argument might go, it is a waste of network resources to have put that data on the wire in the first place. I may be putting words in Mark's mouth, so Mark, if that is NOT your argument, feel free to speak up and correct me. But if that is the argument, then I think a concept that may be helpful is to consider the "time varying value of information". That is, information can be very valuable at one point in time, and less valuable at another point in time. That is key idea behind the idea of "timed reliability". Thus, by having a transport service that allows us to give up on packets after their utility has decreased, we can actually acheive the result of _less_ "junk data" going on the wire. At 09:28 AM 4/4/2003 -0500, Mark Allman wrote: >Another class of problems is whether the transport provides an >incentive for the app to send lots of data that may accomplish no >useful work. I am not sure if PR-SCTP does this or not. But, thus >far, nobody has convinced me that it does not. Mark, if you are not certain that PR-SCTP does this, I think rather the burden of proof is on you to show a scenario that PR-SCTP _does_ create such an incentive. I think that if you can make that case, we can really have a useful discussion. Without a coherent argument to that effect, your technical argument against PR-SCTP seems to be that "it _might_ create an incentive to send junk data, though I can't yet produce the scenario in which that is true". This doesn't seem to be a very strong technical argument. On the other hand, I'd like to present a couple of scenarios, where I think there is a convincing case that PR-SCTP actually achieves the opposite.. that is, to "reduce" the amount of "junk data" flowing on the network. (Scenario 1): Consider a "situational awareness" application operating over a wireless IP network. In a situational awareness application, mobile units (mounted on vehicles or wearable computers) send periodic status updates to planners that need to put together a coherent picture of "who is where" and "how everyone is doing". Military applications are probably obvious, but if you prefer a non-military purpose, consider tracking emergency vehicles (rescue, fire personnel, gas and electrical repair workers, etc.) in a disaster situation (e.g. the "big earthquake"). In such a network, packet loss due to both congestion, noise, and link and router failure may be significant, so it is important to concentrate the resources of the network on the most crucial information. If the application generates status update messages every 2 seconds, then it might make sense to put an "expiration date" on such messages of 3-5 seconds, so that if there is a transient network outage of, say 20 seconds... not long enough to drop the SCTP association, but long enough to create a backlog of update messages, the sender can skip over the retransmission of some stale messages and get the more timely data out the door. Now, in this application, it is NOT the case that the transmission of any of this information is "wasteful" when it is first submitted to the transport service... at least not in the usual case of low packet loss. In that case, the constant updates would flow to the receiver in a timely fashion, and give a second by second picture of where each unit in the overall picture is located, a picture that may be crucial to saving lives. However, once the network gets into trouble, and we get into the situation where due to a transient outage, a bunch of messages are sitting in the transport send buffer of some unit, and those messages at the head of the transmit queue are NOT the most crucial information to transmit at that point in time (because they are stale) PR-SCTP allows the sender to skip over the information that has now _become_ stale, and put the _more_ useful (i.e., more timely) status information on the wire. (Application 2:) My understanding is that in certain problem domains that are outside my main area of expertise (e.g. signalling transport, ip storage) there are certain legacy protocols that it is desirable now, because of the ubiquity of IP-based technology, to place on top of IP networks. (Since my knowledge of sigtran and ip storage is very limited, I hope those who are more expert in these areas can either confirm or correct my simplified explanations below.) Because it is desired for these protocols to benefit from the congestion control, flow control, and retransmission mechanisms available in protocols such as TCP and SCTP, these legacy protocols are generally implemented on top of TCP and/or SCTP. However, a problem occurs because many of these protocols have built into them, legacy retransmission timers of their own. In some cases, these retransmission timers might be, for example, fixed values that are an order of magnitude larger than typical initial RTOs that would result from TCP or SCTP. (say, for sake of argument, 5 seconds), and certainly larger than the retransmission that might result from a duplicate ack triggered fast retransmit. However, sometimes, if the RTO gets backed off, the TCP or SCTP RTO might be larger than the application layer protocols own RTO. Now we have retransmission occurring at two different layers, which is an undesirable situation. Now there are two ways of addressing this probably immediately occur to the reader, neither of which is very satisfactory in the real world, as I understand it. One answer to this would be to "fix the application layer protocol" to either turn off the retransmissions at this layer. However, as a practical matter, my understanding is that the application layer protocols in question are "deeply embedded" in signalling transport and storage systems, and that while is "might be nice" to be able to do this, it is simply not feasible. Another approach, is to apply the end-to-end argument, and run these over a completely best-effort transport, and rely exclusively on the retransmission built into the application layer protocol. A problem here is that the application layer protocol's retransmission strategies don't adapt well to the underlying network, not in the way that the retransmissions in TCP and SCTP adapt. (There may be other reasons as well that this is not feasible... I'll rely on my colleagues to fill in the gaps) The alternative approach is to use the timed-reliability service provided by PR-SCTP to indicate that messages that will be retransmitted by the upper layer after, for example, 5 seconds, should be abandonded by the transport layer once that 5 seconds has elapsed. Again, this results in an actual _reduction_ in "junk data", i.e. a redundant retransmission of a particular message X, which in the absence of the PR-SCTP timed reliabilty service, ends up appearing more than once in the reliable data stream. Therefore, the bottom line is that PR-SCTP helps to keep redundant data, or data that has become stale off the network. None of this data was "junk data" when it was first transmitted, which seems to be one of the fears or doubts that is being thrown at PR-SCTP. Regards, Phill -- Phillip Conrad, Asst Professor, CIS Dept. Temple University -- Philadelphia PA 19122 conrad@acm.org _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 4 14:09:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03124 for ; Fri, 4 Apr 2003 14:09:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34JCbQ09728 for tsvwg-archive@odin.ietf.org; Fri, 4 Apr 2003 14:12:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34JBv809680; Fri, 4 Apr 2003 14:11:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34J9T809560 for ; Fri, 4 Apr 2003 14:09:29 -0500 Received: from smtp-out.comcast.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02971 for ; Fri, 4 Apr 2003 14:06:06 -0500 (EST) Received: from livingroom.acm.org (pcp01480554pcs.ncstl01.de.comcast.net [68.82.68.240]) by mtaout10.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HCU00AVT2I1KY@mtaout10.icomcast.net> for tsvwg@ietf.org; Fri, 04 Apr 2003 14:08:26 -0500 (EST) Date: Fri, 04 Apr 2003 14:08:31 -0500 From: Phillip Conrad Subject: Re: [Tsvwg] pr-sctp X-Sender: phillipconrad@mail.comcast.net To: tsvwg@ietf.org Cc: Phillip Conrad Message-id: <5.1.0.14.2.20030404140421.03f21908@joda.cis.temple.edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Mark, I agree that this explanation is a lot more clear than your previous ones. However I still don't think you have made your case, or at least, your case isn't clear to me. (If it is clear to others, please help me understand it.) More comments below... At 11:59 AM 4/4/2003 -0500, Mark Allman wrote: > >Michael rightly noted that I wrote a whole lot of ambiguous rubbish >the last time around. Durned context senssative languages. So, I >am going to try again... > >Say the app sends the same message to the transport twice. The >transport then sends both copies out (in two segments). Now, say >one of these segments gets dropped but the other arrives fine and is >delivered to the receiving app. By some metrics that offers better >performance than the case when the sending app gives the sending >transport only one copy and lets the transport retransmit as >necessary (which adds an extra ~RTT before the receiving app gets >the data). If the sender has to waste its own resources (buffer >space, cwnd space, etc.) to retransmit the lost segment (that is now >useless) then I think there is *some* incentive against using such a >brute force method. If the sender can say "oh, nevermind on that >lost segment" and clean up our own resources then it seems like >there is no incentive not to waste network resources if one wanted >lots of redundancy. You note that there is a disincentive to sending junk data in regular TCP/SCTP (i.e. spending buffer space, cwnd, etc.). But you imply that this disincentive is NOT present with PR-SCTP. That's where I think we have a difference in understanding, becuase I claim that the same disincentives to send junk data apply equally to PR-SCTP. Specifically, I note that: * Every chunk you send with PR-SCTP consumes rwnd and cwnd space. * PR-SCTP does NOT result in putting any more data on the network than if you did NOT have PR-SCTP. It is only a question of "which" data goes on the network. Look at it another way: TCP-friendliness enforces that each transport sender gets some "share" of the bandwidth on the network. How a given application chooses to use that share is up to that application. PR-SCTP gives the application more flexibility in how it chooses how to use that share... meaning that it can make decisions on the fly about diverting some of that share from a message that is already in the sequence number space to a new message that is not yet in the sequence number space. I don't see how that creates an incentive to send junk data. I'm not saying with 100% certainty that it isn't there, but the more we talk about it, the less worried I get. Maybe there is an argument that I just haven't seen or understood yet. Now in response to your comments about "circling the wagons"... see below. :-) >At 12:57 PM 4/4/2003 -0500, Mark Allman wrote: >>I should re-phrase... I think there *is* an incentive for apps to >>pollute the network with junk data caused by PR-SCTP. What I am not >>sure of, yet, is how much we should really care about it. I.e., how >>big of a deal is it? But, I *would advocate* understanding it >>before sending it out and then waiting for the paper (from Stefan >>Savage, no doubt!) on how to game SCTP for fun and profit. (And, I >>have been somewhat disappointed thus far because I see some folk >>"circling the wagons" to "protect" SCTP rather than trying to help >>figure out if this is a real issue or it is just me being paranoid >>(which is a fine result, BTW). (My guess - without reading your >>note - is that you have not done that.)) I don't know if it was deliberate or accidental, but your last phrase is marvelously ambiguous.. do you mean that your guess is that I have not "circled the wagons", or your guess is that I have not "help[ed] to figure out if this is a real issue"? (You can leave this ambiguous if you like... :-) ). Well, in any case, a accusation that the PR-SCTP advocates are "circling the wagons" sounds a bit light an invitation to up the rhetoric a little bit, but Mark, since I consider you a friend, I'm not gonna take the bait. Well, what the heck, maybe I will, trusting that you'll see this as a friendly jab rather than an invitation to a flame war. I don't think we are circling the wagons at all. I think we are trying honestly to understand what your fear is that PR-SCTP creates an incentive to send junk data... which, if it could be argued convincingly, would be a reason to pause and reflect. But so, far, if you'll forgive me for saying so, your criticism that PR-SCTP creates an incentive to send junk data without a clear explanation of how that occurs feels a little bit like a "fear uncertainty doubt" attack. That's why I sent my much longer note with some specific application scenarios where I think I've made a case that PR-SCTP does just the opposite: it helps applications _reduce_ junk data on the net. The bottom line is that if you are being TCP-friendly, you have a "share" of the network resources. How you use it is up to you. If you waste your share, that's your own funeral, because TCP-friendliness limits your impact on others. How much worse would it be if (in the absence of PR-SCTP) you had to open, for example, two separate connections: say, (1) a TCP or SCTP connection/association for the reliable data, and (2) a TCP-friendly UDP flow, or at somepoint in the future, a DCCP connection for the other data. Now you have to implement your own reliability on top of connection flow (2) and further, you have increased your share of the bandwidth by having two tcp-friendly flows rather than one. Seems like a lot more waste to me. (Obligatory concession: yes, I know that if we all implemented an end point congestion manager type solution, that last point would be invalidated. Seems unlikely though.) Thanks, Phill _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 4 14:18:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03513 for ; Fri, 4 Apr 2003 14:18:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34JLkV10407 for tsvwg-archive@odin.ietf.org; Fri, 4 Apr 2003 14:21:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34JLC810389; Fri, 4 Apr 2003 14:21:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34JKK810322 for ; Fri, 4 Apr 2003 14:20:20 -0500 Received: from ilsa.franken.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03459 for ; Fri, 4 Apr 2003 14:16:56 -0500 (EST) Received: from lurchi.franken.de (dialin-145-254-157-025.arcor-ip.net [145.254.157.25]) by ilsa.franken.de (Postfix) with ESMTP id BDFCC24619; Fri, 4 Apr 2003 21:16:04 +0200 (CEST) Date: Fri, 4 Apr 2003 21:13:11 +0200 Subject: Re: [Tsvwg] Application Scenarios where PR-SCTP reduces "junk data" on the net Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: tsvwg@ietf.org To: Phillip Conrad From: Michael Tuexen In-Reply-To: <5.1.0.14.2.20030404115134.0372e698@joda.cis.temple.edu> Message-Id: <7A68375F-66D1-11D7-B9EB-0030654C1AB6@lurchi.franken.de> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear all, one of the main usage scenarios for SCTP is SIGTRAN. The SS7 protocols being transported can not be changed and run their own timers, ISUP for example. Looking at this example the following happens: The ISUP sender sends an ISUP message, starts a timer and waits for an ISUP answer. If the timer is stopped if the answer arrives and another message will be send. But if the answer does not arrive before the timer runs off ISUP brings down the call by sending a NEW message. Now it makes no sense for the SCTP layer to retransmit the first message. It would be better to discard that message and only deal with the new message. Assuming that this happens during congestion you are sending 2 messages in case of SCTP and only one in case of PR-SCTP, because you are not continuing to retransmit the now useless first message. You can say that we should change the upper layer, but the intention of the SIGTRAN WG is exactly the opposite: provide a way of SS7 over IP WITHOUT changing the SS7 protocols. This usage scenario was already considered during the work on RFC 2960, therefore you find a lifetime parameter in the send call description. The mechanisms in the protocol however, did not make it. So I think the discussion should not only be on potential ways of misuse, but also on the scenarions where such a mechanism can be really helpful. SIGTRAN, in my opinion, is one. Best regards Michael On Friday, Apr 4, 2003, at 19:08 Europe/Berlin, Phillip Conrad wrote: > Dear Colleagues: > > As I understand it, (and I might have it wrong) Mark's concern is that > PR-SCTP might encourage senders to put information on the wire that is > "not very useful"... .what we might call "junk data". After all, if > one is > willing to "give up" on some message, how important could it have been > in the first place? Thus, the argument might go, it is a waste of > network > resources to have put that data on the wire in the first place. > > I may be putting words in Mark's mouth, so Mark, if that is NOT your > argument, > feel free to speak up and correct me. > > But if that is the argument, then I think a concept that may be > helpful is > to consider the "time varying value of information". That is, > information > can be very valuable at one point in time, and less valuable at another > point in time. That is key idea behind the idea of "timed > reliability". Thus, by > having a transport service that allows us to give up on packets after > their > utility has decreased, we can actually acheive the result of _less_ > "junk > data" going on the wire. > > At 09:28 AM 4/4/2003 -0500, Mark Allman wrote: >> Another class of problems is whether the transport provides an >> incentive for the app to send lots of data that may accomplish no >> useful work. I am not sure if PR-SCTP does this or not. But, thus >> far, nobody has convinced me that it does not. > > Mark, if you are not certain that PR-SCTP does this, I think rather > the burden of proof is on you to show a scenario that PR-SCTP _does_ > create such an incentive. > I think that if you can make that case, we can really have a useful > discussion. > > Without a coherent argument to that effect, your technical argument > against PR-SCTP seems to be that "it _might_ create an incentive to > send junk data, though I can't yet produce the scenario in which that > is true". This doesn't seem to be a very strong technical argument. > > On the other hand, I'd like to present a couple of scenarios, where I > think there is a convincing case that PR-SCTP actually achieves the > opposite.. that is, to "reduce" the amount of "junk data" flowing on > the network. > > (Scenario 1): Consider a "situational awareness" application operating > over > a wireless IP network. In a situational awareness application, > mobile units > (mounted on vehicles or wearable computers) send periodic status > updates > to planners that need to put together a coherent picture of "who is > where" > and "how everyone is doing". Military applications are probably > obvious, > but if you prefer a non-military purpose, consider tracking emergency > vehicles (rescue, fire personnel, gas and electrical repair workers, > etc.) > in a disaster situation (e.g. the "big earthquake"). > > In such a network, packet loss due to both congestion, noise, and link > and > router failure may be significant, so it is important to concentrate > the > resources of the network on the most crucial information. If the > application > generates status update messages every 2 seconds, then it might make > sense to put an "expiration date" on such messages of 3-5 seconds, > so that if there is a transient network outage of, say 20 seconds... > not long enough to drop the SCTP association, but long enough to > create a backlog of update messages, the sender can skip over > the retransmission of some stale messages and get the more timely > data out the door. > > Now, in this application, it is NOT the case that the transmission of > any > of this information is "wasteful" when it is first submitted to the > transport > service... at least not in the usual case of low packet loss. In > that case, the > constant updates would flow to the receiver in a timely fashion, and > give > a second by second picture of where each unit in the overall picture > is > located, a picture that may be crucial to saving lives. > > However, once the network gets into trouble, and we get into the > situation > where due to a transient outage, a bunch of messages are sitting in the > transport send buffer of some unit, and those messages at the head of > the transmit queue are NOT the most crucial information to transmit at > that point in time (because they are stale) PR-SCTP allows > the sender to skip over the information that has now _become_ stale, > and > put the _more_ useful (i.e., more timely) status information on the > wire. > > (Application 2:) My understanding is that in > certain problem domains that are outside my main area of expertise > (e.g. signalling transport, ip storage) there are certain legacy > protocols > that it is desirable now, because of the ubiquity of IP-based > technology, to place on top of IP networks. > > (Since my knowledge of sigtran and ip storage is very limited, > I hope those who are more expert in these areas can either confirm > or correct my simplified explanations below.) > > Because it is desired for these protocols to benefit from the > congestion > control, flow control, and retransmission mechanisms available > in protocols such as TCP and SCTP, these legacy protocols are generally > implemented on top of TCP and/or SCTP. > > However, a problem occurs because many of these protocols > have built into them, legacy retransmission timers of their own. In > some > cases, these retransmission timers might be, for example, fixed values > that are an order of magnitude larger than typical initial RTOs that > would > result from TCP or SCTP. (say, for sake of > argument, 5 seconds), and certainly larger than the retransmission that > might result from a duplicate ack triggered fast retransmit. > > However, sometimes, if the RTO gets backed off, the TCP or SCTP RTO > might > be larger than the application layer protocols own RTO. Now we have > retransmission occurring at two different layers, which is an > undesirable situation. > > Now there are two ways of addressing this probably immediately occur > to the > reader, neither of which is very satisfactory in the real world, as I > understand it. > > One answer to this would be to "fix the application layer protocol" to > either turn off the retransmissions at this layer. However, as a > practical matter, my understanding is that the application layer > protocols > in question are "deeply embedded" in signalling transport and storage > systems, and that while is "might be nice" to be able to do this, it is > simply not feasible. > > Another approach, is to apply the end-to-end argument, and run these > over a > completely best-effort transport, and rely exclusively on the > retransmission built into the application layer protocol. A problem > here > is that the application layer protocol's retransmission strategies > don't > adapt well to the underlying network, not in the way that the > retransmissions in TCP and SCTP adapt. (There may be other reasons as > well that this is not feasible... I'll rely on my colleagues to fill > in the > gaps) > > The alternative approach is to use the timed-reliability service > provided > by PR-SCTP to indicate that messages that will be retransmitted by the > upper layer after, for example, 5 seconds, should be abandonded by the > transport layer once that 5 seconds has elapsed. Again, this results > in > an actual _reduction_ in "junk data", i.e. a redundant retransmission > of a > particular message X, which in the absence of the PR-SCTP timed > reliabilty > service, ends up appearing more than once in the reliable data stream. > > Therefore, the bottom line is that PR-SCTP helps to keep redundant > data, > or data that has become stale off the network. None of this data was > "junk data" when it was first transmitted, which seems to be one of the > fears or doubts that is being thrown at PR-SCTP. > > > Regards, > Phill > > -- Phillip Conrad, Asst Professor, CIS Dept. Temple University > -- Philadelphia PA 19122 conrad@acm.org > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 4 14:32:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04040 for ; Fri, 4 Apr 2003 14:32:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34JZgl11321 for tsvwg-archive@odin.ietf.org; Fri, 4 Apr 2003 14:35:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34JY8811176; Fri, 4 Apr 2003 14:34:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34JXV811139 for ; Fri, 4 Apr 2003 14:33:31 -0500 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03933 for ; Fri, 4 Apr 2003 14:30:07 -0500 (EST) Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2/8.11.2) with ESMTP id h34JWY115026; Fri, 4 Apr 2003 11:32:34 -0800 (PST) Message-ID: <3E8DDDD5.6020601@isi.edu> Date: Fri, 04 Apr 2003 11:32:37 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Reiner Ludwig CC: tsvwg@ietf.org Subject: Re: [Tsvwg] redundant data - A TFRC Example References: <200304031842.NAA36873@guns.lerc.nasa.gov> <5.2.0.9.0.20030404102651.02c28e28@mailhost.eed.ericsson.se> X-Enigmail-Version: 0.65.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Reiner Ludwig wrote: > I'd like to add an example for people to think about ... > > If you try to run VoIP over TFRC, you'll most likely be disappointed by > the quality. The reason is that when A talks, then (usually) B is > silent, and vice versa. I.e., a talkspurt A>B is followed by a talkspurt > B>A is followed by a talkspurt A>B, .... It seems odd to consider TFRC for this case. VoIP requires communication that is decidedly outside the behavior patterns of TCP; making VoIP TCP-friendly seems bizzare. Padding real data with dummy data for the sole purpose of being TCP-friendly seems even more bizzare. This would interfere with some potentially nice aggregation of VoIP on trunk links. > The "easy fix" is for B to send dummy data (or even potentially useful > data like pictures, ads, calendar sync data, etc.) for the sole purpose > of maintain the TFRC rate above the required coder rate. B would be a > good Internet citizen in the sense that it is always TCP friendly. Sending dummy data to quench other TCPs from getting real work done isn't being a good Internet citizen; it's a denial-of-service attack, of sorts. The real error here, IMO, is considering TCP-friendly to be equivalent to Internet-friendly. There has to be a good definition of the latter, and that is what we should really be striving for. Joe _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 4 15:01:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05173 for ; Fri, 4 Apr 2003 15:01:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34K4lq13862 for tsvwg-archive@odin.ietf.org; Fri, 4 Apr 2003 15:04:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34K4F813833; Fri, 4 Apr 2003 15:04:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34K3R813803 for ; Fri, 4 Apr 2003 15:03:27 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05084 for ; Fri, 4 Apr 2003 15:00:03 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h34K2Tmr014520; Fri, 4 Apr 2003 12:02:29 -0800 (PST) Received: from MRAMALHO-W2K1.cisco.com (dhcp-64-100-135-217.cisco.com [64.100.135.217]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ACY12969; Fri, 4 Apr 2003 12:02:29 -0800 (PST) Message-Id: <4.3.2.7.2.20030404141357.0166ac88@mira-sjc5-9.cisco.com> X-Sender: mramalho@mira-sjc5-9.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 04 Apr 2003 15:02:28 -0500 To: mallman@grc.nasa.gov, tsvwg@ietf.org From: "Michael A. Ramalho" Subject: Re: [Tsvwg] pr-sctp In-Reply-To: <200304041659.LAA58477@guns.lerc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At 11:59 AM 4/4/2003 -0500, Mark Allman wrote: >Michael rightly noted that I wrote a whole lot of ambiguous rubbish >the last time around. Durned context senssative languages. So, I >am going to try again... > > > If such a service definition existed ... there would be *no need* > > for the application to send N times via APF as you suggest. We > > then let PR-SCTP (the transport ... not the application) do the > > "accounting" and it will only send once (if successful) the > > majority of the times .... and only sends N times when it was > > actually unsuccessful for [N-1] prior times. Thus this service > > definition would make PR-SCTP have a "N persistence" property. > > > > This, in my book, is an incentive for the app to behave better > > than sending "N times" in a brute force manner. > >No need, but maybe a desire. > >Say the app sends the same message to the transport twice. The >transport then sends both copies out (in two segments). Now, say >one of these segments gets dropped but the other arrives fine and is >delivered to the receiving app. By some metrics that offers better >performance than the case when the sending app gives the sending >transport only one copy and lets the transport retransmit as >necessary (which adds an extra ~RTT before the receiving app gets >the data). Ok. Now I get your point. You are specifically looking at "delay performance" ... not other "performance metrics". >If the sender has to waste its own resources (buffer >space, cwnd space, etc.) to retransmit the lost segment (that is now >useless) then I think there is *some* incentive against using such a >brute force method. If the sender can say "oh, nevermind on that >lost segment" and clean up our own resources then it seems like >there is no incentive not to waste network resources if one wanted >lots of redundancy. You have a point if you desire/need redundancy AND delay performance less than an RTT. Obviously any (partially) reliable transport protocol can't do that job without being (knowingly) wasteful (i.e., sending data twice). I think these applications - by design necessity - need application layer design (e.g., FEC on voice packets). But even the vast majority of non-interactive streaming applications could benefit from an additional playout delay of a few RTTs .... and use either the "timed reliability" or "N persistence" flavors of PR-SCTP. For these applications ... let the transport layer use the resources (buffer space, etc.) profitably and let it discard "stale information". To do otherwise, the application needs to get as smart as the average tsvwg'er. >I hope that is a bit more clear. Sorry for any confusion I caused. Got it this time .. thanks. Michael Ramalho >allman > > >-- >Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 4 15:16:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06867 for ; Fri, 4 Apr 2003 15:16:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34KJle15323 for tsvwg-archive@odin.ietf.org; Fri, 4 Apr 2003 15:19:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34KIn815295; Fri, 4 Apr 2003 15:18:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34KHF815253 for ; Fri, 4 Apr 2003 15:17:15 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06617 for ; Fri, 4 Apr 2003 15:13:50 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h34KKK506862 for ; Fri, 4 Apr 2003 23:20:20 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 4 Apr 2003 23:16:18 +0300 Received: from danh02-nrcws56.americas.nokia.com ([172.19.62.56]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 4 Apr 2003 23:16:18 +0300 Subject: Re: [Tsvwg] redundant data - A TFRC Example From: Yogesh Prem Swami To: ext Reiner Ludwig Cc: tsvwg@ietf.org In-Reply-To: <5.2.0.9.0.20030404102651.02c28e28@mailhost.eed.ericsson.se> References: <200304031842.NAA36873@guns.lerc.nasa.gov> <5.2.0.9.0.20030404102651.02c28e28@mailhost.eed.ericsson.se> Content-Type: text/plain Organization: Nokia Research Center, Dallas Message-Id: <1049487376.6687.155.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 04 Apr 2003 14:16:16 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Apr 2003 20:16:18.0365 (UTC) FILETIME=[0D14C6D0:01C2FAE7] Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Reiner, On Fri, 2003-04-04 at 02:52, ext Reiner Ludwig wrote: > I'd like to add an example for people to think about ... > > If you try to run VoIP over TFRC, you'll most likely be disappointed by the > quality. The reason is that when A talks, then (usually) B is silent, and > vice versa. I.e., a talkspurt A>B is followed by a talkspurt B>A is > followed by a talkspurt A>B, .... > > While B is silent and if the talkspurt from A is long enough then B's TFRC > send rate will decay to zero (or at least often enough below the required > coder rate). Andrei Gurtov did this experiment and told me how 'broken' > such a voice conversation becomes. > The conversation will be equally "broken" if you don't follow TFRC in this case. Sending a lot of data (after waiting for a long time) does not necessarily mean that the quality will improve--the data also need to reach the receiver. TFRC tries its best to send only as much data as will safely reach the sender after a given time. What's worse in case of not following TFRC is that it might force some TCP connections to timeout. BTW, if a connection has waited for such a long time that it's data rate is so low, why can't it wait a little longer and buffer the data on the receiver side before plying it out. This should mitigate the problem if not solve it sompletely. (Please note rate reduction happends every RTO, which is several times the RTT.) I think TFRC (along with DCCP) does a great job. > The "easy fix" is for B to send dummy data (or even potentially useful data > like pictures, ads, calendar sync data, etc.) for the sole purpose of > maintain the TFRC rate above the required coder rate. B would be a good > Internet citizen in the sense that it is always TCP friendly. Still, B is > sending data it does't have to send necessarily. > You need to define 'necessary' here. Let's take a different example. Say there are 10 people on a LAN which are accessing the same web page. This is also an example of 'unnecessary' data. So should the transport layer now worry about these things too. If I am sitting on a fiber cable, I won't be able to tell whether the data for different web clients is unncessary or whether the data from TFRC is unnecessary. How do we draw the line here. > Should the IETF set up rules that would limit the sending of such > potentially useless data? Do we have hope that such rules would be obeyed > by application and protocol designers? > > I could imagine VoIP application designers that would let themselves be > convinced to move away from uncontrolled UDP to RTP/DCCP, but probably not > much further. I.e., their view could be: "We ensure that our flows behave > TCP friendly, but what we do with the available bandwidth is our business." > That's fine as far as transport layer is concerned. Application protocols desiners, who're as concerned about bandwidth as transport layer protocol designers are, will certainly find the best approach (for example, if the sustainable delay before playout is T = x*RTO, then the application will be happy not to send any 'unnecessary' data until Xth RTO. Okay that's not the right calculation, but you get the idea...) These issues are upto the application to figure out. The transport layer should not worry about them, IMO. --yogesh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 4 15:31:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07300 for ; Fri, 4 Apr 2003 15:31:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34KYiv16254 for tsvwg-archive@odin.ietf.org; Fri, 4 Apr 2003 15:34:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34KY7816207; Fri, 4 Apr 2003 15:34:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34KX4816133 for ; Fri, 4 Apr 2003 15:33:04 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07216 for ; Fri, 4 Apr 2003 15:29:39 -0500 (EST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id EB03B328D5; Fri, 4 Apr 2003 15:32:08 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 0981932897; Fri, 4 Apr 2003 15:32:07 -0500 (EST) Date: Fri, 4 Apr 2003 15:32:06 -0500 (EST) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Yogesh Prem Swami Cc: Subject: Re: [Tsvwg] redundant data - A TFRC Example In-Reply-To: <1049487376.6687.155.camel@atcp01.americas.nokia.com> Message-ID: X-Spam-Status: No, hits=-5.0 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On 4 Apr 2003, Yogesh Prem Swami wrote: > BTW, if a connection has waited for such a long time that it's data rate > is so low, why can't it wait a little longer and buffer the data on the > receiver side before plying it out. Because his traffic example was VoIP, but as Joe pointed out... VoIP is probably not a good example. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 4 15:41:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07447 for ; Fri, 4 Apr 2003 15:41:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34KiqB17508 for tsvwg-archive@odin.ietf.org; Fri, 4 Apr 2003 15:44:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34KiB817486; Fri, 4 Apr 2003 15:44:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Khn817420 for ; Fri, 4 Apr 2003 15:43:49 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07415 for ; Fri, 4 Apr 2003 15:40:22 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h34Kkq518059 for ; Fri, 4 Apr 2003 23:46:52 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 4 Apr 2003 23:42:49 +0300 Received: from danh02-nrcws56.americas.nokia.com ([172.19.62.56]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 4 Apr 2003 23:42:49 +0300 Subject: Re: [Tsvwg] redundant data - A TFRC Example From: Yogesh Prem Swami To: "Armando L. Caro Jr." Cc: tsvwg@ietf.org In-Reply-To: References: Content-Type: text/plain Organization: Nokia Research Center, Dallas Message-Id: <1049488967.6917.2.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 04 Apr 2003 14:42:47 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Apr 2003 20:42:49.0798 (UTC) FILETIME=[C1A62E60:01C2FAEA] Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Fri, 2003-04-04 at 14:32, ext Armando L. Caro Jr. wrote: > On 4 Apr 2003, Yogesh Prem Swami wrote: > > > BTW, if a connection has waited for such a long time that it's data rate > > is so low, why can't it wait a little longer and buffer the data on the > > receiver side before plying it out. > > Because his traffic example was VoIP, but as Joe pointed out... VoIP is > probably not a good example. > To the best of my knowlege, even VoIP data needs to be buffered if for no other reason than to get rid of jitter. Of course how long it needs to wait is a different question. --yogesh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 4 16:29:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08752 for ; Fri, 4 Apr 2003 16:29:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34LWPq20367 for tsvwg-archive@odin.ietf.org; Fri, 4 Apr 2003 16:32:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34LVW820320; Fri, 4 Apr 2003 16:31:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34LUN820206 for ; Fri, 4 Apr 2003 16:30:23 -0500 Received: from web10903.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08661 for ; Fri, 4 Apr 2003 16:26:56 -0500 (EST) Message-ID: <20030404212926.64283.qmail@web10903.mail.yahoo.com> Received: from [12.237.229.250] by web10903.mail.yahoo.com via HTTP; Fri, 04 Apr 2003 13:29:26 PST Date: Fri, 4 Apr 2003 13:29:26 -0800 (PST) From: Spencer Dawkins Subject: Re: [Tsvwg] redundant data - A TFRC Example To: tsvwg@ietf.org In-Reply-To: <1049488967.6917.2.camel@atcp01.americas.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Hi, Yogesh, --- Yogesh Prem Swami wrote: > > To the best of my knowlege, even VoIP data needs to be > buffered if for > no other reason than to get rid of jitter. Of course how long > it needs > to wait is a different question. Yeah, but - "buffering" is relative, as you point out - buffering streaming traffic for 50-ms for a less-jittery playout isn't the order of magnitude we talk about for end-to-end transport roundtrip times, right? People start noticing things at about 100-200 ms - if you start to talk and the other person doesn't stop talking for 400 ms because the voice stream was buffered, most people find this disconcerting. It's something closer to "push-to-talk" than voice traffic we know and love... Spencer _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 4 16:35:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08930 for ; Fri, 4 Apr 2003 16:35:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34Lcks21506 for tsvwg-archive@odin.ietf.org; Fri, 4 Apr 2003 16:38:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Lc4821479; Fri, 4 Apr 2003 16:38:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34LbC820896 for ; Fri, 4 Apr 2003 16:37:12 -0500 Received: from web10907.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08862 for ; Fri, 4 Apr 2003 16:33:45 -0500 (EST) Message-ID: <20030404213614.13324.qmail@web10907.mail.yahoo.com> Received: from [12.237.229.250] by web10907.mail.yahoo.com via HTTP; Fri, 04 Apr 2003 13:36:14 PST Date: Fri, 4 Apr 2003 13:36:14 -0800 (PST) From: Spencer Dawkins Subject: Re: [Tsvwg] redundant data - A TFRC Example To: tsvwg@ietf.org In-Reply-To: <3E8DDDD5.6020601@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Believe it or not, I don't always post whatever enters my mind. I was trying to think of a way to say what Joe said, much better than any way that I'd come up with, so far: --- Joe Touch wrote: > The real error here, IMO, is considering TCP-friendly to be > equivalent > to Internet-friendly. There has to be a good definition of the > latter, > and that is what we should really be striving for. I'm really curious where a definition of "internet-friendly" would begin, if it's to be different from "TCP-friendly". I'm assuming that reducing sending rates in the face of sustained congestion is the floor we're not willing to go beneath - is there a higher floor that we all agree on? Spencer _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 4 16:54:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09500 for ; Fri, 4 Apr 2003 16:54:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34LvWX22551 for tsvwg-archive@odin.ietf.org; Fri, 4 Apr 2003 16:57:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Lv8822532; Fri, 4 Apr 2003 16:57:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34LuK822480 for ; Fri, 4 Apr 2003 16:56:20 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09424 for ; Fri, 4 Apr 2003 16:52:53 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h34LroN04909 for ; Sat, 5 Apr 2003 00:53:50 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 5 Apr 2003 00:55:22 +0300 Received: from danh02-nrcws56.americas.nokia.com ([172.19.62.56]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sat, 5 Apr 2003 00:55:21 +0300 Subject: Re: [Tsvwg] redundant data - A TFRC Example From: Yogesh Prem Swami To: ext Spencer Dawkins Cc: tsvwg@ietf.org In-Reply-To: <20030404212926.64283.qmail@web10903.mail.yahoo.com> References: <20030404212926.64283.qmail@web10903.mail.yahoo.com> Content-Type: text/plain Organization: Nokia Research Center, Dallas Message-Id: <1049493320.6918.27.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 04 Apr 2003 15:55:20 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Apr 2003 21:55:22.0021 (UTC) FILETIME=[E3C6B550:01C2FAF4] Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Spencer, On Fri, 2003-04-04 at 15:29, ext Spencer Dawkins wrote: > Hi, Yogesh, > > --- Yogesh Prem Swami wrote: > > > > To the best of my knowlege, even VoIP data needs to be > > buffered if for > > no other reason than to get rid of jitter. Of course how long > > it needs > > to wait is a different question. > > Yeah, but - "buffering" is relative, as you point out - > buffering streaming traffic for 50-ms for a less-jittery playout > isn't the order of magnitude we talk about for end-to-end > transport roundtrip times, right? > People start noticing things at about 100-200 ms - if you start > to talk and the other person doesn't stop talking for 400 ms > because the voice stream was buffered, most people find this > disconcerting. It's something closer to "push-to-talk" than > voice traffic we know and love... I completely agree. The point I was trying to make is it's not upto the transport layer to worry about these things. TFRC says: this is what the data rate an application will get. It's upto the application to decide the right strategy to get the data rate it wants. If that requires sending unnecessary data or buffering them, then that's fine as far as transport layer is concerned. --yogesh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sat Apr 5 00:52:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19017 for ; Sat, 5 Apr 2003 00:52:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h355u0n23678 for tsvwg-archive@odin.ietf.org; Sat, 5 Apr 2003 00:56:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h355ja823381; Sat, 5 Apr 2003 00:45:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h355iW823346 for ; Sat, 5 Apr 2003 00:44:32 -0500 Received: from smtp-out.comcast.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18930 for ; Sat, 5 Apr 2003 00:40:55 -0500 (EST) Received: from livingroom.acm.org (pcp01480554pcs.ncstl01.de.comcast.net [68.82.68.240]) by mtaout11.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HCU00FA4VWC68@mtaout11.icomcast.net> for tsvwg@ietf.org; Sat, 05 Apr 2003 00:43:26 -0500 (EST) Date: Sat, 05 Apr 2003 00:43:21 -0500 From: Phillip Conrad Subject: Re: [Tsvwg] pr-sctp In-reply-to: <5.1.0.14.2.20030404140421.03f21908@joda.cis.temple.edu> X-Sender: phillipconrad@mail.comcast.net To: tsvwg@ietf.org Cc: Phillip Conrad Message-id: <5.1.0.14.2.20030405003401.03852488@joda.cis.temple.edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT I want to apologize to Mark Allman for inadvertently responding to a private note on the open list. This was an honest mistake on my part; Mark's note was a response to mine, and so had [tsvwg] in the subject line. I mistakenly concluded that it was an on-list reply; I should have looked more carefully at the header before responding. Sincerely, Phill Conrad _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sat Apr 5 02:48:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02419 for ; Sat, 5 Apr 2003 02:48:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h357pRC09938 for tsvwg-archive@odin.ietf.org; Sat, 5 Apr 2003 02:51:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h357fH809641; Sat, 5 Apr 2003 02:41:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h357dJ809550 for ; Sat, 5 Apr 2003 02:39:19 -0500 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02282 for ; Sat, 5 Apr 2003 02:35:40 -0500 (EST) Received: from isi.edu ([207.151.149.14]) by boreas.isi.edu (8.11.6p2/8.11.2) with ESMTP id h357c8123831; Fri, 4 Apr 2003 23:38:08 -0800 (PST) Message-ID: <3E8E87AC.1090708@isi.edu> Date: Fri, 04 Apr 2003 23:37:16 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Spencer Dawkins CC: tsvwg@ietf.org Subject: Re: [Tsvwg] redundant data - A TFRC Example References: <20030404213614.13324.qmail@web10907.mail.yahoo.com> In-Reply-To: <20030404213614.13324.qmail@web10907.mail.yahoo.com> X-Enigmail-Version: 0.73.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Spencer Dawkins wrote: > Believe it or not, I don't always post whatever enters my mind. > I was trying to think of a way to say what Joe said, much better > than any way that I'd come up with, so far: > > --- Joe Touch wrote: > >>The real error here, IMO, is considering TCP-friendly to be >>equivalent >>to Internet-friendly. There has to be a good definition of the >>latter, >>and that is what we should really be striving for. > > I'm really curious where a definition of "internet-friendly" > would begin, if it's to be different from "TCP-friendly". I'm > assuming that reducing sending rates in the face of sustained > congestion is the floor we're not willing to go beneath - is > there a higher floor that we all agree on? > > Spencer One challenge is the implicit assumption in defining friendliness in terms of rate. For some applications, rate is meaningless. For others, the timescale is critical - one RTT, multiple RTTs, etc. TCP analysis generally assumes sustained offered load, with a goal of generating stable sending rates over many RTTs. For VoIP, those goals don't apply. Here are some initial definitions of Internet-Friendly: - gets 1/Nth of network capacity when there are N flows - not more (fair to others) implicitly allowing the other N-1 flows the whole of the capacity when there is no data to send - not less (fair to self/upper layers) - reacts to known network conditions within 1 RTT the key here is the term "known" - it can't be expected to read minds - adds load in a 'gentle' fashion This might, e.g., allow VoIP to send lots of little bursts, where, e.g., each burst is O(10 packets), where the average sending rate over 100's of RTTs is stable, but need not be over 1 RTT or even 10's of RTTs. That wouldn't be TCP-friendly, but maybe that's because TCP expects that everyone who backs off does so when the congestion occurs (assuming that all connections are constantly active), rather than when they notice it (which may be equally reasonable). Joe _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sat Apr 5 22:36:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20929 for ; Sat, 5 Apr 2003 22:36:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h363dXr08959 for tsvwg-archive@odin.ietf.org; Sat, 5 Apr 2003 22:39:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h363Qm807891; Sat, 5 Apr 2003 22:26:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h363OD807842 for ; Sat, 5 Apr 2003 22:24:13 -0500 Received: from thebe.your-site.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20832 for ; Sat, 5 Apr 2003 22:20:11 -0500 (EST) Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 7FFCE244A15 for ; Sat, 5 Apr 2003 22:22:35 -0500 (EST) Date: Sat, 5 Apr 2003 21:24:36 -0600 From: Caitlin Bestler Subject: Re: [Tsvwg] redundant data - A TFRC Example To: tsvwg@ietf.org X-Priority: 3 In-Reply-To: <3E8E87AC.1090708@isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 4/4/03, Joe Touch wrote: > >One challenge is the implicit assumption in defining >friendliness in terms of rate. For some applications, rate >is meaningless. For others, the timescale is critical - >one RTT, multiple RTTs, etc. > >TCP analysis generally assumes sustained offered load, >with a goal of generating stable sending rates over many >RTTs. For VoIP, those goals don't apply. > >Here are some initial definitions of Internet-Friendly: > > - gets 1/Nth of network capacity when there are N flows > - not more (fair to others) > implicitly allowing the other N-1 > flows the whole of the capacity > when there is no data to send > - not less (fair to self/upper layers) > > - reacts to known network conditions within 1 RTT > the key here is the term "known" - > it can't be expected to read minds > > - adds load in a 'gentle' fashion > >This might, e.g., allow VoIP to send lots of little >bursts, where, e.g., each burst is O(10 packets), where >the average sending rate over 100's of RTTs is stable, but >need not be over 1 RTT or even 10's of RTTs. > >That wouldn't be TCP-friendly, but maybe that's because >TCP expects that everyone who backs off does so when the >congestion occurs (assuming that all connections are >constantly active), rather than when they notice it (which >may be equally reasonable). > ATM QoS differentiates not only the sustained rate, but a peak rate and latency. I'm not suggesting that IP networks are capable of dealing with ATM type controls, but that at least we should recognize the same range of application bandwidth requirements. As you properly point out, all current work is horrendously biased to low-latency sustained throughput. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sun Apr 6 14:40:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02607 for ; Sun, 6 Apr 2003 14:40:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h36IhqM26862 for tsvwg-archive@odin.ietf.org; Sun, 6 Apr 2003 14:43:52 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h36IaN825862; Sun, 6 Apr 2003 14:36:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h36IYR825800 for ; Sun, 6 Apr 2003 14:34:27 -0400 Received: from stewart.chicago.il.us (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02396 for ; Sun, 6 Apr 2003 14:30:05 -0400 (EDT) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8/8.12.3) with ESMTP id h36IVlbY068898; Sun, 6 Apr 2003 13:31:47 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E90648C.2030401@stewart.chicago.il.us> Date: Sun, 06 Apr 2003 12:31:56 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Armando L. Caro Jr." CC: "Michael A. Ramalho" , mallman@grc.nasa.gov, tsvwg@ietf.org Subject: Re: [Tsvwg] pr-sctp References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Armando L. Caro Jr. wrote: > On Wed, 2 Apr 2003, Michael A. Ramalho wrote: > > >>But to be emphatic .... under congestion this is exactly the behavior you want. >>This is because every bit of information you send that the receiver can't >>profitably >>use (because it is stale) is information that is sent *before more useful >>information*. >>Therefore the process of re-sending stale information is *delaying* the >>sending of >>useful information (potentially making it stale also ... under extended >>congestion >>episodes). > > > I agree with the concept of PR-SCTP. I want to emphasize that bundling > FTSNs with data should be done whenever possible. I think that sending a > FTSN in a packet of its own is not much better than re-sending the stale > data. Both will be triggered at the same point. Both will take the same > time to reach the receiver. And if lost, both suffer the same > consequences. The only improvement is that flightsize gets reduced and new > data may be sent. > > Section 3.5 F2) emphasizes that bundling should be done, but just > wondering out loud... should PR-SCTP implementations reserve room > for FTSNs in all packets. If data chunks are not fragmented properly > when queued, then SCTP cannot refragment them later when bundling > is needed. The draft says that a sender MAY wait to bundle FTSNs, but is > this wording loose enough to allow SCTP to wait for newly queued data to > bundle with. In other words, data already queued may be fragmented too > large for bundling, but newly queued data may be fragmented small enough > for bundling. ...I don't think I like this idea. Maybe simply reserving > room for some minimum FTSN size is good enough. > You have the same issue with SACK's as well... one might be wise when implementing to set the fragmentation point SCTP uses to be small enough for a minimal SACK OR a F-TSN.. > >>Note: The congestion condition is not simply characterized by loss .... but >>additionally by duration (in time) of the congestion event (as this has an >>effect on "staleness"). We need to consider the time/delay element in >>the congestion episode. > > > I don't follow how this relates to FTSNs. > > >>In this thought process we might consider other PR-SCTP service definitions >>that are more appropriate to the applications to consider under >>overload or congestion scenarios. The creation of other pr-sctp service >>definition >>to help "govern" the sending of data would be welcome. However, the F-TSN >>mechanism is the only thing required "on the wire" for PR-SCTP. > > > I like that the PR-SCTP mechanism is independent of the service > definition. However, I cannot think of applications that could use > anything but timed-reliability. > I can, one great use would be for applications such as IP-Fix... where I "want" to get data across on peg counts but if my router that is reporting the information gets TOO busy I would prefer to drop some of the peg counts .. too busy being to much memory allocated to the "peg" counts... at the same time there are things like templates that MUST make it across... Note no time is involved.. it has to do with buffering capacity of the router and busy-ness.. We will be working internally at cisco in getting a prototype up in IOS that uses PR-SCTP shortly.. if I can ever stop traveling :-0 R > ~armando > > 0-- --0 > | Armando L. Caro Jr. | Protocol Engineering Lab | > | www.cis.udel.edu/~acaro | University of Delaware | > 0-- --0 > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sun Apr 6 17:26:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06577 for ; Sun, 6 Apr 2003 17:26:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h36LUOf03965 for tsvwg-archive@odin.ietf.org; Sun, 6 Apr 2003 17:30:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h36LMe803679; Sun, 6 Apr 2003 17:22:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h36LLP803651 for ; Sun, 6 Apr 2003 17:21:25 -0400 Received: from stewart.chicago.il.us (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06415 for ; Sun, 6 Apr 2003 17:17:01 -0400 (EDT) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8/8.12.3) with ESMTP id h36LJCbY069085; Sun, 6 Apr 2003 16:19:16 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E908BC9.4010009@stewart.chicago.il.us> Date: Sun, 06 Apr 2003 15:19:21 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@grc.nasa.gov CC: "Michael A. Ramalho" , tsvwg@ietf.org Subject: Re: [Tsvwg] pr-sctp References: <200304041659.LAA58477@guns.lerc.nasa.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mark Allman wrote: > Michael rightly noted that I wrote a whole lot of ambiguous rubbish > the last time around. Durned context senssative languages. So, I > am going to try again... > > >>If such a service definition existed ... there would be *no need* >>for the application to send N times via APF as you suggest. We >>then let PR-SCTP (the transport ... not the application) do the >>"accounting" and it will only send once (if successful) the >>majority of the times .... and only sends N times when it was >>actually unsuccessful for [N-1] prior times. Thus this service >>definition would make PR-SCTP have a "N persistence" property. >> >>This, in my book, is an incentive for the app to behave better >>than sending "N times" in a brute force manner. > > > No need, but maybe a desire. > > Say the app sends the same message to the transport twice. The > transport then sends both copies out (in two segments). Now, say > one of these segments gets dropped but the other arrives fine and is > delivered to the receiving app. By some metrics that offers better > performance than the case when the sending app gives the sending > transport only one copy and lets the transport retransmit as > necessary (which adds an extra ~RTT before the receiving app gets > the data). If the sender has to waste its own resources (buffer > space, cwnd space, etc.) to retransmit the lost segment (that is now > useless) then I think there is *some* incentive against using such a > brute force method. If the sender can say "oh, nevermind on that > lost segment" and clean up our own resources then it seems like > there is no incentive not to waste network resources if one wanted > lots of redundancy. > Mark: I think I understand your point but I don't see how PR-SCTP encourages an application designer to send extra data... Lets say I send two copies of packet X in the hopes of getting it through with an application sequence number.... Now what have I done with PR-SCTP ... taken up twice the amount of cwnd space... each copy eats into how much I can send. My problem is I am missing the incentive for this bad behavior that PR-SCTP provides.. The dis-incentive for this behavior you mention is head of line blocking (for TCP).. but what is my dis-incentive for unordered SCTP? The same for PR-SCTP, if I send it twice I eat up twice my cwnd this is the only dis-incentive that I can see and PR-SCTP does not change compared to SCTP-unordered.... Am I missing a dis-incentive... or to flip the coin.. an incentive to send extra non-needed data... I don't see it... If I really am going to send each 'packet X' twice.. I can do the same thing with SCTP/Un-ordered, UDP or DCP... I agree that TCP has the extra dis-incentive of head of line blocking, but semi-ordered SCTP and unordered SCTP do not have this problem. For example take away unordered SCTP and I the application designer will setup 100 streams in SCTP. Send copy 1 of Packet X on stream 0, send the next copy on stream 1. Then send Packet Y on stream 2 and copy on stream 3.. etc. Again.. what is my dis-incentive for the above behavior? I eat up cwnd of my association. Even in TCP I can do the above... setup multiple connections and then not only do I get the ability to replicate everything down the second connection.. I can also get two sets of cwnd's. Am I missing something in your side of the bolgna? I just can't find the incentive for bad behavior over what is already out there... R > I hope that is a bit more clear. Sorry for any confusion I caused. > > allman > > > -- > Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Apr 7 00:26:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13874 for ; Mon, 7 Apr 2003 00:26:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h374U8U27802 for tsvwg-archive@odin.ietf.org; Mon, 7 Apr 2003 00:30:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h374J5827464; Mon, 7 Apr 2003 00:19:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h374HX827427 for ; Mon, 7 Apr 2003 00:17:33 -0400 Received: from pop-3.dnv.wideopenwest.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13636 for ; Mon, 7 Apr 2003 00:13:00 -0400 (EDT) Received: from thoth.ir.bbn.com (d53-66-209.clv.wideopenwest.com [64.53.209.66]) by pop-3.dnv.wideopenwest.com (8.11.6/8.11.6) with ESMTP id h374gVl06822; Sun, 6 Apr 2003 23:42:31 -0500 Received: from thoth.ir.bbn.com (localhost [127.0.0.1]) by thoth.ir.bbn.com (8.12.6p2/8.12.6) with ESMTP id h374OuBG043678; Mon, 7 Apr 2003 00:24:56 -0400 (EDT) (envelope-from mallman@thoth.ir.bbn.com) Message-Id: <200304070424.h374OuBG043678@thoth.ir.bbn.com> To: Phillip Conrad From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: tsvwg@ietf.org Subject: Re: [Tsvwg] pr-sctp In-Reply-To: <5.1.0.14.2.20030405003401.03852488@joda.cis.temple.edu> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Lonesome Day Date: Mon, 07 Apr 2003 00:24:56 -0400 X-RAVMilter-Version: 8.4.1(snapshot 20020919) (pop-3.dnv.wideopenwest.com) Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > I want to apologize to Mark Allman for inadvertently responding to > a private note on the open list. > > This was an honest mistake on my part; Mark's note was a response > to mine, and so had [tsvwg] in the subject line. I mistakenly > concluded that it was an on-list reply; I should have looked more > carefully at the header before responding. Thank you, sir. allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Apr 7 04:16:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08648 for ; Mon, 7 Apr 2003 04:16:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h378KFF22229 for tsvwg-archive@odin.ietf.org; Mon, 7 Apr 2003 04:20:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3788O821735; Mon, 7 Apr 2003 04:08:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3787G821223 for ; Mon, 7 Apr 2003 04:07:16 -0400 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07891 for ; Mon, 7 Apr 2003 04:02:37 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h37856I3013196; Mon, 7 Apr 2003 10:05:07 +0200 (MEST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A47Y7J7; Mon, 7 Apr 2003 10:05:07 +0200 Received: from res0010384da36.eed.ericsson.se (rac169pc.edd.ericsson.se [164.48.123.169]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id KAA01556; Mon, 7 Apr 2003 10:05:04 +0200 (MET DST) Message-Id: <5.2.0.9.0.20030407095729.02764c80@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 07 Apr 2003 10:05:07 +0200 To: Joe Touch From: Reiner Ludwig Subject: Re: [Tsvwg] redundant data - A TFRC Example Cc: tsvwg@ietf.org In-Reply-To: <3E8DDDD5.6020601@isi.edu> References: <200304031842.NAA36873@guns.lerc.nasa.gov> <5.2.0.9.0.20030404102651.02c28e28@mailhost.eed.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At 21:32 04.04.2003, Joe Touch wrote: >The real error here, IMO, is considering TCP-friendly to be equivalent to >Internet-friendly. There has to be a good definition of the latter, and >that is what we should really be striving for. I agree 100 percent, since that's exactly the point I wanted to raise when I presented the few slides at the last TSVWG meeting: http://www.cs.helsinki.fi/u/gurtov/reiner/TCP_FEC.pdf http://www.cs.helsinki.fi/u/gurtov/reiner/TCP_FEC.ppt I just tried to paint a bit in black & white hoping that that would provoke some deeper thinking about this :-) But afterall, if I recall right then VoIP was mentioned as one the applications for TFRC in those drafts ... ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Apr 7 08:01:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17873 for ; Mon, 7 Apr 2003 08:01:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37C5Nh04515 for tsvwg-archive@odin.ietf.org; Mon, 7 Apr 2003 08:05:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37BwH804218; Mon, 7 Apr 2003 07:58:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37Bvo804185 for ; Mon, 7 Apr 2003 07:57:50 -0400 Received: from pop-3.dnv.wideopenwest.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17737 for ; Mon, 7 Apr 2003 07:53:07 -0400 (EDT) Received: from thoth.ir.bbn.com (d53-66-209.clv.wideopenwest.com [64.53.209.66]) by pop-3.dnv.wideopenwest.com (8.11.6/8.11.6) with ESMTP id h37CMml29947 for ; Mon, 7 Apr 2003 07:22:48 -0500 Received: from thoth.ir.bbn.com (localhost [127.0.0.1]) by thoth.ir.bbn.com (8.12.6p2/8.12.6) with ESMTP id h37C59BG044586 for ; Mon, 7 Apr 2003 08:05:12 -0400 (EDT) (envelope-from mallman@thoth.ir.bbn.com) Message-Id: <200304071205.h37C59BG044586@thoth.ir.bbn.com> To: tsvwg@ietf.org From: Mark Allman Reply-To: mallman@grc.nasa.gov Organization: BBN Technologies/NASA GRC Song-of-the-Day: Lonesome Day Date: Mon, 07 Apr 2003 08:05:09 -0400 X-RAVMilter-Version: 8.4.1(snapshot 20020919) (pop-3.dnv.wideopenwest.com) Subject: [Tsvwg] pr-sctp -- final thoughts from me Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Folks- I do not want to continue to repeat myself on the list. After reading through this thread and having some on-list and off-list dicussions I am left with the following thoughts/clarifications (/FUD - depending on your viewpoint). * I never said and hopefully did not insinuate that there was no use/need/application for PR-SCTP. So, for all of the folks who have written me enumerating all sorts of applications: I agree, there are compelling apps for PR-SCTP (and, more generally partially reliable transports). I am not advocating throwing the baby out with the bath water. I am wondering about whether we should think about enforcing a little more network friendliness because we can. * Just because a transport sends at a rate that is dictated by CC doesn't mean it's doing so in a terribly useful or friendly manner. Just because a transport is allowed to send at X bps should not give it the right to send just anything at X bps. If lots of the traffic is redundant the transport is using network resources that could be put to better use (to accomplish useful work). In my opinion, *** being a well-behaved transport is not just about sending at the "right" rate. *** (Although, note that sending at the "right" rate is *part* of being network friendly.) * PR-SCTP is network friendly in one sense because it can prevent needless retransmits from being sent (i.e., because an application can no longer use the data). This is a Good Thing. But, if we're using this PR functionality to squeltch a high percentage of messages from being retransmitted then I think we turn this Good Thing into a Bad Thing. Sure, the transport is still preventing needless retransmissions, but at the same time it is acknowledging that it's cluttering up the network with a lot of packets that are not needed. IMO, a little PR is fine, but lots of PR is not. (Where I purposely leave "a little" and "a lot" ambiguous because I don't know how to precisely define them.) * My own personal opinion is there are a number of angles to look at how "network friendly" a transport protocol happens to be. I believe that one aspect of this is how much useless data the transport injects into the network. In this context I believe we need to think about the *incentives* a transport protocol offers to applications using it. In addition, we need to look at the *opportunity* the transport has to police the sending of redundant data. (And, note, that this is not something I have selectivly applied to SCTP. I have explored this in TCP as well. For instance, in work that Ethan Blanton and I have done on making TCP robust to reordering one of the goals is to adjust the duplicate ACK threshold so that TCP does not pollute the network with lots of needless retransmissions that are caused by packet reordering not packet loss. I.e., I am not attempting to disparage only SCTP here. This is a general issue, but I think PR-SCTP is a place to apply anti-pollution strategies.) * I want to discuss several transports in the context of the above bit about incentives and opportunities, since others have brought them up. If we look at UDP I don't think there is any dis-incentive offered by the transport to prevent the application from sending lots of redundant data into the network. If the application sends every message twice in case one of them is lost there is really no transport-level problem with that (i.e., this behavior does not cost the transport anything). But, the flip side is that there is no opportunity for the transport to do anything about it. Each message sent from the application to the transport is just transmitted without any sort of accounting, data naming, etc. So, the transport is ignorant of what is being sent. So, while UDP can be abused by applications that choose to do so, there is pretty much nothing that UDP can do about it. Next, look at TCP (and, really, any ordered, reliable transport). TCP provides a huge dis-incentive for applications to send multiple copies of a message for redundancy purposes. TCP ensures that all copies will arrive -- and in the order the were given to the sending transport by the sending application. There is head-of-line blocking so there is just no good reason to send an application message twice to try to get better performance (via some metric). (Note: TCP itself can be more or less careful about what it resends and then starts getting into these issues. For instance, early retransmit allows for the resending of data with a less robust loss indicator than we currently use. That *could* have the impact of inserting a bunch of useless data into the network in the path that has persistent reordering. This should be prevented.) Next up is unordered, reliable SCTP. In this case, applications can send multiple copies of some message for some possible gain. Since there is no head-of-line blocking it may make sense (performance-wise) for an application to send multiple copies of some message to the transport and then throw any extra copies that arrive at the receiving application in the bit bucket. The dis-incentive provided by the transport in this case is that the extra messages (some of which are useless) take space in buffers, take space in the congestion window and take (re)transmission opportunities from other data. And, all messages take these resources until they are successfully delivered to the receiving transport. Depending on the application these tradeoffs an application designer might think these tradeoffs are worth it and the abuse to the network will happen. But, that is not the whole story. The other side of this variant of SCTP is that the transport is "out of the loop" on what is redundant and what is not. Since all the redundancy is happening in application land (as in the UDP case) SCTP has no real clue about what is going on and therefore has no opportunity to police the stream and prevent redundant data. Finally, we get to PR-SCTP -- where I believe incentive and opportunity finally cross paths. Think of the application passing down multiple copies of the same message to the transport with short lifetimes. So, the job of the extra copies of the message is to "back up" the first and get to the application if the first is lost (quicker than a retransmission of the first could). Now the transport is giving an incentive to the application to do this and has an opportunity to prevent excessive (ab)use of it. The dis-incentive to do this is quite similar to the case above for unordered, reliable SCTP -- that is, the redundant data takes cwnd space, buffer space and transmission opportunities. But, PR-SCTP goes a step further because the application (in effect) gets to tell the transport to release the resources quickly. So, rather than being required to use these resources until a loss is repaired they can be freed and used for other things. This is a Good Thing in moderation and a Bad Thing in excess, IMO. In my opinion, the dis-incentive for PR-SCTP is *less* than the dis-incentive for unordered SCTP. But, the really important bit that distiguishes PR-SCTP from the unordered, reliable SCTP is that PR-SCTP is "in the loop" and knows exactly what is going on (i.e., which data was sent & lost, but will not be re-sent). And, hence, PR-SCTP can do something about it to prevent excessive (ab)use of the PR mechanism. So, my opinion is still that PR-SCTP *does* provide *incentive* for application abuse *and* yet also has an *opportunity* to police it and to ensure that the use of the PR feature is not excessive. And, I believe that having both of those is the fundemental discriminator between PR-SCTP and all of our previous (popular) transports. * It's been suggested that I am advocating things that can be accomplished with twisting of other protocols (e.g., multiple connection TCP). Well, I am not going on a long rant here -- although it is tempting. ;) In any case, fine, I'll admit that if you twist and warp things they can be abused. So, what? Does that give us the license to produce lousy protocols? Did the fact that mutliple TCP connections viloates standard TCP CC or that UDP does not use CC allow us to design bogus (or no) CC into SCTP? No. The argument that since we can abuse other things we should not have to be careful in the design of PR-SCTP is just bogus. That's the end of my mini-rant -- I am sure you can fill in the rest! :) There is an old tradition in the IETF that says that repeating your argument over-and-over makes you more-and-more correct. I don't buy it (although, alas, sometimes fall into the trap) and so I intend for this to be my last note in this thread (on tsvwg) because I don't think I have said much new in here (but, hopefully, in a more coherent and comprehensive way), or really since the thread started. (Besides, if you have made it this far you're all sick of listening to my bullshit anyway!) I am intersted in hearing what other folk have to say. Thanks for listening, allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Apr 7 08:21:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18305 for ; Mon, 7 Apr 2003 08:21:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37CPCg06006 for tsvwg-archive@odin.ietf.org; Mon, 7 Apr 2003 08:25:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37CF9805661; Mon, 7 Apr 2003 08:15:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37CEK805634 for ; Mon, 7 Apr 2003 08:14:20 -0400 Received: from web10905.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18073 for ; Mon, 7 Apr 2003 08:09:36 -0400 (EDT) Message-ID: <20030407121208.42522.qmail@web10905.mail.yahoo.com> Received: from [12.237.229.250] by web10905.mail.yahoo.com via HTTP; Mon, 07 Apr 2003 05:12:08 PDT Date: Mon, 7 Apr 2003 05:12:08 -0700 (PDT) From: Spencer Dawkins Subject: Re: [Tsvwg] redundant data - A TFRC Example To: tsvwg@ietf.org In-Reply-To: <5.2.0.9.0.20030407095729.02764c80@mailhost.eed.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , We must have gone through Reiner's slides REALLY fast. I was a minute-taker for TSVWG, IIRC, and they didn't sink in during the meeting at all. Unfortunate, because they are an excellent jumping-off-point for the issue we're discussing on this thread. RFC 3448 includes the following text in the abstract: This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best- effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance. So it looks like Reiner is remembering correctly that VoIP was a motivator for TFRC... Spencer --- Reiner Ludwig wrote: > > I agree 100 percent, since that's exactly the point I wanted > to raise when > I presented the few slides at the last TSVWG meeting: > http://www.cs.helsinki.fi/u/gurtov/reiner/TCP_FEC.pdf > http://www.cs.helsinki.fi/u/gurtov/reiner/TCP_FEC.ppt > > I just tried to paint a bit in black & white hoping that that > would provoke > some deeper thinking about this :-) > > But afterall, if I recall right then VoIP was mentioned as one > the > applications for TFRC in those drafts ... > > ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Apr 7 11:59:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24473 for ; Mon, 7 Apr 2003 11:59:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37G3Wt21960 for tsvwg-archive@odin.ietf.org; Mon, 7 Apr 2003 12:03:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37FqS821349; Mon, 7 Apr 2003 11:52:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37FpP821253 for ; Mon, 7 Apr 2003 11:51:25 -0400 Received: from seraph3.grc.nasa.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24168 for ; Mon, 7 Apr 2003 11:46:36 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id B708F6B9EB for ; Mon, 7 Apr 2003 11:49:09 -0400 (EDT) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h37Fn9KV004989 for ; Mon, 7 Apr 2003 11:49:09 -0400 (EDT) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id LAA91705; Mon, 7 Apr 2003 11:49:09 -0400 (EDT) Message-Id: <200304071549.LAA91705@guns.lerc.nasa.gov> To: tsvwg@ietf.org From: Mark Allman Reply-To: mallman@grc.nasa.gov Organization: BBN Technologies/NASA GRC Song-of-the-Day: The Entertainer Date: Mon, 07 Apr 2003 11:49:09 -0400 Subject: [Tsvwg] Re: pr-sctp -- final thoughts from me Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Folks- > I do not want to continue to repeat myself on the list. I did not mean to discourage on-list chat by the above line, which, judging from a couple of private emails I may have done. My point was that I feel like I am repeating myself and so *I* plan to not argue point-by-point any longer. Other SHOULD send thoughts to the list. Sorry for any misunderstanding... allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Apr 7 12:12:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25046 for ; Mon, 7 Apr 2003 12:12:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37GH4N23822 for tsvwg-archive@odin.ietf.org; Mon, 7 Apr 2003 12:17:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37GAC823453; Mon, 7 Apr 2003 12:10:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37G6i822216 for ; Mon, 7 Apr 2003 12:06:44 -0400 Received: from web41808.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24580 for ; Mon, 7 Apr 2003 12:01:54 -0400 (EDT) Message-ID: <20030407160427.27491.qmail@web41808.mail.yahoo.com> Received: from [65.213.193.49] by web41808.mail.yahoo.com via HTTP; Mon, 07 Apr 2003 09:04:27 PDT Date: Mon, 7 Apr 2003 09:04:27 -0700 (PDT) From: CAITR Reply-To: info@caitr.org To: tsvwg@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1491182717-1049731467=:26908" Subject: [Tsvwg] Internetworking 2003: Call for Papers Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , --0-1491182717-1049731467=:26908 Content-Type: text/plain; charset=us-ascii Call for Papers ============== Internetworking 2003, June 22-24, 2003, San Jose, California http://www.caitr.org/internetworking03/index.htm REMINDER: Deadline for submissions is April 11, 2003 The Internetworking 2003 Technical Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following: - Voice over IP (VoIP) - IP Video Conferencing - Storage Area Networks (SANs) - Unicast and Multicast Routing and Convergence - QoS Routing - Network Security and Service Integration - Operational Support Systems - Virtual Private Networks - Internetworking Wireless LANs and 3G Wireless Networks - IP-based Infrastructure for Wireless Networks - Internetworking IP and Optical Networks - Internetworking MPLS with Legacy ATM and Frame Relay Networks - Transition from IPv4 to IPv6 and interworking - Pervasive Computing - High Speed Transport Layer Protocols - Peer to Peer Networking and Grid Computing - Video Teleconferencing (VTC) - 802.11 Hotspots Conference Technical Co-chairs: - Dr. Maurice Gagnaire, ENST, France - Daniel Awduche Technical Program Committee of the Internetworking 2003 Conference: - Roberto Sabella, Erisson - Dr. Moshe Zukerman, Univ. of Melbourne - Nada Golmie, NIST - Dr. Guy Pujolle, LIP6, France - Dr. Samir Tohme, ENST, France - Stefano Trumpy, Italian National Research Council - Dr. Ibrahim Habib, City Univ. of NY - Dr. Vishal Sharma, Metanoia - Dr. Parviz Yegani, Cisco Systems - Dr. G.S. Kuo - Dr. Abbas Jamalipour, Univ. of Sydney - Dr. Hussein Mouftah, Univ. of Ottawa - James Kempf - Elizabeth Rodriguez, Co-chair, IETF Working Group on IP Storage - Dr. Ferit Yegenoglu, Isocore - Dr. Ali Zadeh, George Mason University - Tony Przygienda, Co-chair, IETF Working Group on IS-IS for IP Internets - Ran Canetti, Co-chair, IETF Working Group on Multicast Security --0-1491182717-1049731467=:26908 Content-Type: text/html; charset=us-ascii

Call for Papers
==============

Internetworking 2003, June 22-24, 2003, San Jose, California
http://www.caitr.org/internetworking03/index.htm

REMINDER: Deadline for submissions is April 11, 2003

The Internetworking 2003 Technical Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following:

- Voice over IP (VoIP)
- IP Video Conferencing
- Storage Area Networks (SANs)
- Unicast and Multicast Routing and Convergence
- QoS Routing
- Network Security and Service Integration
- Operational Support Systems
- Virtual Private Networks
- Internetworking Wireless LANs and 3G Wireless Networks
- IP-based Infrastructure for Wireless Networks
- Internetworking IP and Optical Networks
- Internetworking MPLS with Legacy ATM and Frame Relay Networks
- Transition from IPv4 to IPv6 and interworking
- Pervasive Computing
- High Speed Transport Layer Protocols
- Peer to Peer Networking and Grid Computing
- Video Teleconferencing (VTC)
- 802.11 Hotspots

Conference Technical Co-chairs:
- Dr. Maurice Gagnaire, ENST, France
- Daniel Awduche

Technical Program Committee of the Internetworking 2003 Conference:
- Roberto Sabella, Erisson
- Dr. Moshe Zukerman, Univ. of Melbourne
- Nada Golmie, NIST
- Dr. Guy Pujolle, LIP6, France
- Dr. Samir Tohme, ENST, France
- Stefano Trumpy, Italian National Research Council
- Dr. Ibrahim Habib, City Univ. of NY
- Dr. Vishal Sharma, Metanoia
- Dr. Parviz Yegani, Cisco Systems
- Dr. G.S. Kuo
- Dr. Abbas Jamalipour, Univ. of Sydney
- Dr. Hussein Mouftah, Univ. of Ottawa
- James Kempf
- Elizabeth Rodriguez, Co-chair, IETF Working Group on IP Storage
- Dr. Ferit Yegenoglu, Isocore
- Dr. Ali Zadeh, George Mason University
- Tony Przygienda, Co-chair, IETF Working Group on IS-IS for IP Internets
- Ran Canetti, Co-chair, IETF Working Group on Multicast Security

--0-1491182717-1049731467=:26908-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Apr 7 13:59:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29201 for ; Mon, 7 Apr 2003 13:59:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37I3YT31526 for tsvwg-archive@odin.ietf.org; Mon, 7 Apr 2003 14:03:34 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37HrM831170; Mon, 7 Apr 2003 13:53:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37HqK831146 for ; Mon, 7 Apr 2003 13:52:20 -0400 Received: from thebe.your-site.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28987 for ; Mon, 7 Apr 2003 13:47:30 -0400 (EDT) Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 6DF092455A8 for ; Mon, 7 Apr 2003 13:50:11 -0400 (EDT) Date: Mon, 7 Apr 2003 12:52:14 -0500 From: Caitlin Bestler Subject: Re: [Tsvwg] pr-sctp -- final thoughts from me To: tsvwg@ietf.org X-Priority: 3 In-Reply-To: <200304071205.h37C59BG044586@thoth.ir.bbn.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 4/7/03, Mark Allman wrote: > Next, look at TCP (and, really, any ordered, reliable > transport). TCP provides a huge dis-incentive for > applications to send multiple copies of a message for > redundancy purposes. TCP ensures that all copies will > arrive -- and in the order the were given to the sending > transport by the sending application. There is > head-of-line blocking so there is just no good reason to > send an application message twice to try to get better > performance (via some metric). (Note: TCP itself can be > more or less careful about what it resends and then > starts getting into these issues. For instance, early > retransmit allows for the resending of data with a less > robust loss indicator than we currently use. That > *could* have the impact of inserting a bunch of useless > data into the network in the path that has persistent > reordering. This should be prevented.) TCP is actually fully compatabible with this type of cheating, without any cost to the abusive sender. The sender simply opens multiple redundant connections (leaving even less capacity for those pesky other users). The same TCP segments are then sent on all paths. Once *any* connection has acked material, the sender simply discards the buffers. The retention is based on the *fastest* ack, not the slowest. Any connection that ultimately needs the now missing data is simply reset, and then re-established. More network traffic, but what's that compared to our reckless applications buffer space? It takes time, so better have *several* spare connections. As you already concede, UDP does not have the ability to detect redundant data transmission by the application. Therefore it is fully compatible with abusive programs. Most uses of PR-SCTP would have otherwise used UDP, not TCP or SCTP. So there is certainly no redudction in the networks ability to prevent abusive traffic. Beyond that, what change would be made anyway? And more importantly, wouldn't it be strictly a local interface question? The wire messages that invalidate the need to wait for previously sent data chunks do not cite a reason. Whatever safety checks/guidelines might be agreed upon, they will not be wire visisble. I am also skeptical that any useful policies could be drafted with any teath beyond "SHOULD NOT"s. It is very hard to encode real-time enforcement that NEVER has a false positive. And any real-time enforcement MUST NOT block ANY legitimate practice (no matter how strange). Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Apr 8 09:49:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09986 for ; Tue, 8 Apr 2003 09:49:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38Ds3O26396 for tsvwg-archive@odin.ietf.org; Tue, 8 Apr 2003 09:54:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Dph826216; Tue, 8 Apr 2003 09:51:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38DoB826146 for ; Tue, 8 Apr 2003 09:50:11 -0400 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09883 for ; Tue, 8 Apr 2003 09:44:55 -0400 (EDT) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h38DlPgE021936; Tue, 8 Apr 2003 06:47:25 -0700 (PDT) Received: from MRAMALHO-W2K1.cisco.com (dhcp-64-100-135-217.cisco.com [64.100.135.217]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADA32077; Tue, 8 Apr 2003 06:47:23 -0700 (PDT) Message-Id: <4.3.2.7.2.20030407164552.0166bf08@mira-sjc5-9.cisco.com> X-Sender: mramalho@mira-sjc5-9.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 Apr 2003 09:47:22 -0400 To: mallman@grc.nasa.gov, tsvwg@ietf.org From: "Michael A. Ramalho" Subject: Re: [Tsvwg] pr-sctp -- final thoughts from me In-Reply-To: <200304071205.h37C59BG044586@thoth.ir.bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Mark, My comments, as promised. Comments are in-line. Michael Ramalho At 08:05 AM 4/7/2003 -0400, Mark Allman wrote: > >Folks- > >I do not want to continue to repeat myself on the list. After >reading through this thread and having some on-list and off-list >dicussions I am left with the following thoughts/clarifications >(/FUD - depending on your viewpoint). > > * I never said and hopefully did not insinuate that there was no > use/need/application for PR-SCTP. So, for all of the folks who > have written me enumerating all sorts of applications: I agree, > there are compelling apps for PR-SCTP (and, more generally > partially reliable transports). > > I am not advocating throwing the baby out with the bath water. > I am wondering about whether we should think about enforcing a > little more network friendliness because we can. > > * Just because a transport sends at a rate that is dictated by CC > doesn't mean it's doing so in a terribly useful or friendly > manner. Just because a transport is allowed to send at X bps > should not give it the right to send just anything at X bps. Let me understand you. I find TCP a form of socialism ... each of N sessions get 1/Nth (on very rough average) of the (bottleneck) bandwidth. You desire to go beyond socialism ... and not allow what you see as *applications created* redundant data ... even if you are within your 1/Nth ... even, perhaps, if you are within the QoS bandwidth you paid a service provider for? Many people would disagree with your point of view here for all "better than best-effort" application environments. I do note that many, if not the majority, of sigtran environments are QoS provisioned. Note: I have no problem with minimizing "redundant data" in a given layer (your transport optimizations examples below). >If > lots of the traffic is redundant the transport is using network > resources that could be put to better use (to accomplish useful > work). In my opinion, *** being a well-behaved transport is not > just about sending at the "right" rate. *** (Although, note that > sending at the "right" rate is *part* of being network > friendly.) OK. This is a "generic goodness" argument .. but is hard or impossible to enforce. If an application has to send twice (or send FEC/redundant information) in order to meet it's delay performance requirements and it is otherwise abiding in a responsible manner (e.g., paid for the bandwidth in a QoS-enabled environment or is otherwise within it's designed transport bounds) .... who are we to say that the application isn't "network friendly"? I, as will be seen below, fully agree with minimizing duplicate data being sent in a given layer (e.g., wholly within transport layer). > * PR-SCTP is network friendly in one sense because it can prevent > needless retransmits from being sent (i.e., because an > application can no longer use the data). This is a Good Thing. > > But, if we're using this PR functionality to squeltch a high > percentage of messages from being retransmitted then I think we > turn this Good Thing into a Bad Thing. Sure, the transport is > still preventing needless retransmissions, but at the same time > it is acknowledging that it's cluttering up the network with a > lot of packets that are not needed. Beauty (of data) is in the eye of the beholder. I view most of the data that pr-sctp decides to do without (because of staleness) *is* data that we would have liked to have received. But given a choice of getting "more relevant data now" or "getting the old, potentially irrelevant, data now ... then the more relevant data even later" ... we choose the former. That does not mean the data which we decide not to re-transmit was "clutter" when it was originally sent. > IMO, a little PR is fine, but lots of PR is not. (Where I > purposely leave "a little" and "a lot" ambiguous because I don't > know how to precisely define them.) > > * My own personal opinion is there are a number of angles to look > at how "network friendly" a transport protocol happens to be. > I believe that one aspect of this is how much useless data the > transport injects into the network. I agree in general. But note you said "transport layer injects" (not "application layer injects"). > In this context I believe we need to think about the > *incentives* a transport protocol offers to applications using > it. In addition, we need to look at the *opportunity* the > transport has to police the sending of redundant data. I'm a little confused here. Your next paragraph describes mechanisms *in the transport layer* to limit the amount of truly useless (re-transmitted) data sent *by the transport layer*. I have no problem with such goals and wholeheartedly agree. But how does the transport layer know of redundant data sent to it by the application? Surely the redundant data need not be identical ... it could have been formatted differently? How would the transport layer know? It is not the transport's job to police this! > (And, note, that this is not something I have selectivly applied > to SCTP. I have explored this in TCP as well. For instance, in > work that Ethan Blanton and I have done on making TCP robust to > reordering one of the goals is to adjust the duplicate ACK > threshold so that TCP does not pollute the network with lots of > needless retransmissions that are caused by packet reordering > not packet loss. I.e., I am not attempting to disparage only > SCTP here. This is a general issue, but I think PR-SCTP is a > place to apply anti-pollution strategies.) > > * I want to discuss several transports in the context of the above > bit about incentives and opportunities, since others have > brought them up. > > If we look at UDP I don't think there is any dis-incentive > offered by the transport to prevent the application from sending > lots of redundant data into the network. If the application > sends every message twice in case one of them is lost there is > really no transport-level problem with that (i.e., this behavior > does not cost the transport anything). But, the flip side is > that there is no opportunity for the transport to do anything > about it. Each message sent from the application to the > transport is just transmitted without any sort of accounting, > data naming, etc. So, the transport is ignorant of what is > being sent. So, while UDP can be abused by applications that > choose to do so, there is pretty much nothing that UDP can do > about it. Agree. > Next, look at TCP (and, really, any ordered, reliable > transport). TCP provides a huge dis-incentive for applications > to send multiple copies of a message for redundancy purposes. > TCP ensures that all copies will arrive -- and in the order the > were given to the sending transport by the sending application. > There is head-of-line blocking so there is just no good reason > to send an application message twice to try to get better > performance (via some metric). As noted previously ... an application could open multiple TCP connections, though. Not only would this increase the probability that the message got there with one-way delay, it would also double it's "share" of the bandwidth (assuming two TCP connections) and resources (ports, etc.). We both agree this is bad - and that there is *nothing* we can do about it from an *applications enforcement* perspective. The transport layer cannot be expected to "police" for this redundant data. Store this thought for use later. >(Note: TCP itself can be more or > less careful about what it resends and then starts getting into > these issues. For instance, early retransmit allows for the > resending of data with a less robust loss indicator than we > currently use. That *could* have the impact of inserting a > bunch of useless data into the network in the path that has > persistent reordering. This should be prevented.) > > Next up is unordered, reliable SCTP. In this case, applications > can send multiple copies of some message for some possible gain. Of course, unordered reliable SCTP was designed for messages that were *uncorrelated* ... you are trying to "abuse" the very premise of design for unordered service (via 100% correlated messages). Are you suggesting that because it *can* be abused ... that it shouldn't exist for the services or applications that it was designed for? I don't think so ... but I'd like to find the alternative. > Since there is no head-of-line blocking it may make sense > (performance-wise) for an application to send multiple copies of > some message to the transport and then throw any extra copies > that arrive at the receiving application in the bit bucket. The incentive *only exists* if the SCTP session *isn't presently using it's fair share*. If it is ... then there is the appropriate disincentive ..... less throughput/goodput and potentially more delay of the "other" information. To me ... this is an even greater *disincentive*. Be "greedy" and it "hurts you more" during the congestion episode! Exactly when you need performance ... your greediness hurts you! I fail to see why you think this is an incentive for bad applications behavior; as the application is "punished" via poorer (average) performance when the going gets tough. I understand your desire to minimize "redundant information" for generic goodness purposes .... but just like we can't mandate non use of some of the present day RTP/UDP tricks ... we can't mandate that applications can't do this. Applications that do as you suggest can potentially get better performance during non-congestion periods in exchange for poorer performance during congestion episodes. But at least they can't use more than their fair share *during congestion* if they use SCTP. This seems like pretty optimal behavior ... when the going "gets tough" ... you protect "the network". When the network has excess capacity, you live with some bad apples. >The > dis-incentive provided by the transport in this case is that the > extra messages (some of which are useless) take space in > buffers, take space in the congestion window and take > (re)transmission opportunities from other data. And, all > messages take these resources until they are successfully > delivered to the receiving transport. Depending on the > application these tradeoffs an application designer might think > these tradeoffs are worth it and the abuse to the network will > happen. But ... unlike the multiple TCP case ... it still only uses it's (singular) fair share of the bandwidth. > But, that is not the whole story. The other side of > this variant of SCTP is that the transport is "out of the loop" > on what is redundant and what is not. Since all the redundancy > is happening in application land (as in the UDP case) SCTP has > no real clue about what is going on and therefore has no > opportunity to police the stream and prevent redundant data. True. It isn't the transport's job to police the data. SCTP doesn't see the data as "redundant" .... and it still doesn't use more than it's share of the bandwidth. > Finally, we get to PR-SCTP -- where I believe incentive and > opportunity finally cross paths. Think of the application > passing down multiple copies of the same message to the > transport with short lifetimes. Call me dense ... but if you have a few RTT's to get the data across ... I still don't understand why you would do this? Because ... if you have a few RTT's ... you would only send it once with the appropriate lifetime. If you do not have a few RTT's and you really should be using UDP/DCCP with the appropriate FEC. Am I wrong in thinking that you are attempting to "abuse" PR-SCTP in a manner in which no transport protocol can protect against? If you try to formulate a mechanism in which the transport polices the application layer information to make sure that it is not sending redundant information - what you are suggesting is a clear layer violation. I have no problem with the TCP fast/quick restart tweaks you mentioned previously ... as they were fixes entirely *within* the transport layer. >So, the job of the extra copies > of the message is to "back up" the first and get to the > application if the first is lost (quicker than a retransmission > of the first could). Now the transport is giving an incentive > to the application to do this and has an opportunity to prevent > excessive (ab)use of it. Even if an "application abuser" did this ... there is still less incentive than multiple TCP sessions .. and a disincentive during congestion episodes (as above). >The dis-incentive to do this is quite > similar to the case above for unordered, reliable SCTP -- that > is, the redundant data takes cwnd space, buffer space and > transmission opportunities. But, PR-SCTP goes a step further > because the application (in effect) gets to tell the transport > to release the resources quickly. So, rather than being > required to use these resources until a loss is repaired they > can be freed and used for other things. Yes. By design. >This is a Good Thing in > moderation and a Bad Thing in excess, IMO. In my opinion, the > dis-incentive for PR-SCTP is *less* than the dis-incentive for > unordered SCTP. OK. Now you send multiple identical messages with shorter lifetimes. Let's look at the two cases. Case One: Lifetimes greater than a few RTTs. There is *no incentive* to do this ... as a singular message would make it under reasonable packet error conditions. Case Two: Lifetimes on the order of a two RTTs or less. The case for abuse is there ... but .... PR-SCTP *still* won't use it's fair share of bandwidth. And (PR-)SCTP is still ignorant of whether the data it has been passed is redundant. I fail to see how you can do better than this *without layer violating application <-> transport policing*. >But, the really important bit that distiguishes > PR-SCTP from the unordered, reliable SCTP is that PR-SCTP is "in > the loop" and knows exactly what is going on (i.e., which data > was sent & lost, but will not be re-sent). And, hence, PR-SCTP > can do something about it to prevent excessive (ab)use of the PR > mechanism. > > So, my opinion is still that PR-SCTP *does* provide *incentive* > for application abuse *and* yet also has an *opportunity* to > police it and to ensure that the use of the PR feature is not > excessive. Please explain how PR-SCTP has an opportunity to police without violating the application/transport. I don't quite get this ... and you haven't provided an example of how the transport layer would determine "redundant data". Even if an app "abuses" PR-SCTP in the manner you envision ... it still doesn't get more than it's bandwidth share. >And, I believe that having both of those is the > fundemental discriminator between PR-SCTP and all of our > previous (popular) transports. > > * It's been suggested that I am advocating things that can be > accomplished with twisting of other protocols (e.g., multiple > connection TCP). Well, I am not going on a long rant here -- > although it is tempting. ;) In any case, fine, I'll admit that > if you twist and warp things they can be abused. So, what? > Does that give us the license to produce lousy protocols? Did > the fact that mutliple TCP connections viloates standard TCP CC > or that UDP does not use CC allow us to design bogus (or no) CC > into SCTP? No. The argument that since we can abuse other > things we should not have to be careful in the design of PR-SCTP > is just bogus. That's the end of my mini-rant -- I am sure you > can fill in the rest! :) I'm not trying to be difficult ... I just do not know how to protect against what you seem to object to without layer violation. >There is an old tradition in the IETF that says that repeating your >argument over-and-over makes you more-and-more correct. I don't buy >it (although, alas, sometimes fall into the trap) and so I intend >for this to be my last note in this thread (on tsvwg) because I >don't think I have said much new in here (but, hopefully, in a more >coherent and comprehensive way), or really since the thread >started. (Besides, if you have made it this far you're all sick of >listening to my bullshit anyway!) > >I am intersted in hearing what other folk have to say. > >Thanks for listening, >allman > > >-- >Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg Michael A. Ramalho, Ph.D. Office email: mramalho@cisco.com Personal email: mar42@cornell.edu Office: +1.941.708.4650 Cell: +1.941.544.2844 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Apr 8 10:25:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13476 for ; Tue, 8 Apr 2003 10:25:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38EUc529639 for tsvwg-archive@odin.ietf.org; Tue, 8 Apr 2003 10:30:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38ESC829435; Tue, 8 Apr 2003 10:28:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38ERY829386 for ; Tue, 8 Apr 2003 10:27:34 -0400 Received: from seraph2.grc.nasa.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12694 for ; Tue, 8 Apr 2003 10:22:19 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 52EA0689BC for ; Tue, 8 Apr 2003 10:24:52 -0400 (EDT) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h38EOpKV022996; Tue, 8 Apr 2003 10:24:51 -0400 (EDT) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id KAA05642; Tue, 8 Apr 2003 10:24:51 -0400 (EDT) Message-Id: <200304081424.KAA05642@guns.lerc.nasa.gov> To: tsvwg@ietf.org Cc: "Michael A. Ramalho" From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: Re: [Tsvwg] pr-sctp -- final thoughts from me In-Reply-To: <4.3.2.7.2.20030407164552.0166bf08@mira-sjc5-9.cisco.com> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Pink Houses Date: Tue, 08 Apr 2003 10:24:51 -0400 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Folks- I lied. I am replying to this thread. But, just as a clarification because I chose some unfortunate language in my original note. > Please explain how PR-SCTP has an opportunity to police without > violating the application/transport. I don't quite get this > ... and you haven't provided an example of how the transport layer > would determine "redundant data". It is clear to me from Michael's note that I inter-mixed my examples and my statements of principle too much. The term "redundant data" should have been used in the context of my examples only. What I was advocating was the transport layer policing "junk data" ("useless data", "data never delivered to the recieving application"... pick your favorite). In the case of PR-SCTP the transport knows what information this is by what the application tells the transport and what the transport knows about which bits of data have been lost, retransmitted, not retransmitted, etc. I *was not* advocating any sort of new communication between transport and application. And, I *was not* advocating that the transport should try to mine extra information from the application data passed down. If the policing scheme I was suggesting is a layer viloation then so is PR-SCTP (which I do not believe is the case). allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Apr 8 12:22:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20915 for ; Tue, 8 Apr 2003 12:22:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38GRWI07929 for tsvwg-archive@odin.ietf.org; Tue, 8 Apr 2003 12:27:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38GQi807907; Tue, 8 Apr 2003 12:26:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38GPv807883 for ; Tue, 8 Apr 2003 12:25:57 -0400 Received: from seraph3.grc.nasa.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20873 for ; Tue, 8 Apr 2003 12:20:39 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 3B5576BA40 for ; Tue, 8 Apr 2003 12:23:13 -0400 (EDT) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h38GNCKV006004; Tue, 8 Apr 2003 12:23:12 -0400 (EDT) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id MAA07704; Tue, 8 Apr 2003 12:23:12 -0400 (EDT) Message-Id: <200304081623.MAA07704@guns.lerc.nasa.gov> To: tsvwg@ietf.org Cc: Yogesh Prem Swami , Aaron Falk From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: Re: [Tsvwg] Test environments for congestion response In-Reply-To: <20030307194443.GH15341@isi.edu> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Pink Houses Date: Tue, 08 Apr 2003 12:23:12 -0400 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , [Continuing the slightly off-topic thread... (I'm await my knuckle swat, I suppose).] > You might find this of interest: > > http://www.acm.org/sigcomm/ccr/archive/1999/oct99/allman2.pdf The other day I wrote up a very quick web page to collect documents that give tips on effective research (such as the paper Aaron pointed out). The web page is at: http://roland.grc.nasa.gov/~mallman/tips/ Additional pointers that I have (inadvertently) left off would be very much welcome and appreciated. allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Apr 8 13:14:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22572 for ; Tue, 8 Apr 2003 13:14:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38HJ1W12256 for tsvwg-archive@odin.ietf.org; Tue, 8 Apr 2003 13:19:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38HEE811972; Tue, 8 Apr 2003 13:14:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38HD1811899 for ; Tue, 8 Apr 2003 13:13:01 -0400 Received: from smtp-out.comcast.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22439 for ; Tue, 8 Apr 2003 13:07:42 -0400 (EDT) Received: from livingroom.acm.org (pcp01480554pcs.ncstl01.de.comcast.net [68.82.68.240]) by mtaout08.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HD100JYDBLR60@mtaout08.icomcast.net> for tsvwg@ietf.org; Tue, 08 Apr 2003 13:08:16 -0400 (EDT) Date: Tue, 08 Apr 2003 13:09:33 -0400 From: Phillip Conrad X-Sender: phillipconrad@mail.comcast.net To: tsvwg@ietf.org Message-id: <5.1.0.14.2.20030408130351.03c17d70@joda.cis.temple.edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Subject: [Tsvwg] 6th SCTP Interoperability Testing Event Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Colleagues, The 6th SCTP Interoperability Testing Event (what we used to call by a word pronounced someting like "behkov") will be held Jun 1-8 at the University of Delaware. For more details, go to http://pel.cis.udel.edu/interop. You may also contact Phill Conrad to be placed on a (moderated, no spam) mailing list specifically related to this event. Thanks, Phill Conrad PS: I announced this "tentatively" at the San Francisco IETF, but the event is now "officially on". Hope to see you in Newark DE soon! _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Apr 8 20:12:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09064 for ; Tue, 8 Apr 2003 20:12:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h390HRm13325 for tsvwg-archive@odin.ietf.org; Tue, 8 Apr 2003 20:17:27 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39075812127; Tue, 8 Apr 2003 20:07:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3905P811883 for ; Tue, 8 Apr 2003 20:05:25 -0400 Received: from navgwout.symantec.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08699; Tue, 8 Apr 2003 19:59:58 -0400 (EDT) Received: from navgwout.symantec.com (navgwout [198.6.49.12]) by navgwout.symantec.com (8.11.6+Sun/8.9.3) with SMTP id h3902UI28045; Tue, 8 Apr 2003 17:02:30 -0700 (PDT) Received: from uscu-smtpob01-1.symantec.com ([155.64.74.130]) by navgwout.symantec.com (SAVSMTP 3.0.1.45) with SMTP id M2003040817023014819 ; Tue, 08 Apr 2003 17:02:30 -0700 To: sigtran@ietf.org, tsvwg@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 Message-ID: From: "Ian Barile" Date: Tue, 8 Apr 2003 16:57:41 -0700 X-MIMETrack: Serialize by Router on USCU-SMTPOB01-1/GLOBE-ADMIN/SYMANTEC(Release 5.0.11 |July 24, 2002) at 04/08/2003 05:12:35 PM, Serialize complete at 04/08/2003 05:12:35 PM Content-Type: multipart/alternative; boundary="=_alternative 0000357488256D03_=" Subject: [Tsvwg] SCTP RFC 2960 && draft-ietf-tsvwg-sctpsocket-06.txt Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 0000357488256D03_= Content-Type: text/plain; charset="US-ASCII" To Whom It May Concern: I have recently learned about the proposal of the new transport protocol SCTP and it shows great promise. I am also new to the IETF working group discussions. One of the things that I like about SCTP is that it allows you to use many virtualized streams over a single connection. The possibilities for using this to replace TCP and use the virtualized streams to simplfy parsing bytes streams is excellent. However, in my reading I didn't come across 2 ideas that I thought could add to the flexibility of SCTP and I was wondering if any discussion had occured on these topics. 1. Dynamically adding and removing the number of virtualized streams on a connection. 2. Prioritizing delivery of specific virtualized streams to enhance quality of service. If they have been discussed for the standard and can somone point me to further reading on these topics. Thanks Ian Barile --=_alternative 0000357488256D03_= Content-Type: text/html; charset="US-ASCII"
To Whom It May Concern:

I have recently learned about the proposal of the new transport protocol SCTP and it shows great promise.  I am also new to the IETF working group discussions.  

One of the things that I like about SCTP is that it allows you to use many virtualized streams over a single connection.  The possibilities for using this to replace TCP and use the virtualized streams to simplfy parsing bytes streams is excellent.  However, in my reading I didn't come across 2 ideas that I thought could add to the flexibility of SCTP and I was wondering if any discussion had occured on these topics.  

1.  Dynamically adding and removing the number of virtualized streams on a connection.
2.  Prioritizing delivery of specific virtualized streams to enhance quality of service.

If they have been discussed for the standard and can somone point me to further reading on these topics.

Thanks
Ian Barile --=_alternative 0000357488256D03_=-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Apr 8 21:56:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11713 for ; Tue, 8 Apr 2003 21:56:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h39213v20066 for tsvwg-archive@odin.ietf.org; Tue, 8 Apr 2003 22:01:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h391nT819586; Tue, 8 Apr 2003 21:49:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h391mT819523 for ; Tue, 8 Apr 2003 21:48:30 -0400 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11479; Tue, 8 Apr 2003 21:43:01 -0400 (EDT) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 828313293F; Tue, 8 Apr 2003 21:45:29 -0400 (EDT) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id C4B543293B; Tue, 8 Apr 2003 21:45:28 -0400 (EDT) Date: Tue, 8 Apr 2003 21:45:28 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Ian Barile Cc: , , Gerard Heinz Subject: Re: [Tsvwg] SCTP RFC 2960 && draft-ietf-tsvwg-sctpsocket-06.txt In-Reply-To: Message-ID: X-Spam-Status: No, hits=-5.0 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Tue, 8 Apr 2003, Ian Barile wrote: > bytes streams is excellent. However, in my reading I didn't come across 2 > ideas that I thought could add to the flexibility of SCTP and I was > wondering if any discussion had occured on these topics. > > 1. Dynamically adding and removing the number of virtualized streams on a > connection. I have heard this idea bounced around, but I don't know if anyone has looked into this area. > 2. Prioritizing delivery of specific virtualized streams to enhance > quality of service. Jerry Heinz here at UD is currently investigating the use of prioritized streams. In particular, he is investigating how such a feature could be useful to instant messager applications. However, I don't think he has any papers yet... ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Apr 8 22:37:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12816 for ; Tue, 8 Apr 2003 22:37:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h392gwQ23239 for tsvwg-archive@odin.ietf.org; Tue, 8 Apr 2003 22:42:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h392Z5822094; Tue, 8 Apr 2003 22:35:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h392VI821940 for ; Tue, 8 Apr 2003 22:31:18 -0400 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12499; Tue, 8 Apr 2003 22:25:47 -0400 (EDT) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h392SVtc028622; Tue, 8 Apr 2003 19:28:31 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id TAA02098; Tue, 8 Apr 2003 19:25:40 -0700 (MST)] Received: from motorola.com (d50-38cd.cig.mot.com [160.47.56.205]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 2DANMMNZ; Tue, 8 Apr 2003 21:27:30 -0500 Message-ID: <3E93840F.4AEB0E77@motorola.com> Date: Tue, 08 Apr 2003 21:23:11 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Armando L. Caro Jr." CC: Ian Barile , sigtran@ietf.org, tsvwg@ietf.org, Gerard Heinz Subject: Re: [Tsvwg] SCTP RFC 2960 && draft-ietf-tsvwg-sctpsocket-06.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit "Armando L. Caro Jr." wrote: .. > > 1. Dynamically adding and removing the number of virtualized streams on a > > connection. > > I have heard this idea bounced around, but I don't know if anyone has > looked into this area. This was debated at length during the development of SCTP and at the end we reached the consensus that the complexity of adding this feature outweighed the value it could bring. For example, if one ever would be in a situation where additional streams is needed, one could always open more at the assoc initialization since the cost of maintaining extra streams is close to null. Similarly, there seems to be no good reason that one would need to remove stream that are no longer in use. regards, -Qiaobing _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 9 05:20:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19102 for ; Wed, 9 Apr 2003 05:20:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h399Pmv27799 for tsvwg-archive@odin.ietf.org; Wed, 9 Apr 2003 05:25:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h399Im827476; Wed, 9 Apr 2003 05:18:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h399G0827393 for ; Wed, 9 Apr 2003 05:16:00 -0400 Received: from ns.unisa.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18862 for ; Wed, 9 Apr 2003 05:10:21 -0400 (EDT) Received: from fw-2 (dmz2.unisa.it [193.205.160.61]) by ns.unisa.it (8.12.8/8.12.0) with SMTP id h399Ch4R007887 for ; Wed, 9 Apr 2003 11:12:43 +0200 (MET DST) Received: from ([193.205.164.89]) by fw-2; Wed, 09 Apr 2003 10:09:13 +0200 (CEST) From: giuseppe To: tsvwg@ietf.org Content-Type: text/plain Message-Id: <1049879292.5278.11.camel@cori17> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 09 Apr 2003 11:08:12 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] again load sharing Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit HI. I am investigating the opportunity of load sharing in SCTP. One of the thing I not undertand is when the load sharing is effective. There are situations in which load sharing is effective? Second, is there anyone who is attempting to response to this question: when two links are un-shared? In my opinion two link are unshared when they do not cross same Point Of Congestion. So, detecting at run-time this event is a very hard challenge.... Giuseppe De Marco -- Giuseppe De Marco Departement of Electrical and Information Engineering University of Salerno Italy SA via ponte don Melillo 1 Fisciano SA tel: +39 089 964012 mail: gdemarco@unisa.it _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 9 05:57:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19783 for ; Wed, 9 Apr 2003 05:57:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h39A2ch30168 for tsvwg-archive@odin.ietf.org; Wed, 9 Apr 2003 06:02:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h399tM829909; Wed, 9 Apr 2003 05:55:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h399qO829802 for ; Wed, 9 Apr 2003 05:52:24 -0400 Received: from gw.openss7.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19619 for ; Wed, 9 Apr 2003 05:46:45 -0400 (EDT) Received: from ns.pigworks.openss7.net (IDENT:AykVsAnsSTRQsG5PEfpjydC08gLjRcEQ@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h399nI919934; Wed, 9 Apr 2003 03:49:18 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h399nIt13774; Wed, 9 Apr 2003 03:49:18 -0600 Date: Wed, 9 Apr 2003 03:49:18 -0600 From: "Brian F. G. Bidulock" To: giuseppe Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] again load sharing Message-ID: <20030409034918.B12896@openss7.org> Reply-To: bidulock@openss7.org References: <1049879292.5278.11.camel@cori17> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <1049879292.5278.11.camel@cori17>; from gdemarco@unisa.it on Wed, Apr 09, 2003 at 11:08:12AM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit giuseppe, On Wed, 09 Apr 2003, giuseppe wrote: > HI. I am investigating the opportunity of load sharing in SCTP. One of > the thing I not undertand is when the load sharing is effective. There > are situations in which load sharing is effective? Load sharing is effective in any situation where both the available bandwidth of the network and the offered load exceeds the available bandwidth of any one interface. (Or a similar situation with regard to latency if latency is of concern.) OTOH the algorithm for load sharing can have interactions with SCTP protocol mechanisms (retransmission, gaps, SACKs, bundling) and could reduce efficiency in some circumstances depdending on network conditions. IMO algorithms that more closely correspond to SCTP's "primary" destination approach will have more success than those that deviate widely from it. All other factors equal, a sender should not load-share to a secondary destination until the primary destiation's congestion window has been sent. This or similar procedures should have the effect of grouping as many sequential TSNs as possible to the same destination, avoiding excess gap detection and reporting due to difference or variance in OWT between destinations over which traffic is being loadshared. > Second, is there anyone who is attempting to response to this question: > when two links are un-shared? In my opinion two link are unshared when > they do not cross same Point Of Congestion. So, detecting at run-time > this event is a very hard challenge.... SCTP's congestion procedures do not make assuptions about the underlying network and are resilient to network changes independent of network topology. Where is the challenge? --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 9 08:21:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25347 for ; Wed, 9 Apr 2003 08:21:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h39CR4x07687 for tsvwg-archive@odin.ietf.org; Wed, 9 Apr 2003 08:27:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39CIR807268; Wed, 9 Apr 2003 08:18:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39CGb807134 for ; Wed, 9 Apr 2003 08:16:37 -0400 Received: from ns.unisa.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25068 for ; Wed, 9 Apr 2003 08:10:55 -0400 (EDT) Received: from fw-1 (dmz1.unisa.it [193.205.160.60]) by ns.unisa.it (8.12.8/8.12.0) with SMTP id h39CDL4R023303 for ; Wed, 9 Apr 2003 14:13:21 +0200 (MET DST) Received: from ([193.205.164.89]) by fw-1; Wed, 09 Apr 2003 13:07:12 +0200 (CEST) Subject: [Fwd: Re: [Tsvwg] again load sharing] From: giuseppe To: TSWG Content-Type: multipart/mixed; boundary="=-eEnvVU1F68mBkLbKvWPB" Message-Id: <1049890136.1696.14.camel@cori17> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 09 Apr 2003 14:08:57 +0200 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , --=-eEnvVU1F68mBkLbKvWPB Content-Type: text/plain Content-Transfer-Encoding: 7bit --=-eEnvVU1F68mBkLbKvWPB Content-Disposition: inline Content-Description: Messaggio inoltrato - Re: [Tsvwg] again load sharing Content-Type: message/rfc822 Subject: Re: [Tsvwg] again load sharing From: giuseppe To: bidulock@openss7.org In-Reply-To: <20030409050714.D12896@openss7.org> References: <1049879292.5278.11.camel@cori17> <20030409034918.B12896@openss7.org> <1049884828.14720.3.camel@cori17> <20030409050714.D12896@openss7.org> Content-Type: text/plain Organization: Message-Id: <1049890074.1697.12.camel@cori17> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 09 Apr 2003 14:07:54 +0200 Content-Transfer-Encoding: 7bit I do not agree totally. Maybe I do not understood the matter.But... Il mer, 2003-04-09 alle 13:07, Brian F. G. Bidulock ha scritto: > giuseppe, > > That does not make SCTP "unfair" to TCP. Each destination will still > back off exponentially and grow linearly. TCP connections can only > be to one destination. SCTP multihomed associations in competition with > TCP connections to the one of its destination will behave the same as > a TCP connection to that destination. As long as SCTP acts as a single > TCP connection to each destination, it will behave no differently than > a TCP connection made to each destination. Sure. But let suppose that in the point (router) R1 arrive one TCP connection and one SCTP connection (with load sharing turn on). In steady state SCTP single connection (we mean for connection the couple (source address, destination address) behaves fairly with TCP connection. And they equally share the capacity. Same for the other connection (i.e. the other possible couples). But if we suppose that all the couples, i.e. all the connections of the SCTP, traverse the same POC (in this case R1), SCTP grabs more capacity than TCP, and more, the dropping probability augments . If the common point traversed were a POC, this "probabily" would not happen and the load sharing would be "effective". In my discussion I suppose we are able to fairly select the real path (i.e. the couples...), maybe by using the source addressing mechanism. > In face SCTP is disadvantaged > by source address/destination address path mappings. That is, when > SCTP has two sources (A and B) and two destinations (C and D) it behaves > as thought it were two TCP connections, one to each destination. But > 4 TCP connections can be formed: A-C, B-C, A-D, B-D. This means that > TCP can compete unfairly with SCTP in unbalanced networks or in networks > where source address based routing is performed (e.g. disjoint networks). > Where source address based routing is not performed (normal case, common > points of congestion), the situation is quite fair. > > --brian We detected that there is an other problem in load sharing with SCTP: the problem of unique CTSN variable. In fact, the SACK could increment also the congestion windows associated with paths where there has been a dropping event... So, I am waiting your helpufl comment. > On Wed, 09 Apr 2003, giuseppe wrote: > > > Il mer, 2003-04-09 alle 11:49, Brian F. G. Bidulock ha scritto: > > > giuseppe, > > > > > > On Wed, 09 Apr 2003, giuseppe wrote: > > > > > > > HI. I am investigating the opportunity of load sharing in SCTP. One of > > > > the thing I not undertand is when the load sharing is effective. There > > > > are situations in which load sharing is effective? > > > > > > Load sharing is effective in any situation where both the available > > > bandwidth of the network and the offered load exceeds the available > > > bandwidth of any one interface. (Or a similar situation with regard > > > to latency if latency is of concern.) > > > > > > OTOH the algorithm for load sharing can have interactions with SCTP > > > protocol mechanisms (retransmission, gaps, SACKs, bundling) and could > > > reduce efficiency in some circumstances depdending on network > > > conditions. > > > > > > IMO algorithms that more closely correspond to SCTP's "primary" > > > destination approach will have more success than those that deviate > > > widely from it. All other factors equal, a sender should not load-share > > > to a secondary destination until the primary destiation's congestion > > > window has been sent. This or similar procedures should have the effect > > > of grouping as many sequential TSNs as possible to the same destination, > > > avoiding excess gap detection and reporting due to difference or > > > variance in OWT between destinations over which traffic is being > > > loadshared. > > > > > > > Second, is there anyone who is attempting to response to this question: > > > > when two links are un-shared? In my opinion two link are unshared when > > > > they do not cross same Point Of Congestion. So, detecting at run-time > > > > this event is a very hard challenge.... > > > > > > SCTP's congestion procedures do not make assuptions about the underlying > > > network and are resilient to network changes independent of network > > > topology. > > > > > > > Where is the challenge? > > > > > HI BRian, thanks for the quick response. > > I mean this. If one want sent data source over all the available paths > > (i.e. by using load sharing), it could happen that some paths (let > > suppose 2 for example) share a Point Of Congestion. Thus, sending at a > > send rate greater than of a single TCP connection sharing the same POC, > > could lead to an unfairness problem. In practice, we do not reach the > > well known sqrt(p) relation of the TCP throughput... > > > > > --brian --=-eEnvVU1F68mBkLbKvWPB-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 9 08:48:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26018 for ; Wed, 9 Apr 2003 08:48:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h39CrHq10126 for tsvwg-archive@odin.ietf.org; Wed, 9 Apr 2003 08:53:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39ChA809652; Wed, 9 Apr 2003 08:43:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39Cge809618 for ; Wed, 9 Apr 2003 08:42:40 -0400 Received: from gw.openss7.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25794 for ; Wed, 9 Apr 2003 08:36:57 -0400 (EDT) Received: from ns.pigworks.openss7.net (IDENT:NQVcQR7S58HhR/wDoWvJvqRR4FmR710h@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h39CdU923296; Wed, 9 Apr 2003 06:39:30 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h39CdU118158; Wed, 9 Apr 2003 06:39:30 -0600 Date: Wed, 9 Apr 2003 06:39:30 -0600 From: "Brian F. G. Bidulock" To: giuseppe Cc: TSWG Subject: Re: [Fwd: Re: [Tsvwg] again load sharing] Message-ID: <20030409063930.A17933@openss7.org> Reply-To: bidulock@openss7.org References: <1049890136.1696.14.camel@cori17> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <1049890136.1696.14.camel@cori17>; from gdemarco@unisa.it on Wed, Apr 09, 2003 at 02:08:57PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit giuseppe, On Wed, 09 Apr 2003, giuseppe wrote: > > I do not agree totally. Maybe I do not understood the matter.But... > Il mer, 2003-04-09 alle 13:07, Brian F. G. Bidulock ha scritto: > > giuseppe, > > > > That does not make SCTP "unfair" to TCP. Each destination will still > > back off exponentially and grow linearly. TCP connections can only > > be to one destination. SCTP multihomed associations in competition with > > TCP connections to the one of its destination will behave the same as > > a TCP connection to that destination. As long as SCTP acts as a single > > TCP connection to each destination, it will behave no differently than > > a TCP connection made to each destination. > > Sure. But let suppose that in the point (router) R1 arrive one TCP > connection and one SCTP connection (with load sharing turn on). In > steady state SCTP single connection (we mean for connection the couple > (source address, destination address) behaves fairly with TCP > connection. And they equally share the capacity. Same for the other > connection (i.e. the other possible couples). > But if we suppose that all the couples, i.e. all the connections of the > SCTP, traverse the same POC (in this case R1), SCTP grabs more capacity > than TCP, and more, the dropping probability augments . If the common > point traversed were a POC, this "probabily" would not happen and the > load sharing would be "effective". > In my discussion I suppose we are able to fairly select the real path > (i.e. the couples...), maybe by using the source addressing mechanism. Under congestion during load-sharing, the cwnd of each of N destinations will fall to 1/Nth of TCP's cwnd to the one destination and, everything is quite fair. The only place that SCTP might take advantage in load- sharing is during slow-start, however, an effective load-sharing algorithm could avoid loadsharing over multiple destinations in slow-start. > > > > In face SCTP is disadvantaged > > by source address/destination address path mappings. That is, when > > SCTP has two sources (A and B) and two destinations (C and D) it behaves > > as thought it were two TCP connections, one to each destination. But > > 4 TCP connections can be formed: A-C, B-C, A-D, B-D. This means that > > TCP can compete unfairly with SCTP in unbalanced networks or in networks > > where source address based routing is performed (e.g. disjoint networks). > > Where source address based routing is not performed (normal case, common > > points of congestion), the situation is quite fair. > > > > --brian > > We detected that there is an other problem in load sharing with SCTP: > the problem of unique CTSN variable. In fact, the SACK could increment > also the congestion windows associated with paths where there has been a > dropping event... I don't see the problem here: could you describe this further? --brian > So, I am waiting your helpufl comment. > > > > On Wed, 09 Apr 2003, giuseppe wrote: > > > > > Il mer, 2003-04-09 alle 11:49, Brian F. G. Bidulock ha scritto: > > > > giuseppe, > > > > > > > > On Wed, 09 Apr 2003, giuseppe wrote: > > > > > > > > > HI. I am investigating the opportunity of load sharing in SCTP. One of > > > > > the thing I not undertand is when the load sharing is effective. There > > > > > are situations in which load sharing is effective? > > > > > > > > Load sharing is effective in any situation where both the available > > > > bandwidth of the network and the offered load exceeds the available > > > > bandwidth of any one interface. (Or a similar situation with regard > > > > to latency if latency is of concern.) > > > > > > > > OTOH the algorithm for load sharing can have interactions with SCTP > > > > protocol mechanisms (retransmission, gaps, SACKs, bundling) and could > > > > reduce efficiency in some circumstances depdending on network > > > > conditions. > > > > > > > > IMO algorithms that more closely correspond to SCTP's "primary" > > > > destination approach will have more success than those that deviate > > > > widely from it. All other factors equal, a sender should not load-share > > > > to a secondary destination until the primary destiation's congestion > > > > window has been sent. This or similar procedures should have the effect > > > > of grouping as many sequential TSNs as possible to the same destination, > > > > avoiding excess gap detection and reporting due to difference or > > > > variance in OWT between destinations over which traffic is being > > > > loadshared. > > > > > > > > > Second, is there anyone who is attempting to response to this question: > > > > > when two links are un-shared? In my opinion two link are unshared when > > > > > they do not cross same Point Of Congestion. So, detecting at run-time > > > > > this event is a very hard challenge.... > > > > > > > > SCTP's congestion procedures do not make assuptions about the underlying > > > > network and are resilient to network changes independent of network > > > > topology. > > > > > > > > > > Where is the challenge? > > > > > > > HI BRian, thanks for the quick response. > > > I mean this. If one want sent data source over all the available paths > > > (i.e. by using load sharing), it could happen that some paths (let > > > suppose 2 for example) share a Point Of Congestion. Thus, sending at a > > > send rate greater than of a single TCP connection sharing the same POC, > > > could lead to an unfairness problem. In practice, we do not reach the > > > well known sqrt(p) relation of the TCP throughput... > > > > > > > --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 9 09:40:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27514 for ; Wed, 9 Apr 2003 09:40:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h39Dk3M14223 for tsvwg-archive@odin.ietf.org; Wed, 9 Apr 2003 09:46:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39DYi812908; Wed, 9 Apr 2003 09:34:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39DWe812842 for ; Wed, 9 Apr 2003 09:32:40 -0400 Received: from ns.unisa.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27084 for ; Wed, 9 Apr 2003 09:26:56 -0400 (EDT) Received: from fw-1 (dmz1.unisa.it [193.205.160.60]) by ns.unisa.it (8.12.8/8.12.0) with SMTP id h39DTJ4R025629; Wed, 9 Apr 2003 15:29:19 +0200 (MET DST) Received: from ([193.205.164.89]) by fw-1; Wed, 09 Apr 2003 14:23:11 +0200 (CEST) Subject: Re: [Fwd: Re: [Tsvwg] again load sharing] From: giuseppe To: "Brian F. G. Bidulock" Cc: TSWG In-Reply-To: <20030409063930.A17933@openss7.org> References: <1049890136.1696.14.camel@cori17> <20030409063930.A17933@openss7.org> Content-Type: text/plain Message-Id: <1049894695.1697.123.camel@cori17> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 09 Apr 2003 15:24:56 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Brian, let consider this raw figure: ----- ------ |TCP| |TCP| ----- ------ | | -------- O------------------------O ------- |SCTP A|__________| |____________|SCTP 1| | | | | |SCTP B|----------O------------------------O------------|SCTP 2| -------- -------- Suppose we are in load sharing, i.e. we send out data over A-1 and B-2 jointly. The RFC say that the congestion window must be incremented when : 1) the variable CSTN at sender is lower than the CTSN-AP 2) new data are acknowledged on the associated path Let suppose u send 1-2-3-4 on the path A-1 and 5-6-7-8 on the path B-2. A loss of the packet 5 occurs. A SACK on 1-A, with CSTN-AP=4 and a GAPstart=6 and a GAPstop=8, will increment the CWND both on the A-1 and B-2 path. This is the problem to have a unique CSTN. More, in the figure load sharing is fair. TCP compete fairly with A-1 SCTP. But what happen if also B-2 traverse R1-R2 path? SCTP grabs more bandwidth with respect to TCP? To me, yes. Moreover, if R1-R2 is congested (high p), adding an other connection will further increase p. giuseppe Il mer, 2003-04-09 alle 14:39, Brian F. G. Bidulock ha scritto: > giuseppe, > > On Wed, 09 Apr 2003, giuseppe wrote: > > > > I do not agree totally. Maybe I do not understood the matter.But... > > Il mer, 2003-04-09 alle 13:07, Brian F. G. Bidulock ha scritto: > > > giuseppe, > > > > > > That does not make SCTP "unfair" to TCP. Each destination will still > > > back off exponentially and grow linearly. TCP connections can only > > > be to one destination. SCTP multihomed associations in competition with > > > TCP connections to the one of its destination will behave the same as > > > a TCP connection to that destination. As long as SCTP acts as a single > > > TCP connection to each destination, it will behave no differently than > > > a TCP connection made to each destination. > > > > Sure. But let suppose that in the point (router) R1 arrive one TCP > > connection and one SCTP connection (with load sharing turn on). In > > steady state SCTP single connection (we mean for connection the couple > > (source address, destination address) behaves fairly with TCP > > connection. And they equally share the capacity. Same for the other > > connection (i.e. the other possible couples). > > But if we suppose that all the couples, i.e. all the connections of the > > SCTP, traverse the same POC (in this case R1), SCTP grabs more capacity > > than TCP, and more, the dropping probability augments . If the common > > point traversed were a POC, this "probabily" would not happen and the > > load sharing would be "effective". > > In my discussion I suppose we are able to fairly select the real path > > (i.e. the couples...), maybe by using the source addressing mechanism. > > Under congestion during load-sharing, the cwnd of each of N destinations > will fall to 1/Nth of TCP's cwnd to the one destination and, everything > is quite fair. The only place that SCTP might take advantage in load- > sharing is during slow-start, however, an effective load-sharing algorithm > could avoid loadsharing over multiple destinations in slow-start. > > > > > > > > In face SCTP is disadvantaged > > > by source address/destination address path mappings. That is, when > > > SCTP has two sources (A and B) and two destinations (C and D) it behaves > > > as thought it were two TCP connections, one to each destination. But > > > 4 TCP connections can be formed: A-C, B-C, A-D, B-D. This means that > > > TCP can compete unfairly with SCTP in unbalanced networks or in networks > > > where source address based routing is performed (e.g. disjoint networks). > > > Where source address based routing is not performed (normal case, common > > > points of congestion), the situation is quite fair. > > > > > > --brian > > > > We detected that there is an other problem in load sharing with SCTP: > > the problem of unique CTSN variable. In fact, the SACK could increment > > also the congestion windows associated with paths where there has been a > > dropping event... > > I don't see the problem here: could you describe this further? > > --brian > > > So, I am waiting your helpufl comment. > > > > > > > On Wed, 09 Apr 2003, giuseppe wrote: > > > > > > > Il mer, 2003-04-09 alle 11:49, Brian F. G. Bidulock ha scritto: > > > > > giuseppe, > > > > > > > > > > On Wed, 09 Apr 2003, giuseppe wrote: > > > > > > > > > > > HI. I am investigating the opportunity of load sharing in SCTP. One of > > > > > > the thing I not undertand is when the load sharing is effective. There > > > > > > are situations in which load sharing is effective? > > > > > > > > > > Load sharing is effective in any situation where both the available > > > > > bandwidth of the network and the offered load exceeds the available > > > > > bandwidth of any one interface. (Or a similar situation with regard > > > > > to latency if latency is of concern.) > > > > > > > > > > OTOH the algorithm for load sharing can have interactions with SCTP > > > > > protocol mechanisms (retransmission, gaps, SACKs, bundling) and could > > > > > reduce efficiency in some circumstances depdending on network > > > > > conditions. > > > > > > > > > > IMO algorithms that more closely correspond to SCTP's "primary" > > > > > destination approach will have more success than those that deviate > > > > > widely from it. All other factors equal, a sender should not load-share > > > > > to a secondary destination until the primary destiation's congestion > > > > > window has been sent. This or similar procedures should have the effect > > > > > of grouping as many sequential TSNs as possible to the same destination, > > > > > avoiding excess gap detection and reporting due to difference or > > > > > variance in OWT between destinations over which traffic is being > > > > > loadshared. > > > > > > > > > > > Second, is there anyone who is attempting to response to this question: > > > > > > when two links are un-shared? In my opinion two link are unshared when > > > > > > they do not cross same Point Of Congestion. So, detecting at run-time > > > > > > this event is a very hard challenge.... > > > > > > > > > > SCTP's congestion procedures do not make assuptions about the underlying > > > > > network and are resilient to network changes independent of network > > > > > topology. > > > > > > > > > > > > > Where is the challenge? > > > > > > > > > HI BRian, thanks for the quick response. > > > > I mean this. If one want sent data source over all the available paths > > > > (i.e. by using load sharing), it could happen that some paths (let > > > > suppose 2 for example) share a Point Of Congestion. Thus, sending at a > > > > send rate greater than of a single TCP connection sharing the same POC, > > > > could lead to an unfairness problem. In practice, we do not reach the > > > > well known sqrt(p) relation of the TCP throughput... > > > > > > > > > --brian > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 9 10:06:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28748 for ; Wed, 9 Apr 2003 10:06:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h39EBi916414 for tsvwg-archive@odin.ietf.org; Wed, 9 Apr 2003 10:11:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39E3Q815192; Wed, 9 Apr 2003 10:03:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39E2k815138 for ; Wed, 9 Apr 2003 10:02:46 -0400 Received: from gw.openss7.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28043 for ; Wed, 9 Apr 2003 09:57:02 -0400 (EDT) Received: from ns.pigworks.openss7.net (IDENT:mMnqIskKsQhVwAGj7GskbM+zo4UGpV/n@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h39DxZ924552; Wed, 9 Apr 2003 07:59:35 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h39DxZe19584; Wed, 9 Apr 2003 07:59:35 -0600 Date: Wed, 9 Apr 2003 07:59:34 -0600 From: "Brian F. G. Bidulock" To: giuseppe Cc: TSWG Subject: Re: [Fwd: Re: [Tsvwg] again load sharing] Message-ID: <20030409075934.F19174@openss7.org> Reply-To: bidulock@openss7.org References: <1049890136.1696.14.camel@cori17> <20030409063930.A17933@openss7.org> <1049894695.1697.123.camel@cori17> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <1049894695.1697.123.camel@cori17>; from gdemarco@unisa.it on Wed, Apr 09, 2003 at 03:24:56PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit giuseppe, On Wed, 09 Apr 2003, giuseppe wrote: > Brian, let consider this raw figure: > > > > ----- ------ > |TCP| |TCP| > ----- ------ > | | > -------- O------------------------O ------- > |SCTP A|__________| |____________|SCTP 1| > | | | | > |SCTP B|----------O------------------------O------------|SCTP 2| > -------- -------- > > Suppose we are in load sharing, i.e. we send out data over A-1 and B-2 > jointly. > The RFC say that the congestion window must be incremented when : > 1) the variable CSTN at sender is lower than the CTSN-AP > 2) new data are acknowledged on the associated path > Let suppose u send 1-2-3-4 on the path A-1 and 5-6-7-8 on the path B-2. > A loss of the packet 5 occurs. A SACK on 1-A, with CSTN-AP=4 and a > GAPstart=6 and a GAPstop=8, will increment the CWND both on the A-1 and > B-2 path. This is the problem to have a unique CSTN. Only the congestion window for the destination to which data was sent is incremented and then only if the data is cumulatively acked and the data was not retransmitted. I still don't see a problem. > More, in the figure load sharing is fair. TCP compete fairly with A-1 > SCTP. > But what happen if also B-2 traverse R1-R2 path? SCTP grabs more > bandwidth with respect to TCP? To me, yes. No. SCTP's cwnd for each desitination would fall to 1/2 of TCP's cwnd. > Moreover, if R1-R2 is > congested (high p), adding an other connection will further increase p. -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 9 21:54:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23066 for ; Wed, 9 Apr 2003 21:54:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3A1xhe16117 for tsvwg-archive@odin.ietf.org; Wed, 9 Apr 2003 21:59:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A1qm815758; Wed, 9 Apr 2003 21:52:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A1HR813178 for ; Wed, 9 Apr 2003 21:17:27 -0400 Received: from maude.qualcomm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22184 for ; Wed, 9 Apr 2003 21:11:30 -0400 (EDT) Received: from [127.0.0.1] (helo=qualcomm.com) by maude.qualcomm.com with esmtp (Exim 3.35 #1 (Debian)) id 193Qdc-0002h6-00; Wed, 09 Apr 2003 18:14:00 -0700 Message-ID: <3E94C558.8040802@qualcomm.com> Date: Wed, 09 Apr 2003 18:14:00 -0700 From: Phil Karn User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Reiner Ludwig CC: "Armando L. Caro Jr." , tsvwg@ietf.org Subject: Re: [Tsvwg] Rethinking Karn's algorithm References: <5.1.0.14.0.20030325221003.00aa6300@mailhost.eed.ericsson.se> <5.1.0.14.0.20030327124629.00aada08@mailhost.eed.ericsson.se> In-Reply-To: <5.1.0.14.0.20030327124629.00aada08@mailhost.eed.ericsson.se> X-Enigmail-Version: 0.73.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Reiner Ludwig wrote: > I guess the times when LANs where interconnected by slow dial-up > connections are long gone ... and if they still exist then they > certainly don't pose a threat to the stability of the (public) Internet. I disagree. While many fixed networks are indeed now connected over links much faster than slow dialups, there are some important wireless situations where conditions are very much like those of the Internet 15 years ago. Imagine a self-contained gateway router with 802.11 on one side and a 3G (or CDMA, or whatever) cell phone on the other. I envision these things being used to provide temporary Internet access to a group in a hotel conference room where the hotel doesn't already provide Internet access. Here you have a LAN that can potentially generate a lot of traffic being linked to the public Internet over a relatively slow (by LAN standards) link. It is still important for TCP to be conservative in such situations, don't you think? Phil _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 9 21:57:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23113 for ; Wed, 9 Apr 2003 21:57:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3A22qL16247 for tsvwg-archive@odin.ietf.org; Wed, 9 Apr 2003 22:02:52 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A1r7815798; Wed, 9 Apr 2003 21:53:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A1aw814077 for ; Wed, 9 Apr 2003 21:36:58 -0400 Received: from maude.qualcomm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22530 for ; Wed, 9 Apr 2003 21:31:01 -0400 (EDT) Received: from [127.0.0.1] (helo=qualcomm.com) by maude.qualcomm.com with esmtp (Exim 3.35 #1 (Debian)) id 193QwW-0002hY-00; Wed, 09 Apr 2003 18:33:32 -0700 Message-ID: <3E94C9EC.2060605@qualcomm.com> Date: Wed, 09 Apr 2003 18:33:32 -0700 From: Phil Karn User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Reiner Ludwig CC: tsvwg@ietf.org References: <5.1.0.14.0.20030325221003.00aa6300@mailhost.eed.ericsson.se> In-Reply-To: <5.1.0.14.0.20030325221003.00aa6300@mailhost.eed.ericsson.se> X-Enigmail-Version: 0.73.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Re: Rethinking Karn's algorithm Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Reiner Ludwig wrote: > 1. With timestamps, we can also take valid RTTs from retransmitted > segments. One major difference that *does* exist between the Internet of 15 years ago and the Internet of today is that TCP header timestamps are now very widespread. Nearly all TCPs support them: Linux enables them by default, while W2K (and 98, I think) implement them but you have to turn them on. TCP header timestamps have made my algorithm essentially obsolete, as they eliminates the "retransmission ambiguity" problem I was trying to solve. You just echo back each timestamp as you get it, and you don't care whether the timestamp is on the first transmission of a particular segment or its retransmission. I knew at the time I wrote my paper with Craig that this was possible, but I was interested in algorithms that could work with the existing TCP header. Header overhead is a non-issue here, IHMO. The savings in unnecessary retransmits more than pays back the investment in a larger TCP header. Phil _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 9 22:30:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23773 for ; Wed, 9 Apr 2003 22:30:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3A2ZYY18439 for tsvwg-archive@odin.ietf.org; Wed, 9 Apr 2003 22:35:34 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A2PC818027; Wed, 9 Apr 2003 22:25:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SDvbO04702 for ; Fri, 28 Mar 2003 08:57:37 -0500 Received: from beamer.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28242; Fri, 28 Mar 2003 08:35:18 -0500 (EST) Received: from moody.mchh.siemens.de ([139.21.205.85]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA09332; Fri, 28 Mar 2003 14:37:40 +0100 (MET) Received: from mchh273e.demchh201e.icn.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id OAA25795; Fri, 28 Mar 2003 14:37:40 +0100 (MET) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Fri, 28 Mar 2003 14:37:22 +0100 Message-ID: From: Tuexen Michael To: "'sigtran@ietf.org'" , "'tsvwg@ietf.org'" , "'rserpool@ietf.org'" Date: Fri, 28 Mar 2003 14:37:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Tsvwg] New e-mail address Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Dear all, my Siemens e-mail address will no longer work. Please use tuexen@fh-muenster.de in case you want to contact me. Best regards Michael Michael Tuexen Tel.: +49 89 722 47210 Siemens AG Fax: +49 89 722 48212 ICN CP SE C 7 e-mail: Michael.Tuexen@siemens.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Apr 10 20:30:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13319 for ; Thu, 10 Apr 2003 20:30:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3B0arF28811 for tsvwg-archive@odin.ietf.org; Thu, 10 Apr 2003 20:36:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3B0Sa828293; Thu, 10 Apr 2003 20:28:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3B0Ij827867 for ; Thu, 10 Apr 2003 20:18:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12739; Thu, 10 Apr 2003 20:12:19 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193ltN-0005Tn-00; Thu, 10 Apr 2003 19:55:41 -0400 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 193ltN-0005Tk-00; Thu, 10 Apr 2003 19:55:41 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h3B0Esk21203; Thu, 10 Apr 2003 17:14:54 -0700 (PDT) Message-Id: <200304110014.h3B0Esk21203@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, tsvwg@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 10 Apr 2003 17:14:53 -0700 Subject: [Tsvwg] RFC 3517 on A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3517 Title: A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP Author(s): E. Blanton, M. Allman, K. Fall, L. Wang Status: Standards Track Date: April 2003 Mailbox: eblanton@cs.purdue.edu, mallman@bbn.com, kfall@intel-research.net, lwang0@uky.edu Pages: 13 Characters: 27855 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-allman-tcp-sack-13.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3517.txt This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 2581), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. This document is a product of the Transport Area Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030410171251.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3517 --OtherAccess Content-Type: Message/External-body; name="rfc3517.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030410171251.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 11 04:26:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03610 for ; Fri, 11 Apr 2003 04:26:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3B8Wer05846 for tsvwg-archive@odin.ietf.org; Fri, 11 Apr 2003 04:32:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3B8PW805605; Fri, 11 Apr 2003 04:25:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3B8Ou805545 for ; Fri, 11 Apr 2003 04:24:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03474 for ; Fri, 11 Apr 2003 04:18:22 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193tTi-00005n-00 for tsvwg@ietf.org; Fri, 11 Apr 2003 04:01:42 -0400 Received: from ms.exp-math.uni-essen.de ([132.252.150.18] helo=irmgard.exp-math.uni-essen.de) by ietf-mx with esmtp (Exim 4.12) id 193tTh-00005k-00 for tsvwg@ietf.org; Fri, 11 Apr 2003 04:01:42 -0400 Received: from gina.exp-math.uni-essen.de (gina.exp-math.uni-essen.de [132.252.150.131]) by irmgard.exp-math.uni-essen.de (8.12.8/8.12.2) with ESMTP id h3B8KrJF056536; Fri, 11 Apr 2003 10:20:54 +0200 From: Andreas Jungmaier Organization: University Duisburg-Essen To: giuseppe , "Brian F. G. Bidulock" Subject: Re: [Fwd: Re: [Tsvwg] again load sharing] Date: Fri, 11 Apr 2003 10:19:46 +0200 User-Agent: KMail/1.5 Cc: TSWG References: <1049890136.1696.14.camel@cori17> <20030409063930.A17933@openss7.org> <1049894695.1697.123.camel@cori17> In-Reply-To: <1049894695.1697.123.camel@cori17> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200304111019.48209.ajung@exp-math.uni-essen.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3B8Ou805546 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, please see my comments inline: On Wednesday 09 April 2003 15:24, giuseppe wrote: > > ----- ------ > |TCP| |TCP| > ----- ------ >-------- O------------------------O -------- >|SCTP A|________| |____________|SCTP 1| >| >|SCTP B|----------O----------------------O------------|SCTP 2| >-------- -------- > But what happen if also B-2 traverse R1-R2 path? SCTP grabs more > bandwidth with respect to TCP? To me, yes. Moreover, if R1-R2 is > congested (high p), adding an other connection will further increase p. In that configuration, SCTP behaves essentially similar to two TCP connections. So, one SCTP association probably grabs more bandwidth than one TCP connection. However, it still behaves in a fair manner toward the TCP connection. Also, the SCTP association is bound by the receiver window (RWND), meaning that there is a limit that is enforced on the SCTP association as a whole. Now, if you have 2 TCP connections, these are both limited by their respective receiver windows. So these 2 may, *depending on the parameters of the network setup*, take more bandwidth than one SCTP association with dual-homing and load-sharing. My 2 cents, Andreas - -- Dipl.-Ing. Andreas Jungmaier Computer Networking Technology Group University of Duisburg-Essen http://www.exp-math.uni-essen.de/~ajung My PGP Key-ID: D3824AC0 My PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+lnqiXAsLBNOCSsARAkHvAKCX1+jVWVTrIqvhGjMkFo9vEMXtfQCcCuP7 lJxY8CujFU6B2LJbNDiY3T8= =m+Tj -----END PGP SIGNATURE----- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 11 13:15:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21870 for ; Fri, 11 Apr 2003 13:15:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3BHLQu11920 for tsvwg-archive@odin.ietf.org; Fri, 11 Apr 2003 13:21:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BHL4811903; Fri, 11 Apr 2003 13:21:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BHJq811830 for ; Fri, 11 Apr 2003 13:19:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21832 for ; Fri, 11 Apr 2003 13:13:06 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 19427q-0004NM-00 for tsvwg@ietf.org; Fri, 11 Apr 2003 13:15:42 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19427q-0004NJ-00 for tsvwg@ietf.org; Fri, 11 Apr 2003 13:15:42 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id E7C07328E5; Fri, 11 Apr 2003 13:15:41 -0400 (EDT) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 238C83289E; Fri, 11 Apr 2003 13:15:41 -0400 (EDT) Date: Fri, 11 Apr 2003 13:15:41 -0400 (EDT) From: Janardhan Iyengar X-X-Sender: To: Andreas Jungmaier Cc: giuseppe , "Brian F. G. Bidulock" , TSWG Subject: Re: [Fwd: Re: [Tsvwg] again load sharing] In-Reply-To: <200304111019.48209.ajung@exp-math.uni-essen.de> Message-ID: X-Spam-Status: No, hits=-4.8 required=6.0 tests=DEPT_RCVD,FWD_MSG,IN_REP_TO,PGP_SIGNATURE, QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Hi Andreas/all, > In that configuration, SCTP behaves essentially similar to two > TCP connections. So, one SCTP association probably grabs more > bandwidth than one TCP connection. > > However, it still behaves in a fair manner toward the TCP connection. I don't think I agree. If a single SCTP association behaves as aggressively as two concurrent TCP connections, I do not think it is being fair to TCP. For one, when comparing a single TCP connection with an SCTP association performing what we call "Concurrent Multipath Transfer (CMT)" (or load sharing) with a shared bottleneck, a single loss event at the bottleneck does not result in the same reduced cwnd for the TCP connection and the SCTP-CMT association. > Also, the SCTP association is bound by the receiver window (RWND), meaning > that there is a limit that is enforced on the SCTP association as a > whole. > > Now, if you have 2 TCP connections, these are both limited by > their respective receiver windows. So these 2 may, *depending on the > parameters of the network setup*, take more bandwidth than one SCTP > association with dual-homing and load-sharing. Agreed. But I think we should be comparing 1 TCP connection with 1 SCTP association. Or am I missing something here? Guiseppe: I am currently involved in End-to-End Concurrent Multipath Transfer at the Transport Layer. With regard to your comment about "unique CTSN variable", there are a few things that come to mind. But I'm not sure what you are referring to. If you do have some specific questions with regard to what you are observing, maybe you could get back to me offline? regards, jana > My 2 cents, > > Andreas > > - -- > Dipl.-Ing. Andreas Jungmaier > Computer Networking Technology Group > University of Duisburg-Essen > http://www.exp-math.uni-essen.de/~ajung > My PGP Key-ID: D3824AC0 > > My PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.1 (GNU/Linux) > > iD8DBQE+lnqiXAsLBNOCSsARAkHvAKCX1+jVWVTrIqvhGjMkFo9vEMXtfQCcCuP7 > lJxY8CujFU6B2LJbNDiY3T8= > =m+Tj > -----END PGP SIGNATURE----- > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > ----------------------------------------------------------------------- Janardhan R. Iyengar http://www.cis.udel.edu/~iyengar Protocol Engineering Lab University of Delaware ----------------------------------------------------------------------- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 11 13:51:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22816 for ; Fri, 11 Apr 2003 13:51:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3BHwE814424 for tsvwg-archive@odin.ietf.org; Fri, 11 Apr 2003 13:58:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BHvK814390; Fri, 11 Apr 2003 13:57:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BHuL814329 for ; Fri, 11 Apr 2003 13:56:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22767; Fri, 11 Apr 2003 13:49:34 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1942h7-0004bG-00; Fri, 11 Apr 2003 13:52:09 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1942h7-0004bD-00; Fri, 11 Apr 2003 13:52:09 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 3.36 #1) id 1942h6-0006yj-00; Fri, 11 Apr 2003 10:52:08 -0700 To: tsvwg@ietf.org, minutes@ietf.org Cc: jon.peterson@neustar.biz Reply-To: mankin@psg.com Date: Fri, 11 Apr 2003 17:52:07 +0000 From: Allison Mankin Message-Id: Subject: [Tsvwg] Minutes of TSVWG at IETF 56 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , These are due today it seems, so send corrections to the list, where our archives can serve as the record. Thanks to Spencer for the note-taking. Minutes taken by Spencer Dawkins ================================== Transport Area Working Group TSVWG ================================== Allison Mankin and Jon Peterson Scott has been replaced by Jon as AD but will still be active Kireeti - Status of RSVP change document RSVP has become very popular, people outside IETF want to change it this causes difficulties for interoperation - how do we prevent breaking RSVP? recent code points RFC from completely outside IETF with a lot of pushback give RSVP IANA considerations that it's never had before previous considerations draft had expired give three code points (normal use, experimental use, first-come-first-served) really need a "standards action" code point, too also need PS RFC to initiate behavior changes is this important? Andy Malis: this is absolutely needed - IANA is working with no guidelines whatesoever even first-come-first-served space is broken Bob Braden is now the gatekeeper and things are confusing Bob Braden has suggested name-based sand boxes - not much reaction - do people care? Allison: IESG suggested names not reflect owners for maintainability Philip Matthews: IS-IS has the same issues and is dealing with them in the same way Split between class numbers and C-types? will be discussed on TSVWG mailing list Jukka Manner - Localized RSVP (LRSVP) end-to-end QoS is rarely available backbones fast and reliable access networks are bottleneck congestion points using a small enhancement to RSVP that can coexist with RSVP Local Indication and Expedited Refresh bits allow coexistence Open issues - addressing, asymmetric routing, interworking with end-to-end RSVP, security Steve Casner: each end signals its own access network? A: end-to-end is preferable, this is fall-back Steve Silverman: is "local" on a LAN? A: "local" access network Tom Hiller: 3GPP does things almost identical to this not documented in RFCs because never leaves walled garden John Bennett - IP measurement OAM problem problem statement measure ping, traceroute, etc. can't do this because ot ICMP blocking, flow-specific routes, hop-by-hop vs. end-to-end want to measure increasingly specific things (take HTTP redirect into account, etc) can't figure out which hop is the problem need a new protocol that can be processed in fast path - no control "polite" protocol passes through firewalls, NATs, etc. "IP Measurement Protocol" - IPMP Echo, IPMP Information Request proposed by Andrew McGregor a couple of years ago bennett-00 changes adds redirection, port numbers, TLVs mcgregor-00 and bennet-01 also make changes to previous proposal Peter Neuman - would like to measure downstream with standardized protocol Q: also have a draft we'd like to be considered A: looking at general level of interest first Sally Floyd - draft-floyd-tcp-highspeed-02.txt Quickstart revision is also out for comments adding a new response function for TCPs on links with very low error rates revision adds discussion of TCP with multiple connections Scalable TCP from Tom Kelly Adds a section on choosing parameters Adds discussion on P-MTU, window scaling, etc. Shows simulation results from Evandro de Souza in a drop-tail queue? would work better with small P Need feedback from community before Experimental RFC Limited Slowstart proposal is also related Other changes? Higher dupack threshold, etc. TCP Quickstart isn't ready to be Experimental RFC - needs more research Allison: what is the complexity? A: maintain a table instead of always cutting in half Eric Nordmark: current reference implementation uses scaled math cutting in half is easy, cutting by 22.9 percent is harder A: could approximate by shifting Matt Mathis: uses integer arithmetic Reiner: why don't smaller congestion windows get to use this? A: need to pick targets for response functions for divergence from standard TCP motivation for picking is that TCP is successful now, so small changes Matt Mathis: Fairness on the Internet is because of standard response function can't let everybody dork with their response function - no fairness Q: Not good at translating from drop rates to technologies A: starting at 10**-6 packet loss rates, High Speed TCP seems to make a big difference Mike from Digital Fountain: have you tried parallel sessions of HSTCP? A: yes, pointed to from web page, so far it looks fine congestion network would be better off if you're using HSTCP Joe Touch: use RSVP for SYN, because we're in slow path anyway A: maybe, but not yet Joe Touch: point solution for 10-gig Ethernet? more dynamic than you're thinking about A: can you talk about this on the list? hum to adopt as WG item Ethan Blanton - draft-blanton-dsack-use-02.txt building from Atlanta discussion solved real loss during recovery what do we do now? Randall Stewart: perfectly safe, move it forward hum to adopt as WG item Ethan Blanton draft-blanton-tcp-reordering-00.txt can we recover our congestion window? need to prevent massive burst at window reversion time need to prevent spurious fast retransmits presenting four schemes of increasing complexity most conservative scheme is most complexity need more data, would like to hear alternative schemes spurious RTOs is explicitly out of scope Matt Mathis: there are lots of heuristics hidden in real TCPs that will cloud your results Mark Allman: should this sort of algorithm be Experimental? They're conservative Allison: some RFCs are really experiments, some are really for immediate use Sally: Experimental after one real implementation? Allison: We use "experimental" to mean several different things Sally: Texas A&M proposal could be added to this work Mark Allman - draft-allman-tcp-early-rexmt-00.txt No oppositions based on the list traffic, right? splitting this work out from Limited Transmit less resistent to reordering, but ... Spencer: worse cases are bad in macro sense but effect on user may justify this Sally Floyd - Proposal for newreno standardization Newreno is widely deployed and is still experimental - move it forward? please identify any major fixes this would require (but not other ideas/changes) Reiner Ludwig - Redundant data in TCP? TCP-friendly with quotas on good and bad bytes? please feed back to the mailing list Randall Stewart - draft-stewart-tsvwg-prsctp-03.txt Phil Cochran - SCTP bakeoff at UDelaware June 1-8 (unofficial) PR-SCTP has been around for a while - the first service designed by the spec provides "timed reliability" "abandon" stale chunks of data still make congestion window (downward) adjustments only enabled if both sides understand it! three independent implementations, all interop tested seven additional implementations coming Mark Allman: making it easier to throw useless data into the network? should be considered the way we're considering Reiner's proposal Randall: will construct a scenario on the list David Black: this is the opposite of Reiner's proposal Randall: better than I could have said it Allison: noticed spec made possible to change the lifetime after it was set, suggests interesting race conditions, API complexity in name of flexibility/power... Phil: lots of good issues... agree that if you can change lifetime values, this creates race conditions larger question is about creating lots of new services two parts of proposals - on the wire part is what we need to standardize policy is internal to a node Randall: realistic, can't change this in internal implementations today Mark: more motivation on the list? Randall: unreliable stream didn't simplify anything (per previous connectathon) Mark: couldn't you simplify per-stream, not just per-packet? Phil: good points for application writers, but these are service definition API issues Randall - I could do what you're saying in the current implementation David Black: setting timeouts is valuable in some scenario Chairs: review to be continued on list. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 11 16:24:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28544 for ; Fri, 11 Apr 2003 16:24:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3BKUkb26694 for tsvwg-archive@odin.ietf.org; Fri, 11 Apr 2003 16:30:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BKUR826672; Fri, 11 Apr 2003 16:30:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BKT8826622 for ; Fri, 11 Apr 2003 16:29:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28511 for ; Fri, 11 Apr 2003 16:22:17 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 19454w-0005Sp-00 for tsvwg@ietf.org; Fri, 11 Apr 2003 16:24:54 -0400 Received: from joda.cis.temple.edu ([155.247.71.60] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19454v-0005Sl-00 for tsvwg@ietf.org; Fri, 11 Apr 2003 16:24:53 -0400 Received: from BLUEHEN.acm.org (bluehen.cis.temple.edu [155.247.182.8]) by joda.cis.temple.edu (8.9.3/8.9.3) with ESMTP id QAA24743; Fri, 11 Apr 2003 16:24:48 -0400 (EDT) Message-Id: <5.1.0.14.2.20030411162123.04226208@joda.cis.temple.edu> X-Sender: conrad@joda.cis.temple.edu X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 11 Apr 2003 16:29:06 -0400 To: mankin@psg.com, tsvwg@ietf.org From: "Phillip T. Conrad" Subject: Re: [Tsvwg] Minutes of TSVWG at IETF 56 Cc: jon.peterson@neustar.biz In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , >At 05:52 PM 4/11/2003 +0000, Allison Mankin wrote: >These are due today it seems, so send corrections to the list, where >our archives can serve as the record. Thanks to Spencer for the >note-taking. >... One correction: ... >Randall Stewart - draft-stewart-tsvwg-prsctp-03.txt > > Phil Cochran - SCTP bakeoff at UDelaware June 1-8 (unofficial) ^^^^^^^^^^^^^ > PR-SCTP has been around for a while - the first service designed ... Phill Conrad made the SCTP bakeoff announcement, and participated in the PR-SCTP discussion (rather than Phil Cochran). (I have this on good authority.) The minutes are accurate that the bakeoff announcement was "unofficial" at the time it was made; however, if you like, we can add a note that the bakeoff is now officially "on" for that date, and details are at: http://pel.cis.udel.edu/interop Cheers, Phill Conrad _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Apr 14 06:03:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29565 for ; Mon, 14 Apr 2003 06:03:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3EAApB08281 for tsvwg-archive@odin.ietf.org; Mon, 14 Apr 2003 06:10:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EA8q808181; Mon, 14 Apr 2003 06:08:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EA7E807664 for ; Mon, 14 Apr 2003 06:07:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29484 for ; Mon, 14 Apr 2003 05:59:08 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1950mT-00014s-00 for tsvwg@ietf.org; Mon, 14 Apr 2003 06:01:41 -0400 Received: from ms.exp-math.uni-essen.de ([132.252.150.18] helo=irmgard.exp-math.uni-essen.de) by ietf-mx with esmtp (Exim 4.12) id 1950mS-00014p-00 for tsvwg@ietf.org; Mon, 14 Apr 2003 06:01:40 -0400 Received: from gina.exp-math.uni-essen.de (gina.exp-math.uni-essen.de [132.252.150.131]) by irmgard.exp-math.uni-essen.de (8.12.8/8.12.2) with ESMTP id h3EA1cJF070510; Mon, 14 Apr 2003 12:01:39 +0200 From: Andreas Jungmaier Organization: University Duisburg-Essen Subject: Fwd: Re: [Fwd: Re: [Tsvwg] again load sharing] Date: Mon, 14 Apr 2003 12:00:28 +0200 User-Agent: KMail/1.5 To: TSWG Cc: giuseppe , "Brian F. G. Bidulock" MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200304141200.29608.ajung@exp-math.uni-essen.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3EA7E807689 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Janar, all, please see my comments below - inline: > > In that configuration, SCTP behaves essentially similar to two > > TCP connections. So, one SCTP association probably grabs more > > bandwidth than one TCP connection. > > > > However, it still behaves in a fair manner toward the TCP connection. > > I don't think I agree. If a single SCTP association behaves as > aggressively as two concurrent TCP connections, I do not think it is being > fair to TCP. Agreed, I have not phrased this precisely enough. I was actually referring to the TCP friendly congestion control for each SCTP path, i.e. the fact that if there are n TCP connections and 1 SCTP association with m paths (engaged in what you nicely call "concurrent multipath transfer") then an additional TCP connection would obtain another 1/(m+n+1)-th part of the bandwidth. So clearly, ONE SCTP assoc grabs more than a fair share, but there is still some "fairness". So: actually we are both d'accord ! Best regards, Andreas - -- Dipl.-Ing. Andreas Jungmaier Computer Networking Technology Group University of Duisburg-Essen http://www.exp-math.uni-essen.de/~ajung My PGP Key-ID: D3824AC0 My PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+moa8XAsLBNOCSsARAgmBAJ47EHfI6UIv/RyxGciwB7IukakusQCfVPpq ObMhoKPL5k9d1PBmhf2QSmg= =qetK -----END PGP SIGNATURE----- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 23 08:00:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14616 for ; Wed, 23 Apr 2003 08:00:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3NCCL618889 for tsvwg-archive@odin.ietf.org; Wed, 23 Apr 2003 08:12:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NCAv818809; Wed, 23 Apr 2003 08:10:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NC9g818740 for ; Wed, 23 Apr 2003 08:09:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14531 for ; Wed, 23 Apr 2003 07:57:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198IuR-00037C-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 07:59:31 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 198IuQ-000379-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 07:59:30 -0400 Received: from mannersaari.cs.Helsinki.FI (mannersaari.cs.helsinki.fi [::ffff:128.214.11.173]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 23 Apr 2003 14:59:54 +0300 Date: Wed, 23 Apr 2003 14:59:54 +0300 (EEST) From: Jukka MJ Manner To: tsvwg@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Request for feedback about the Localized RSVP Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, I had a short presentation of the Localized RSVP extension to RSVP at the last IETF meeting. The ADs proposed that I should see from the working group people, whether there is interest in doing something like we have proposed, to have a mechanism for setting up local resource reservations. The draft has motivations about when this would be a useful thing. Thus, if people could read the draft (it is not that long :) and answer to two questions: 1) Is the concept of local resource reservations a good idea in the first place? 2) If the above answer was "yes", is our approach using RSVP a good one, and could be taken further in the TSVWG? The announcement and a link to the draft is below. Best regards, Jukka Manner --------------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Localized RSVP Author(s) : J. Manner et al. Filename : draft-manner-lrsvp-01.txt Pages : 16 Date : 2003-1-14 Guaranteed QoS for multimedia applications is based on reserved resources in each node on the end-to-end path. Even if the correspondent node does not support QoS, it would be useful to be able to reserve at least local resources at the access network, especially wireless link resources. Additionally, for mobile nodes the continuity of QoS is disturbed due to end-to-end signaling or slow re-reservations of resources after each handover. This draft proposes a simple enhancement to RSVP, so that initial resource reservations and re-reservations due to host mobility can be done locally in an access network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-manner-lrsvp-01.txt _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 23 11:11:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22755 for ; Wed, 23 Apr 2003 11:11:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3NFNgr01344 for tsvwg-archive@odin.ietf.org; Wed, 23 Apr 2003 11:23:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NFMX801228; Wed, 23 Apr 2003 11:22:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NFJt801083 for ; Wed, 23 Apr 2003 11:19:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22636 for ; Wed, 23 Apr 2003 11:07:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198LsS-0004gJ-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 11:09:40 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 198LsR-0004fo-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 11:09:39 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h3NF9Aje000575; Wed, 23 Apr 2003 10:09:11 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3EA6AC96.2050809@stewart.chicago.il.us> Date: Wed, 23 Apr 2003 10:09:10 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: TSV WG list , Allison Mankin , Jon Peterson , Scott Bradner Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] PR-SCTP Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit All: I would like once again to bring up PR-SCTP for discussion... So far I have received several comments on the document and am preparing changes based on them. One unresolved issue is Mark Allmans comments on "junk" data. Mark and I agree that we have a fundamental difference of opinion on this... :-0 I don't think a transport protocol should police the data that an application sends over it... even if there are hints that are given saying "you can abandon this data if after some amount of time you can't get it through". To me this seems to improve chances of getting out of congestion faster since it may not be the case that the application as anything else to say for a while.. and even if it does.. overall you are reducing the load on the network by the data that you removed (since classic SCTP would retransmit it until it was sent on through). Mark feels that the parameters given could be used in some way to enforce on the app that it not use this feature to much... (Mark jump in and correct me if I mis-state things)... no matter if it is an abuser (for example sending multiple copies of data to speed things up) or a valid application.. junk data is junk data... If you do it to much you should in some way be penalized... aka make the data reliable or reset the connection.... Do others feel the same as Mark? Should a transport police the types of data being sent? ... I guess this falls in with some of Reiner's work as well (on FEC related use of the cwnd).. My opinion is obvious :> I am against this... Along with the above I would like to get other feedback... I would like to get this document moved on to last-call possibly after incorporating all of the comments.. to date... What does everyone think??? Thanks R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 23 12:03:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24621 for ; Wed, 23 Apr 2003 12:03:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3NGFQP06057 for tsvwg-archive@odin.ietf.org; Wed, 23 Apr 2003 12:15:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NGEB805931; Wed, 23 Apr 2003 12:14:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NG96805651 for ; Wed, 23 Apr 2003 12:09:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24372 for ; Wed, 23 Apr 2003 11:56:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198Me2-00055W-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 11:58:50 -0400 Received: from web10901.mail.yahoo.com ([216.136.131.37]) by ietf-mx with smtp (Exim 4.12) id 198Me1-00055T-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 11:58:50 -0400 Message-ID: <20030423155914.41814.qmail@web10901.mail.yahoo.com> Received: from [12.237.229.250] by web10901.mail.yahoo.com via HTTP; Wed, 23 Apr 2003 08:59:14 PDT Date: Wed, 23 Apr 2003 08:59:14 -0700 (PDT) From: Spencer Dawkins Subject: Re: [Tsvwg] PR-SCTP To: TSV WG list In-Reply-To: <3EA6AC96.2050809@stewart.chicago.il.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , OK, let me show how poorly I understand the issue. If an application gives clues to transport that something isn't as interesting as something else, how is this different from per-packet priority marking? My first take is that I'm not sure how transports know something is junk, in the general case. I'm actually interested in understanding more clearly what the axes of "interesting" look like. I think I'd like to understand this better, before providing local-optimal feedback. My understanding of Randall's concept is "deadline discard" - if you don't deliver this in 800 ms, don't bother? My understanding of Reiner's concept is "reduce retransmission latency by retransmitting" - if you have unACKed data and don't have anything else new to send, send the old data again? What are the other concepts that people are thinking about? Spencer _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 23 12:06:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24723 for ; Wed, 23 Apr 2003 12:06:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3NGIC806234 for tsvwg-archive@odin.ietf.org; Wed, 23 Apr 2003 12:18:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NGH4806192; Wed, 23 Apr 2003 12:17:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NGGY806137 for ; Wed, 23 Apr 2003 12:16:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24671 for ; Wed, 23 Apr 2003 12:03:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198MlF-00058R-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 12:06:17 -0400 Received: from gw.openss7.com ([142.179.199.224] ident=[7ErIgRX47bVFW5i9X1eaFsVdLc+WtvDU]) by ietf-mx with esmtp (Exim 4.12) id 198MlF-00058O-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 12:06:17 -0400 Received: from ns.pigworks.openss7.net (IDENT:fS1k+nTW1LzCUjg0EjTnfYaNarMQKSLy@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h3NG6W926217; Wed, 23 Apr 2003 10:06:32 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h3NG6Vv24301; Wed, 23 Apr 2003 10:06:31 -0600 Date: Wed, 23 Apr 2003 10:06:31 -0600 From: "Brian F. G. Bidulock" To: Randall Stewart Cc: TSV WG list , Allison Mankin , Jon Peterson , Scott Bradner Subject: Re: [Tsvwg] PR-SCTP Message-ID: <20030423100631.A23785@openss7.org> Reply-To: bidulock@openss7.org References: <3EA6AC96.2050809@stewart.chicago.il.us> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3EA6AC96.2050809@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Wed, Apr 23, 2003 at 10:09:10AM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id h3NG6W926217 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3NGGY806138 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Randall, I am against transports policing junk also. What other comments are you talking about? (I only saw the ladders that Mark started...) I don't see any problems with the latest draft. --brian On Wed, 23 Apr 2003, Randall Stewart wrote: > All: > > I would like once again to bring up PR-SCTP for discussion... > > So far I have received several comments on the document and > am preparing changes based on them. One unresolved > issue is Mark Allmans comments on "junk" data. > > Mark and I agree that we have a fundamental difference of opinion > on this... :-0 > > I don't think a transport protocol should police the data that > an application sends over it... even if there are hints that > are given saying "you can abandon this data if after some > amount of time you can't get it through". To me this seems to > improve chances of getting out of congestion faster since it > may not be the case that the application as anything else > to say for a while.. and even if it does.. overall you are > reducing the load on the network by the data that you removed > (since classic SCTP would retransmit it until it was sent > on through). > > Mark feels that the parameters given could be used in some > way to enforce on the app that it not use this feature to > much... (Mark jump in and correct me if I mis-state things)... > no matter if it is an abuser (for example sending multiple > copies of data to speed things up) or a valid application.. junk > data is junk data... If you do it to much you should in > some way be penalized... aka make the data reliable or > reset the connection.... > > Do others feel the same as Mark? Should a transport police > the types of data being sent? ... I guess this falls in > with some of Reiner's work as well (on FEC related use > of the cwnd).. My opinion is obvious :> I am against > this... > > Along with the above I would like to get other feedback... I > would like to get this document moved on to last-call possibly > after incorporating all of the comments.. to date... > > What does everyone think??? > > Thanks > > R > -- > Randall R. Stewart > randall@stewart.chicago.il.us 815-342-5222 (cell phone) > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 23 12:30:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25360 for ; Wed, 23 Apr 2003 12:30:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3NGgYv08271 for tsvwg-archive@odin.ietf.org; Wed, 23 Apr 2003 12:42:34 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NGfI808244; Wed, 23 Apr 2003 12:41:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NGem808206 for ; Wed, 23 Apr 2003 12:40:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25318 for ; Wed, 23 Apr 2003 12:28:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198N8h-0005JQ-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 12:30:31 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 198N8g-0005JN-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 12:30:30 -0400 Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id D01192453EE; Wed, 23 Apr 2003 12:30:40 -0400 (EDT) Date: Wed, 23 Apr 2003 11:33:07 -0500 From: Caitlin Bestler Subject: Re: [Tsvwg] PR-SCTP To: Randall Stewart , tsvwg@ietf.org X-Priority: 3 In-Reply-To: <3EA6AC96.2050809@stewart.chicago.il.us> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 4/23/03, Randall Stewart wrote: > >Do others feel the same as Mark? Should a transport police >the types of data being sent? ... I guess this falls in >with some of Reiner's work as well (on FEC related use >of the cwnd).. My opinion is obvious :> I am against >this... > Even if you agree that the transport layer should prevent or at least discourage abuse of network bandwidth by the application layer, it would not be PR-SCTP specific. Or even SCTP specific for that matter. PR-SCTP can never guarantee that payload will *not* be delivered. Even if you cancel it, the receiving side might still get the data before the cancellation. If there is a real concern for transports encouraging junk data, I would suggest a better target being congestion control itself. It encourages a "use it or lose it" mentality concerning bandwidth -- a problem not found with explicit rate control. I'm not advocating any specific solution -- but at least its a real problem. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 23 12:51:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25821 for ; Wed, 23 Apr 2003 12:51:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3NH3AX09329 for tsvwg-archive@odin.ietf.org; Wed, 23 Apr 2003 13:03:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NH28809293; Wed, 23 Apr 2003 13:02:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NH0x809207 for ; Wed, 23 Apr 2003 13:00:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25748 for ; Wed, 23 Apr 2003 12:48:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198NSD-0005Ql-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 12:50:41 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 198NSD-0005QX-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 12:50:41 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id B5CD168A21 for ; Wed, 23 Apr 2003 12:50:36 -0400 (EDT) Received: from guns.lerc.nasa.gov (guns.grc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3NGoZuW022351; Wed, 23 Apr 2003 12:50:36 -0400 (EDT) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id MAA22483; Wed, 23 Apr 2003 12:50:35 -0400 (EDT) Message-Id: <200304231650.MAA22483@guns.lerc.nasa.gov> To: Randall Stewart From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: TSV WG list , Allison Mankin , Jon Peterson , Scott Bradner Subject: Re: [Tsvwg] PR-SCTP In-Reply-To: <3EA6AC96.2050809@stewart.chicago.il.us> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Lodi Date: Wed, 23 Apr 2003 12:50:35 -0400 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , My last two notes on this subject from a couple week back stand as my opinion. I will not repeat them. But, I would be interested in others opinions (especially those we have no heard). But, a clarification... > Mark and I agree that we have a fundamental difference of opinion > on this... :-0 Indeed. > Mark feels that the parameters given could be used in some > way to enforce on the app that it not use this feature to > much... (Mark jump in and correct me if I mis-state things)... > no matter if it is an abuser (for example sending multiple > copies of data to speed things up) or a valid application.. junk > data is junk data... If you do it to much you should in > some way be penalized... aka make the data reliable or > reset the connection.... Note that "junk data" is maybe not the best way to describe it (even though I, no doubt, started that). We can determine data that was sent, dropped (with good probability) and not retransmitted using PR-SCTP. That data **accomplished no useful work and used scarce network resources**. (I see this as a pretty non-controversial opinion. Do we have agreement on it (i.e., only what I have written in this paragraph)?) And, then there is the question of what to do about data being sent that does not accomplish useful work. Also, I want to stress that I offered that **excessive** amounts of data transmitted without accomplishing useful work should be curbed. I never said it was a reason not to do PR-SCTP. allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 23 12:54:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25891 for ; Wed, 23 Apr 2003 12:54:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3NH6FA09486 for tsvwg-archive@odin.ietf.org; Wed, 23 Apr 2003 13:06:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NH55809428; Wed, 23 Apr 2003 13:05:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NH4h809401 for ; Wed, 23 Apr 2003 13:04:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25853 for ; Wed, 23 Apr 2003 12:52:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198NVq-0005SM-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 12:54:26 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 198NVp-0005SB-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 12:54:25 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h3NGs9je000742; Wed, 23 Apr 2003 11:54:11 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3EA6C531.2090205@stewart.chicago.il.us> Date: Wed, 23 Apr 2003 11:54:09 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: TSV WG list , Allison Mankin , Jon Peterson , Scott Bradner Subject: Re: [Tsvwg] PR-SCTP References: <3EA6AC96.2050809@stewart.chicago.il.us> <20030423100631.A23785@openss7.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I believe there are actually four (two off-line and one at the TSV meeting)... 1) The current document uses the term "drop" .. this to some in TSV is confusing.. aka a router will "drop" a packet due to congestion. Instead the term "abandon" aka the user decides to "abandon" a packet.. is being substituted for "drop" 2) There was a typo in the document the word "parameter" is miss-spelled 3) Allison wanted a clearification in the service model presented in the document that an application cannot change the lifetime of a message after it was sent. This is implied in some places but not spelled out... It was also due to some poor wording choices in the document as to who is evalutating ... etc: So the following clearifications are put in (note the line numbers are against my xml file..not the draft)... 887c896 The sender MAY evaluate the lifetime of messages at anytime. --- The sending SCTP MAY evaluate the lifetime of messages at anytime. 891a901,904 TR6) The sending application MUST NOT change the lifetime parameter once the message is passed to the sending SCTP. 900c913 < implementor flexibility to evaluate lifetime at any other convenient --- > SCTP implementor flexibility to evaluate lifetime at any other convenien 4) Comments at the tsv were made that it was not clear that normal cwnd adjustments should be made when timers go off even if you decide to abandon a chunk.. So a new F5) will be added that specifies: If a decision to "abandon" a chunk is made based on a retransmission decision (e.g T3-Timeout or Fast Retransmit) the appropriate congestion adjustment as specified in RFC2960 MUST be made before any FORWARD TSN chunk is sent. These are all I have.. unless others pop up :-> R Brian F. G. Bidulock wrote: > Randall, > > I am against transports policing junk also. > > What other comments are you talking about? (I only > saw the ladders that Mark started...) > > I don't see any problems with the latest draft. > > --brian > > On Wed, 23 Apr 2003, Randall Stewart wrote: > > >>All: >> >>I would like once again to bring up PR-SCTP for discussion... >> >>So far I have received several comments on the document and >>am preparing changes based on them. One unresolved >>issue is Mark Allmans comments on "junk" data. >> >>Mark and I agree that we have a fundamental difference of opinion >>on this... :-0 >> >>I don't think a transport protocol should police the data that >>an application sends over it... even if there are hints that >>are given saying "you can abandon this data if after some >>amount of time you can't get it through". To me this seems to >>improve chances of getting out of congestion faster since it >>may not be the case that the application as anything else >>to say for a while.. and even if it does.. overall you are >>reducing the load on the network by the data that you removed >>(since classic SCTP would retransmit it until it was sent >> on through). >> >>Mark feels that the parameters given could be used in some >>way to enforce on the app that it not use this feature to >>much... (Mark jump in and correct me if I mis-state things)... >>no matter if it is an abuser (for example sending multiple >>copies of data to speed things up) or a valid application.. junk >>data is junk data... If you do it to much you should in >>some way be penalized... aka make the data reliable or >>reset the connection.... >> >>Do others feel the same as Mark? Should a transport police >>the types of data being sent? ... I guess this falls in >>with some of Reiner's work as well (on FEC related use >>of the cwnd).. My opinion is obvious :> I am against >>this... >> >>Along with the above I would like to get other feedback... I >>would like to get this document moved on to last-call possibly >>after incorporating all of the comments.. to date... >> >>What does everyone think??? >> >>Thanks >> >>R >>-- >>Randall R. Stewart >>randall@stewart.chicago.il.us 815-342-5222 (cell phone) >> >>_______________________________________________ >>tsvwg mailing list >>tsvwg@ietf.org >>https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 23 12:59:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26324 for ; Wed, 23 Apr 2003 12:59:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3NHBDw10651 for tsvwg-archive@odin.ietf.org; Wed, 23 Apr 2003 13:11:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NHA6810570; Wed, 23 Apr 2003 13:10:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NH9Y810516 for ; Wed, 23 Apr 2003 13:09:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26050 for ; Wed, 23 Apr 2003 12:56:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198NaW-0005Up-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 12:59:17 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 198NaW-0005Tz-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 12:59:16 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h3NGx3je000752; Wed, 23 Apr 2003 11:59:03 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3EA6C657.6050009@stewart.chicago.il.us> Date: Wed, 23 Apr 2003 11:59:03 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@grc.nasa.gov CC: TSV WG list , Allison Mankin , Jon Peterson , Scott Bradner Subject: Re: [Tsvwg] PR-SCTP References: <200304231650.MAA22483@guns.lerc.nasa.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mark Allman wrote: > My last two notes on this subject from a couple week back stand as > my opinion. I will not repeat them. But, I would be interested in > others opinions (especially those we have no heard). > > But, a clarification... > > >>Mark and I agree that we have a fundamental difference of opinion >>on this... :-0 > > > Indeed. > we surely agree here :> > >>Mark feels that the parameters given could be used in some >>way to enforce on the app that it not use this feature to >>much... (Mark jump in and correct me if I mis-state things)... >>no matter if it is an abuser (for example sending multiple >>copies of data to speed things up) or a valid application.. junk >>data is junk data... If you do it to much you should in >>some way be penalized... aka make the data reliable or >>reset the connection.... > > > Note that "junk data" is maybe not the best way to describe it (even > though I, no doubt, started that). It might be nice to have a better term.. but I did not want to muddy the water by changing terms :-0 We can determine data that was > sent, dropped (with good probability) and not retransmitted using > PR-SCTP. That data **accomplished no useful work and used scarce > network resources**. (I see this as a pretty non-controversial > opinion. Do we have agreement on it (i.e., only what I have written > in this paragraph)?) Well, Caitlin actually had a good point.. just because you abandon a chunk does NOT mean it did not get delivered... so it COULD have done some useful work... you the sender just do not know if it got there at all (in a timely manner where it was used) or not.... it may have... with a ACK loss making you think it did not.. or it may NOT have and then the above would have been true... But I guess your "good probability" qualification may be saying this :> > > And, then there is the question of what to do about data being sent > that does not accomplish useful work. > > Also, I want to stress that I offered that **excessive** amounts of > data transmitted without accomplishing useful work should be curbed. > I never said it was a reason not to do PR-SCTP. Thanks for the clearification.. I too would like to hear what others think.. R > > allman > > > -- > Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 23 13:03:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26477 for ; Wed, 23 Apr 2003 13:03:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3NHFEa10983 for tsvwg-archive@odin.ietf.org; Wed, 23 Apr 2003 13:15:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NHE7810868; Wed, 23 Apr 2003 13:14:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NHDN810806 for ; Wed, 23 Apr 2003 13:13:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26400 for ; Wed, 23 Apr 2003 13:00:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198NeE-0005ad-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 13:03:06 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 198NeD-0005aH-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 13:03:05 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 1368768A21 for ; Wed, 23 Apr 2003 13:03:01 -0400 (EDT) Received: from guns.lerc.nasa.gov (guns.grc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3NH30uW026013; Wed, 23 Apr 2003 13:03:00 -0400 (EDT) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id NAA22699; Wed, 23 Apr 2003 13:03:00 -0400 (EDT) Message-Id: <200304231703.NAA22699@guns.lerc.nasa.gov> To: Randall Stewart From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: TSV WG list , Allison Mankin , Jon Peterson , Scott Bradner Subject: Re: [Tsvwg] PR-SCTP In-Reply-To: <3EA6C657.6050009@stewart.chicago.il.us> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Lodi Date: Wed, 23 Apr 2003 13:03:00 -0400 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > > We can determine data that was sent, dropped (with good > > probability) and not retransmitted using PR-SCTP. That data > > **accomplished no useful work and used scarce network > > resources**. (I see this as a pretty non-controversial opinion. > > Do we have agreement on it (i.e., only what I have written in > > this paragraph)?) > > Well, Caitlin actually had a good point.. just because you abandon a > chunk does NOT mean it did not get delivered... so it COULD have done > some useful work... you the sender just do not know if it got there > at all (in a timely manner where it was used) or not.... it may > have... with a ACK loss making you think it did not.. or it may > NOT have and then the above would have been true... But I guess > your "good probability" qualification may be saying this :> Yes, that was my intent. allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 23 15:15:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02421 for ; Wed, 23 Apr 2003 15:15:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3NJRfW21049 for tsvwg-archive@odin.ietf.org; Wed, 23 Apr 2003 15:27:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NJQO820986; Wed, 23 Apr 2003 15:26:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NJPX820913 for ; Wed, 23 Apr 2003 15:25:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02087 for ; Wed, 23 Apr 2003 15:12:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198Pi5-0006YE-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 15:15:13 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 198Pi4-0006Xw-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 15:15:12 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h3NJF6je000958; Wed, 23 Apr 2003 14:15:06 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3EA6E63A.2090607@stewart.chicago.il.us> Date: Wed, 23 Apr 2003 14:15:06 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: lglaude@pt.com CC: TSV WG list Subject: Re: [Tsvwg] PR-SCTP References: <3EA6AC96.2050809@stewart.chicago.il.us> <3EA6D076.8060400@pt.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Laurent: Thanks for your response.. I am copying the list (hope thats ok) .. maybe you forgot to do the reply-all think :> R Laurent Glaude wrote: > Randall, > > I support your view that the transport layer should not police the data > that an application sends over it. I do not believe that PR-SCTP > provides an incentive to send "junk data". > > -Laurent > > Randall Stewart wrote: > >> All: >> >> I would like once again to bring up PR-SCTP for discussion... >> >> So far I have received several comments on the document and >> am preparing changes based on them. One unresolved >> issue is Mark Allmans comments on "junk" data. >> >> Mark and I agree that we have a fundamental difference of opinion >> on this... :-0 >> >> I don't think a transport protocol should police the data that >> an application sends over it... even if there are hints that >> are given saying "you can abandon this data if after some >> amount of time you can't get it through". To me this seems to >> improve chances of getting out of congestion faster since it >> may not be the case that the application as anything else >> to say for a while.. and even if it does.. overall you are >> reducing the load on the network by the data that you removed >> (since classic SCTP would retransmit it until it was sent >> on through). >> >> Mark feels that the parameters given could be used in some >> way to enforce on the app that it not use this feature to >> much... (Mark jump in and correct me if I mis-state things)... >> no matter if it is an abuser (for example sending multiple >> copies of data to speed things up) or a valid application.. junk >> data is junk data... If you do it to much you should in >> some way be penalized... aka make the data reliable or >> reset the connection.... >> >> Do others feel the same as Mark? Should a transport police >> the types of data being sent? ... I guess this falls in >> with some of Reiner's work as well (on FEC related use >> of the cwnd).. My opinion is obvious :> I am against >> this... >> >> Along with the above I would like to get other feedback... I >> would like to get this document moved on to last-call possibly >> after incorporating all of the comments.. to date... >> >> What does everyone think??? >> >> Thanks >> >> R > > > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 23 15:34:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03690 for ; Wed, 23 Apr 2003 15:34:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3NJl1B22899 for tsvwg-archive@odin.ietf.org; Wed, 23 Apr 2003 15:47:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NJjG822816; Wed, 23 Apr 2003 15:45:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NJiJ822738 for ; Wed, 23 Apr 2003 15:44:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03268 for ; Wed, 23 Apr 2003 15:31:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198Q0E-0006jf-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 15:33:58 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 198Q0D-0006iw-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 15:33:57 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3NJXcID023412; Wed, 23 Apr 2003 12:33:38 -0700 (PDT) Received: from MRAMALHO-W2K1.cisco.com (dhcp-64-100-135-217.cisco.com [64.100.135.217]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ADM50334; Wed, 23 Apr 2003 12:33:36 -0700 (PDT) Message-Id: <4.3.2.7.2.20030423151457.016b4ff8@mira-sjc5-9.cisco.com> X-Sender: mramalho@mira-sjc5-9.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Apr 2003 15:33:35 -0400 To: mallman@grc.nasa.gov, Randall Stewart From: "Michael A. Ramalho" Subject: Re: [Tsvwg] PR-SCTP Cc: TSV WG list , Allison Mankin , Jon Peterson , Scott Bradner In-Reply-To: <200304231650.MAA22483@guns.lerc.nasa.gov> References: <3EA6AC96.2050809@stewart.chicago.il.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Mark ... A comment or two ... Michael Ramalho At 12:50 PM 4/23/2003 -0400, Mark Allman wrote: >My last two notes on this subject from a couple week back stand as >my opinion. I will not repeat them. But, I would be interested in >others opinions (especially those we have no heard). > >But, a clarification... > > > Mark and I agree that we have a fundamental difference of opinion > > on this... :-0 > >Indeed. > > > Mark feels that the parameters given could be used in some > > way to enforce on the app that it not use this feature to > > much... (Mark jump in and correct me if I mis-state things)... > > no matter if it is an abuser (for example sending multiple > > copies of data to speed things up) or a valid application.. junk > > data is junk data... If you do it to much you should in > > some way be penalized... aka make the data reliable or > > reset the connection.... > >Note that "junk data" is maybe not the best way to describe it (even >though I, no doubt, started that). We can determine data that was >sent, dropped (with good probability) and not retransmitted using >PR-SCTP. That data **accomplished no useful work and used scarce >network resources**. (I see this as a pretty non-controversial >opinion. Do we have agreement on it (i.e., only what I have written >in this paragraph)?) Yes, I'd agree with the "**" sentence as it stands. However, it is - in my view - an artful sentence that clouds the issue. (Hey Mark .. don't get bent out of shape ... I meant this as a compliment ... not everyone can write like a sentence that :-) ). The application *did not know a priori* it was using scarce resources - this became apparent only "after the fact". Then the application, *given the choice of getting more current data now rather than getting old data .. then the new data* chose the latter. And note the latter actually reduced the congestion by the entropy of the chunk that became "abandoned" (Randall's new descriptive term). >And, then there is the question of what to do about data being sent >that does not accomplish useful work. Obviously, if you knew that a priori ... you would not have sent it! There are many applications with the property that they monitor changing parameters. These applications usually send at regular intervals ... and, in the absence of congestion, would like data at all the time intervals the data is sent. PR-SCTP "timed reliability" provides another mechanism for the application to chose what gets abandoned in the hope that: 1) it will get more recent data sooner (because it is not behind the now stale data) and 2) it actually will reduce the congestion episode by *not* injecting the (now more stale) data into the network (i.e., by *saving network resources* when you really need them saved ... during congestion episodes). I suggested in my earlier posts that I believed this is close to optimum behavior during congestion episodes (i.e., without a priori information) ... and you did not refute or challenge that claim. So I am at a loss to address your concern lacking either: 1) "a priori knowledge on congestion" or 2) a "garbage/relevance" gauge that the transport could use to determine "excessive/bad/junk/redundant" data. >Also, I want to stress that I offered that **excessive** amounts of >data transmitted without accomplishing useful work should be curbed. I agree that this should be discouraged ... I just don't know how to enforce/police at the transport level. >I never said it was a reason not to do PR-SCTP. Good to hear that. >allman > > >-- >Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg Michael A. Ramalho, Ph.D. Office email: mramalho@cisco.com Personal email: mar42@cornell.edu Office: +1.941.708.4650 Cell: +1.941.544.2844 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 23 21:01:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16710 for ; Wed, 23 Apr 2003 21:01:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3O13Mi14229 for tsvwg-archive@odin.ietf.org; Wed, 23 Apr 2003 21:03:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3O127814133; Wed, 23 Apr 2003 21:02:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3O10D814013 for ; Wed, 23 Apr 2003 21:00:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16646 for ; Wed, 23 Apr 2003 20:57:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198V5P-0001ar-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 20:59:39 -0400 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 198V5P-0001ao-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 20:59:39 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h3O104EN024950 for ; Wed, 23 Apr 2003 18:00:04 -0700 (MST) Received: from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id h3O102Oq003156 for ; Wed, 23 Apr 2003 20:00:03 -0500 Received: from motorola.com (QUANTIX21 [160.47.57.248]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 2DANZCS1; Wed, 23 Apr 2003 20:00:01 -0500 Message-ID: <3EA73721.26118D60@motorola.com> Date: Wed, 23 Apr 2003 20:00:17 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Spencer Dawkins CC: TSV WG list Subject: Re: [Tsvwg] PR-SCTP References: <20030423155914.41814.qmail@web10901.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Spencer Dawkins wrote: > > OK, let me show how poorly I understand the issue. > > If an application gives clues to transport that something isn't > as interesting as something else, how is this different from > per-packet priority marking? To be more precise, the app is not saying that the data is less interesting. Rather, in the case of PR-SCTP, the apps is simply saying that *this piece of data is equally interesting/important as any other at this moment, but it will become less useful after x seconds* For this reason, I wouldn't call it "junk data". Maybe better to call it "time sensitive data". -Qiaobing > > My first take is that I'm not sure how transports know something > is junk, in the general case. I'm actually interested in > understanding more clearly what the axes of "interesting" look > like. I think I'd like to understand this better, before > providing local-optimal feedback. > > My understanding of Randall's concept is "deadline discard" - if > you don't deliver this in 800 ms, don't bother? > > My understanding of Reiner's concept is "reduce retransmission > latency by retransmitting" - if you have unACKed data and don't > have anything else new to send, send the old data again? > > What are the other concepts that people are thinking about? > > Spencer > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 23 22:26:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18926 for ; Wed, 23 Apr 2003 22:26:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3O2SXN19686 for tsvwg-archive@odin.ietf.org; Wed, 23 Apr 2003 22:28:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3O2RU819670; Wed, 23 Apr 2003 22:27:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3O2QH819621 for ; Wed, 23 Apr 2003 22:26:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18883 for ; Wed, 23 Apr 2003 22:23:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198WQf-00024k-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 22:25:41 -0400 Received: from web10906.mail.yahoo.com ([216.136.131.42]) by ietf-mx with smtp (Exim 4.12) id 198WQf-00024g-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 22:25:41 -0400 Message-ID: <20030424022606.28800.qmail@web10906.mail.yahoo.com> Received: from [12.237.229.250] by web10906.mail.yahoo.com via HTTP; Wed, 23 Apr 2003 19:26:06 PDT Date: Wed, 23 Apr 2003 19:26:06 -0700 (PDT) From: Spencer Dawkins Subject: Re: [Tsvwg] PR-SCTP To: tsvwg@ietf.org In-Reply-To: <3EA73721.26118D60@motorola.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , OK, that actually helped in Randall's case - I was thinking about a linear decay, but see that Randall is talking about a right-angle decay... I think my question still applies in Reiner's case (the sender knows that the data could very well have gotten there the first time, but would rather retransmit than sit idly and wait for a timer to pop). Spencer --- Qiaobing Xie wrote: > Spencer Dawkins wrote: > > > > OK, let me show how poorly I understand the issue. > > > > If an application gives clues to transport that something > isn't > > as interesting as something else, how is this different from > > per-packet priority marking? > > To be more precise, the app is not saying that the data is > less > interesting. Rather, in the case of PR-SCTP, the apps is > simply saying > that *this piece of data is equally interesting/important as > any other > at this moment, but it will become less useful after x > seconds* > > For this reason, I wouldn't call it "junk data". Maybe better > to call it > "time sensitive data". > > -Qiaobing _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 23 22:40:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19275 for ; Wed, 23 Apr 2003 22:40:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3O2hIX21072 for tsvwg-archive@odin.ietf.org; Wed, 23 Apr 2003 22:43:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3O2gB821043; Wed, 23 Apr 2003 22:42:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3O2fh821020 for ; Wed, 23 Apr 2003 22:41:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19233 for ; Wed, 23 Apr 2003 22:38:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198Wfc-000284-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 22:41:08 -0400 Received: from gw.openss7.com ([142.179.199.224] ident=[QYp/VHOZoJXn15oOc5aIm/++Ap2PE2Ev]) by ietf-mx with esmtp (Exim 4.12) id 198Wfb-000281-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 22:41:07 -0400 Received: from ns.pigworks.openss7.net (IDENT:i+VTjL0pcfnw3tHWzV9GnloNssyZ12IZ@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h3O2fX902977; Wed, 23 Apr 2003 20:41:33 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h3O2fWP07552; Wed, 23 Apr 2003 20:41:32 -0600 Date: Wed, 23 Apr 2003 20:41:32 -0600 From: "Brian F. G. Bidulock" To: Spencer Dawkins Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] PR-SCTP Message-ID: <20030423204132.A7494@openss7.org> Reply-To: bidulock@openss7.org References: <3EA73721.26118D60@motorola.com> <20030424022606.28800.qmail@web10906.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030424022606.28800.qmail@web10906.mail.yahoo.com>; from spencer_dawkins@yahoo.com on Wed, Apr 23, 2003 at 07:26:06PM -0700 Organization: http://www.openss7.org/ Dsn-Notification-To: X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id h3O2fX902977 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3O2fi821022 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Spencer, Regardless of where you attempt to police FEC or excessive retransmissions, the application can simply retransmit one layer up and avoid whatever measures are taken at the lower layer. IMO Only a measure that penalizes an application for sending data would thwart FEC (at the cost of bulk data transfer). I don't believe that this is a PR-SCTP gating issue at all. I think it is a general issue outside the scope of PR-SCTP. I also don't think that PR-SCTP should be delayed in advancing while disussing this more general question. My 2 cents. --brian On Wed, 23 Apr 2003, Spencer Dawkins wrote: > OK, that actually helped in Randall's case - I was thinking > about a linear decay, but see that Randall is talking about a > right-angle decay... > > I think my question still applies in Reiner's case (the sender > knows that the data could very well have gotten there the first > time, but would rather retransmit than sit idly and wait for a > timer to pop). > > Spencer > > --- Qiaobing Xie wrote: > > Spencer Dawkins wrote: > > > > > > OK, let me show how poorly I understand the issue. > > > > > > If an application gives clues to transport that something > > isn't > > > as interesting as something else, how is this different from > > > per-packet priority marking? > > > > To be more precise, the app is not saying that the data is > > less > > interesting. Rather, in the case of PR-SCTP, the apps is > > simply saying > > that *this piece of data is equally interesting/important as > > any other > > at this moment, but it will become less useful after x > > seconds* > > > > For this reason, I wouldn't call it "junk data". Maybe better > > to call it > > "time sensitive data". > > > > -Qiaobing > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 23 23:36:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20828 for ; Wed, 23 Apr 2003 23:36:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3O3cfP24628 for tsvwg-archive@odin.ietf.org; Wed, 23 Apr 2003 23:38:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3O3bc824594; Wed, 23 Apr 2003 23:37:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3O3a8823721 for ; Wed, 23 Apr 2003 23:36:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20798 for ; Wed, 23 Apr 2003 23:33:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198XWF-0002Rd-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 23:35:31 -0400 Received: from web10904.mail.yahoo.com ([216.136.131.40]) by ietf-mx with smtp (Exim 4.12) id 198XWE-0002Ra-00 for tsvwg@ietf.org; Wed, 23 Apr 2003 23:35:30 -0400 Message-ID: <20030424033556.71600.qmail@web10904.mail.yahoo.com> Received: from [12.237.229.250] by web10904.mail.yahoo.com via HTTP; Wed, 23 Apr 2003 20:35:56 PDT Date: Wed, 23 Apr 2003 20:35:56 -0700 (PDT) From: Spencer Dawkins Subject: Re: [Tsvwg] PR-SCTP To: tsvwg@ietf.org In-Reply-To: <20030423204132.A7494@openss7.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , --- "Brian F. G. Bidulock" wrote: > Spencer, > > Regardless of where you attempt to police FEC or excessive > retransmissions, the application can simply retransmit one > layer up and avoid whatever measures are taken at the lower > layer. > > IMO Only a measure that penalizes an application for sending > data would thwart FEC (at the cost of bulk data transfer). Are there only sticks, and no carrots? We've had better luck getting people to deploy using carrots (congestion avoidance, HTTP/1.1, CIDR ...) > > I don't believe that this is a PR-SCTP gating issue at all. > I think it is a general issue outside the scope of PR-SCTP. > I also don't think that PR-SCTP should be delayed in advancing > while disussing this more general question. Agreed. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Apr 24 05:11:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09075 for ; Thu, 24 Apr 2003 05:11:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3O9E0Z25479 for tsvwg-archive@odin.ietf.org; Thu, 24 Apr 2003 05:14:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3O9CT825389; Thu, 24 Apr 2003 05:12:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3O9BR825346 for ; Thu, 24 Apr 2003 05:11:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08989 for ; Thu, 24 Apr 2003 05:08:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198ckd-00041G-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 05:10:43 -0400 Received: from irmgard.exp-math.uni-essen.de ([132.252.150.18]) by ietf-mx with esmtp (Exim 4.12) id 198ckc-00041D-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 05:10:43 -0400 Received: from gina.exp-math.uni-essen.de (gina.exp-math.uni-essen.de [132.252.150.131]) by irmgard.exp-math.uni-essen.de (8.12.8/8.12.2) with ESMTP id h3O9B3JF050318; Thu, 24 Apr 2003 11:11:03 +0200 From: Andreas Jungmaier Organization: University Duisburg-Essen To: Randall Stewart , TSV WG list , Allison Mankin , Jon Peterson , Scott Bradner Subject: Re: [Tsvwg] PR-SCTP Date: Thu, 24 Apr 2003 11:09:41 +0200 User-Agent: KMail/1.5 References: <3EA6AC96.2050809@stewart.chicago.il.us> In-Reply-To: <3EA6AC96.2050809@stewart.chicago.il.us> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200304241109.42995.ajung@exp-math.uni-essen.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3O9BR825347 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, I am under the impression that the "discussion" started by Mark is a "pseudo"-discussion, more for the sake of having a discussion than making a point. Suppose three degrees of freedom (as transport protocol): 1.TCP, 2.plain SCTP, 3.PR-SCTP. For an application that wants to transmit all data reliably, it will be able to choose from either of the three, and in the case of PR-SCTP specify an infinite lifetime, i.e. reliable delivery, of all data (essentially the same as plain SCTP). Of course, the application may profit from SCTP multi-homing, especially in the case where congestion occurs, and retransmission go along a different, otherwise idle path. Now, things become interesting for applications that make use of the unreliable delivery feature, and specify a lifetime for data to be sent. Will this be an incentive for applications to sent more data ? The applications cannot be sure that the data is NOT sent over the wire, a priori, so any data submitted to the transport PR-SCTP may or may not be sent, and therefore may, in the worst case *for the application*, hurt the application's congestion window. I don't think this is an incentive for applications to send "junk" data (or data that better not be sent). As retransmissions are more likely to occur in situations where the network experiences congestion, PR-SCTP may relieve this congestion compared to plain SCTP or TCP, where TCP will insist on retransmitting the data to the same transport address. Plain SCTP may do the same (in case associations are single-homed), and will still put more load on the network than PR-SCTP (in case associations are multi-homed and use distinct phiysical paths). So, is PR-SCTP a bad thing ? I do not think so, for the above reasons. It will relieve the network over the long run. My 2 cents. Andreas - -- Dipl.-Ing. Andreas Jungmaier Computer Networking Technology Group University of Duisburg-Essen http://www.exp-math.uni-essen.de/~ajung My PGP Key-ID: D3824AC0 My PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+p6nVXAsLBNOCSsARAmZwAKDvjDaUUUv6ON9qBWvJEyjoym+OowCgvgCz ViLhJPPqQCqlHOLnNllCeu4= =ad88 -----END PGP SIGNATURE----- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Apr 24 08:22:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14318 for ; Thu, 24 Apr 2003 08:22:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3OCPRO05792 for tsvwg-archive@odin.ietf.org; Thu, 24 Apr 2003 08:25:27 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OCNi805719; Thu, 24 Apr 2003 08:23:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OCMI805656 for ; Thu, 24 Apr 2003 08:22:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14274 for ; Thu, 24 Apr 2003 08:19:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198fjG-0005Tw-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 08:21:30 -0400 Received: from d53-66-209.clv.wideopenwest.com ([64.53.209.66] helo=lawyers.ir.bbn.com) by ietf-mx with esmtp (Exim 4.12) id 198fjG-0005Tt-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 08:21:30 -0400 Received: by lawyers.ir.bbn.com (Postfix, from userid 9076) id CB6426B2B9; Thu, 24 Apr 2003 08:21:02 -0400 (EDT) To: tsvwg@ietf.org From: Mark Allman Reply-To: mallman@grc.nasa.gov Organization: BBN Technologies/NASA GRC Song-of-the-Day: Lodi Date: Thu, 24 Apr 2003 08:21:02 -0400 Message-Id: <20030424122102.CB6426B2B9@lawyers.ir.bbn.com> Subject: [Tsvwg] early retransmit limits Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Now for something different and the same.... I'm interested in hearing some opinions on what to do about limiting the use of early retransmit. We are in the process of updating the ID on the subject -- the current version is draft-allman-tcp-early-rexmt-00.txt. To briefly recap the draft says that when the amount of outstanding data is < 4 segments and the TCP sender has no new data to send (ala limited transmit) then TCP can use ownd-1 dupacks to trigger fast retransmit behavior rather than waiting for the RTO to fire. The idea is basically that in this case TCP knows that it will never get 3 duplicate ACKs and cannot induce 3 duplicate ACKs with new data. In the draft we sketch two versions of "worst case" scenarios whereby one-third of the packets sent into the network are needless retransmits caused by reordering not loss. So, the question is what, if anything, do we do about this worst case. So, I'd like to see some discussion / opinions on a range of reasonable options... OPTION A -------- Just don't do early retransmit. The cost, in terms of network wasteage and/or network wasteage prevention is just not worth it for the benefits that ER provides. OPTION B -------- Ust use early retransmit without worrying about preventing bogus retransmits. In other words, the cases where this really breaks and sends a huge amount of wasteful traffic into the network are pathelogical and ER is tightly scoped enough that we don't need to worry about a limit. OPTION C -------- Allow ER, but only once per connection. Most connections (especially those that will benefit from ER) are short. So, this will help lots of connections. Also, this scheme is easy and cheap to implement. But, it will not help long connections through networks where cwnd is less than 4 segments (due to either low bandwidth or lots of statistical multiplexing). OPTION D -------- Allow some percentage of transmissions to be spurious. The deployment path here is sort of two-fold. (D.1) If the sender and receiver are using timestamps the sender can use Eifel to figure out whether an ERed segment was spurious or not. Alternatively, if the receiver sends DSACKs (which the sender has to "learn" by seeing one) then we can use those to detect spuriously ERed segments. In either case, we count the number of ERed segments that were wrongly sent and make sure that this number is some small precent (say 3% -- an order of magnitude less than the worst case ER wasteage) of the total traffic being sent. (D.2) In the case when neither timestamps nor DSACKs are used the sender can still use ER. But, the sender must not ER more than some small percent (same as above - say 3%) of segments via ER. Essentially, this scheme makes the conservative assumption that every segment sent with ER is bogus for limiting purposes. (And, so, it is clearly more advantageous to the sender to use a D.1-like scheme.) OPTION E -------- The same D.1, but replace D.2 with OPTION C -- so, if you don't have fine-grained information about the spuriousness of what you are sending then you can only send one ER per connection. (Of course, this would also have to come with a way to detect that DSACK was supported -- say, by overlapping the first two packets by one byte or some such kludginess.) OPTION x -------- Some other tightly specified option that someone thinks of. Send text. My personal leaning is towards option B. (And, I do not speak for my co-authors who can (and hopefully will) assert their own preferences.) One of the problems is that C, D and E only address and limit the spuriousness for long connections. But, for connections that only send 3 packets (2 unique data packets and a retransmit -- see draft for a better sketch of this "worst case") none of these mitigations actually helps at all. Also, I think the worst case is pathelogical enough (2 (or 3) segment window, persisten reordering that is just so and a TCP that cannot send new data) that even without limiting we're not going to see a ton of spurious retransmits running around the network because of ER. I'd be thrilled to hear opinions on which option others like best. Thanks! allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Apr 24 09:26:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15897 for ; Thu, 24 Apr 2003 09:26:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3ODTEZ10027 for tsvwg-archive@odin.ietf.org; Thu, 24 Apr 2003 09:29:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ODQR809876; Thu, 24 Apr 2003 09:26:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ODP4809824 for ; Thu, 24 Apr 2003 09:25:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15814 for ; Thu, 24 Apr 2003 09:21:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198ghz-0005sw-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 09:24:15 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 198ghy-0005st-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 09:24:14 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3ODObRs019313; Thu, 24 Apr 2003 15:24:37 +0200 (MEST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id JPSH9R1X; Thu, 24 Apr 2003 15:23:41 +0200 Received: from res0010384da36.eed.ericsson.se (dhcp5-109 [164.48.135.109]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id PAA01275; Thu, 24 Apr 2003 15:23:38 +0200 (MET DST) Message-Id: <5.2.0.9.0.20030424151732.028b6a60@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 24 Apr 2003 15:23:51 +0200 To: mallman@grc.nasa.gov From: Reiner Ludwig Subject: Re: [Tsvwg] early retransmit limits Cc: tsvwg@ietf.org In-Reply-To: <20030424122102.CB6426B2B9@lawyers.ir.bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At 14:21 24.04.2003, Mark Allman wrote: >My personal leaning is towards option B. As I said before, I'm convinced that option B is the right way to go. >Also, I think the >worst case is pathelogical enough (2 (or 3) segment window, >persisten reordering that is just so and a TCP that cannot send new >data) that even without limiting we're not going to see a ton of >spurious retransmits running around the network because of ER. I'm also convinced that this worst-case is so pathological that we shouldn't worry about it. ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Apr 24 10:05:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16894 for ; Thu, 24 Apr 2003 10:05:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3OE8SM13235 for tsvwg-archive@odin.ietf.org; Thu, 24 Apr 2003 10:08:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OE7H812790; Thu, 24 Apr 2003 10:07:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OE5i812254 for ; Thu, 24 Apr 2003 10:05:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16579 for ; Thu, 24 Apr 2003 10:02:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198hLK-00066a-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 10:04:54 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 198hLJ-00066S-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 10:04:54 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 1783432983; Thu, 24 Apr 2003 10:05:16 -0400 (EDT) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 575A332987; Thu, 24 Apr 2003 10:05:15 -0400 (EDT) Date: Thu, 24 Apr 2003 10:05:15 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Mark Allman Cc: Subject: Re: [Tsvwg] early retransmit limits In-Reply-To: <20030424122102.CB6426B2B9@lawyers.ir.bbn.com> Message-ID: X-Spam-Status: No, hits=-5.0 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Thu, 24 Apr 2003, Mark Allman wrote: > OPTION B > -------- > Ust use early retransmit without worrying about preventing bogus > retransmits. In other words, the cases where this really breaks and > sends a huge amount of wasteful traffic into the network are > pathelogical and ER is tightly scoped enough that we don't need to > worry about a limit. I think I prefer option B, but if there is a concern about too many spurious retransmits occuring... perhaps one option may be to use a timer similar to the delayed ack timer. That way, the sender provides the opportunity for either new data to be sent or the ack for a reordered segment to arrive. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Apr 24 10:15:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17834 for ; Thu, 24 Apr 2003 10:15:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3OEIEl13593 for tsvwg-archive@odin.ietf.org; Thu, 24 Apr 2003 10:18:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OEH6813545; Thu, 24 Apr 2003 10:17:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OEGM813511 for ; Thu, 24 Apr 2003 10:16:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17614 for ; Thu, 24 Apr 2003 10:13:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198hVc-00069D-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 10:15:32 -0400 Received: from maestra.inria.fr ([138.96.112.24] ident=root) by ietf-mx with esmtp (Exim 4.12) id 198hVb-00069A-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 10:15:31 -0400 Received: from sophia.inria.fr (localhost [127.0.0.1]) by maestra.inria.fr (8.12.8/8.12.5) with ESMTP id h3OEFvkK009119; Thu, 24 Apr 2003 16:15:57 +0200 Message-ID: <3EA7F19D.60109@sophia.inria.fr> Date: Thu, 24 Apr 2003 16:15:57 +0200 From: Urtzi Ayesta User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030317 X-Accept-Language: fr-FR, en, eu, es-ES MIME-Version: 1.0 To: mallman@grc.nasa.gov CC: tsvwg@ietf.org Subject: Re: [Tsvwg] early retransmit limits References: <20030424122102.CB6426B2B9@lawyers.ir.bbn.com> In-Reply-To: <20030424122102.CB6426B2B9@lawyers.ir.bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi all, here are some thoughts I wouldn't go for options D and E since they need to specify a parameter (the percentage) and in my opinion this introduces some arbitrariness that I'm not comfortable with since we don't know much about what this value should be. In this sense we are introducing some complexity into the algorithm without a remarkable benefit. I wouldn't go for setting a hard threshold (option C) since the aim of ER is to avoid lengthy timeouts for short TCP connections as well as for interactive applications which send data in bursts. Setting a hard threshold we fail in the case of interactive applications. Maybe we could consider setting a larger hard threshold to provide some flexibility for long sessions as well, but again what should be the value of this threshold... as a coauthour I wouldn't go for option A... :-) So my personal leaning is also towards B. I expect that systematic high reordering to be pathological behaviour and ER is in a certain way self-controling since it would only trigger when the flying number of segments is small. regards, urtzi Mark Allman wrote: > > >OPTION A >-------- >Just don't do early retransmit. The cost, in terms of network >wasteage and/or network wasteage prevention is just not worth it >for the benefits that ER provides. > >OPTION B >-------- >Ust use early retransmit without worrying about preventing bogus >retransmits. In other words, the cases where this really breaks and >sends a huge amount of wasteful traffic into the network are >pathelogical and ER is tightly scoped enough that we don't need to >worry about a limit. > >OPTION C >-------- >Allow ER, but only once per connection. Most connections >(especially those that will benefit from ER) are short. So, this >will help lots of connections. Also, this scheme is easy and cheap >to implement. But, it will not help long connections through >networks where cwnd is less than 4 segments (due to either low >bandwidth or lots of statistical multiplexing). > >OPTION D >-------- >Allow some percentage of transmissions to be spurious. The >deployment path here is sort of two-fold. > >(D.1) If the sender and receiver are using timestamps the sender can > use Eifel to figure out whether an ERed segment was spurious or > not. Alternatively, if the receiver sends DSACKs (which the > sender has to "learn" by seeing one) then we can use those to > detect spuriously ERed segments. In either case, we count the > number of ERed segments that were wrongly sent and make sure > that this number is some small precent (say 3% -- an order of > magnitude less than the worst case ER wasteage) of the total > traffic being sent. > >(D.2) In the case when neither timestamps nor DSACKs are used the > sender can still use ER. But, the sender must not ER more than > some small percent (same as above - say 3%) of segments via ER. > Essentially, this scheme makes the conservative assumption that > every segment sent with ER is bogus for limiting purposes. > (And, so, it is clearly more advantageous to the sender to use a > D.1-like scheme.) > >OPTION E >-------- >The same D.1, but replace D.2 with OPTION C -- so, if you don't have >fine-grained information about the spuriousness of what you are >sending then you can only send one ER per connection. (Of course, >this would also have to come with a way to detect that DSACK was >supported -- say, by overlapping the first two packets by one byte >or some such kludginess.) > > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Apr 24 10:35:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18462 for ; Thu, 24 Apr 2003 10:35:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3OEcTQ15498 for tsvwg-archive@odin.ietf.org; Thu, 24 Apr 2003 10:38:29 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OEbD814954; Thu, 24 Apr 2003 10:37:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OEaZ814557 for ; Thu, 24 Apr 2003 10:36:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18414 for ; Thu, 24 Apr 2003 10:33:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198hpA-0006GC-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 10:35:44 -0400 Received: from maestra.inria.fr ([138.96.112.24] ident=root) by ietf-mx with esmtp (Exim 4.12) id 198hpA-0006G9-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 10:35:44 -0400 Received: from sophia.inria.fr (localhost [127.0.0.1]) by maestra.inria.fr (8.12.8/8.12.5) with ESMTP id h3OEa9kK009235; Thu, 24 Apr 2003 16:36:09 +0200 Message-ID: <3EA7F659.5070208@sophia.inria.fr> Date: Thu, 24 Apr 2003 16:36:09 +0200 From: Urtzi Ayesta User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030317 X-Accept-Language: fr-FR, en, eu, es-ES MIME-Version: 1.0 To: "Armando L. Caro Jr." CC: tsvwg@ietf.org Subject: Re: [Tsvwg] early retransmit limits References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Armando L. Caro Jr. wrote: >On Thu, 24 Apr 2003, Mark Allman wrote: > >I think I prefer option B, but if there is a concern about too many >spurious retransmits occuring... perhaps one option may be to use a timer >similar to the delayed ack timer. That way, the sender provides the >opportunity for either new data to be sent or the ack for a reordered >segment to arrive. > > > this seems to be a reasonable possibility. The value of the timer could be the same as the one for delayed ACK, couldn't it? thanks urtzi _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Apr 24 11:08:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19296 for ; Thu, 24 Apr 2003 11:08:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3OFAhH17834 for tsvwg-archive@odin.ietf.org; Thu, 24 Apr 2003 11:10:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OF99817705; Thu, 24 Apr 2003 11:09:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OF8k817668 for ; Thu, 24 Apr 2003 11:08:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19093 for ; Thu, 24 Apr 2003 11:05:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198iKJ-0006QU-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 11:07:55 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 198iKJ-0006QM-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 11:07:55 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 773276895C for ; Thu, 24 Apr 2003 11:07:52 -0400 (EDT) Received: from guns.lerc.nasa.gov (guns.grc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3OF7puW010435; Thu, 24 Apr 2003 11:07:51 -0400 (EDT) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id LAA35464; Thu, 24 Apr 2003 11:07:51 -0400 (EDT) Message-Id: <200304241507.LAA35464@guns.lerc.nasa.gov> To: "Armando L. Caro Jr." From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] early retransmit limits In-Reply-To: Organization: BBN Technologies/NASA GRC Song-of-the-Day: Dead Flowers Date: Thu, 24 Apr 2003 11:07:51 -0400 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Armando- > if there is a concern about too many spurious retransmits > occuring... perhaps one option may be to use a timer similar to > the delayed ack timer. That way, the sender provides the > opportunity for either new data to be sent or the ack for a > reordered segment to arrive. I don't follow... Are you saying that we should do Vern Paxson's trick of using < 3 dupacks, but adding a small timeout as well? So, something like "after 2 dupacks + 20 msec we can fast retransmit". If not, can you try to explain again (maybe with an example)? I am just not sure I am following yet. Thanks! allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Apr 24 15:22:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29558 for ; Thu, 24 Apr 2003 15:22:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3OJOvG03675 for tsvwg-archive@odin.ietf.org; Thu, 24 Apr 2003 15:24:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OJNR803631; Thu, 24 Apr 2003 15:23:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OJMt803607 for ; Thu, 24 Apr 2003 15:22:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29454 for ; Thu, 24 Apr 2003 15:19:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198mIA-0000SM-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 15:21:58 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 198mIA-0000SD-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 15:21:58 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 33EDF32953; Thu, 24 Apr 2003 15:22:25 -0400 (EDT) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 6AD66328BA; Thu, 24 Apr 2003 15:22:24 -0400 (EDT) Date: Thu, 24 Apr 2003 15:22:24 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Mark Allman Cc: Urtzi Ayesta , Subject: Re: [Tsvwg] early retransmit limits In-Reply-To: <200304241507.LAA35464@guns.lerc.nasa.gov> Message-ID: X-Spam-Status: No, hits=-5.0 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Thu, 24 Apr 2003, Mark Allman wrote: > I don't follow... Are you saying that we should do Vern Paxson's > trick of using < 3 dupacks, but adding a small timeout as well? I don't know which trick you are referring to, but it sounds like Vern's trick is similar to what I was thinking... > So, something like "after 2 dupacks + 20 msec we can fast retransmit". Yes. I am not sure about the 20ms begin the delay though. Maybe Urtzi's idea of the same delay as the delayed ack algorithm uses would fine. But anyway, let's first understand the idea properly... The idea is to allow early retransmit to occur, but to try being conservative by allowing the chance for either (a) 3 dupacks or (b) the hole to be filled in case of reordering. case (a) 1. Suppose the sender sends segments 1, 2, and 3. 2. The receiver receives segments 2 and 3, and sends two dupacks for 1. 3. The sender receives two dupacks for 1 (i.e., segment 1 is missing). 4. Since the TCP sender has no other data in flight and no more data to send, ER comes into play. However, the sender delays x ms before retransmitting. 5. If within the x ms delay the sending application provides the TCP sender with more data to send, ER is not triggered. Instead, the TCP sender sends segment 4 and waits for the third dupack for segment 1 to arrive. Upon receiving the third dupack for segment 1, the TCP can do a "normal" Fast Retransmit. 6. Otherwise, retransmit segment 1. case (b) 1. Sender sends segments 1, 2, and 3. 2. The receiver receives segments 2, 3, and 1... in that order. 3. The sender receives two dupacks for 1, which may begin to imply that segment 1 is missing. 4. Again, since the TCP sender has no other data in flight and no more data to send, ER comes into play, but delays x ms before retransmitting. 5. If the ack for segment 1 arrives at the sender before the x ms delay expires, then the sender infers that a reordering occured (as in this example) and no retransmission is necessary. 6. Otherwise, retransmit segment 1. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Apr 24 15:40:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29991 for ; Thu, 24 Apr 2003 15:40:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3OJhEv05221 for tsvwg-archive@odin.ietf.org; Thu, 24 Apr 2003 15:43:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OJgA805187; Thu, 24 Apr 2003 15:42:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OJfE805149 for ; Thu, 24 Apr 2003 15:41:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29963 for ; Thu, 24 Apr 2003 15:37:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198mZt-0000ZT-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 15:40:17 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 198mZt-0000ZN-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 15:40:17 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 963BA689B4 for ; Thu, 24 Apr 2003 15:40:14 -0400 (EDT) Received: from guns.lerc.nasa.gov (guns.grc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3OJeEuW025510; Thu, 24 Apr 2003 15:40:14 -0400 (EDT) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id PAA39903; Thu, 24 Apr 2003 15:40:13 -0400 (EDT) Message-Id: <200304241940.PAA39903@guns.lerc.nasa.gov> To: "Armando L. Caro Jr." From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: Urtzi Ayesta , tsvwg@ietf.org Subject: Re: [Tsvwg] early retransmit limits In-Reply-To: Organization: BBN Technologies/NASA GRC Song-of-the-Day: Dead Flowers Date: Thu, 24 Apr 2003 15:40:13 -0400 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Armando- Thanks for the clarification. The ideas makes good sense to me now. I'm happy to throw that option on the list as a possibility. So, the list is something like: option A - no ER option B - ER as defined in the draft option C - ER, but only once per connection option D - use Eifel or DSACKs to ensure that bogus ERs are < some small percent of the data sent; if we don't have DSACK or timestamps, then just say that ERs cannot amount to more than this small percent of the data we send option E - use Eifel or DSACKs as option D; if we don't have timestamps or DSACKs then revert to option C and ER at most once per connection option F - ER after ownd - 1 dupacks arrive and some timeout occurs (hoping that in the idle time we get an ACK that indicates reordering or a new segment to send ala limited transmit) I still don't like A. Go figure... And, I still think C-E are predicated on us thinking that B would cause too much spurious traffic in the network. F tries to be more robust than B (at the cost of a bit of extra machinery). Is F enough better that we then don't need to think about C-E? I still like B. But, wait .... I guess what I'd really like to know is whether folks are worried about option B. Several people have indicated on the list (and off to me today) that they think ER ala B is scoped enough that it is Just OK. Before having a long discussion about C-F I guess I'd like to get a feeling for whether some are concerned about B (which I think is clearly the easiest path). Thanks! allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Apr 24 17:39:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05069 for ; Thu, 24 Apr 2003 17:39:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3OLgIV14840 for tsvwg-archive@odin.ietf.org; Thu, 24 Apr 2003 17:42:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OLek814741; Thu, 24 Apr 2003 17:40:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OLde814663 for ; Thu, 24 Apr 2003 17:39:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04978 for ; Thu, 24 Apr 2003 17:36:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198oQT-0001ma-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 17:38:41 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 198oQS-0001mJ-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 17:38:41 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id C6F1B689A9 for ; Thu, 24 Apr 2003 17:38:38 -0400 (EDT) Received: from sunfire.grc.nasa.gov (IDENT:root@sunfire.grc.nasa.gov [139.88.111.70]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3OLccuW023335 for ; Thu, 24 Apr 2003 17:38:38 -0400 (EDT) Received: (from jishac@localhost) by sunfire.grc.nasa.gov (8.11.4/8.11.4) id h3OLcNi28210 for tsvwg@ietf.org; Thu, 24 Apr 2003 17:38:23 -0400 Date: Thu, 24 Apr 2003 17:38:23 -0400 From: Joseph Ishac To: tsvwg@ietf.org Subject: Re: [Tsvwg] early retransmit limits Message-ID: <20030424173823.A28115@sunfire.grc.nasa.gov> Reply-To: Joseph Ishac Mail-Followup-To: Joseph Ishac , tsvwg@ietf.org References: <200304241940.PAA39903@guns.lerc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200304241940.PAA39903@guns.lerc.nasa.gov>; from mallman@grc.nasa.gov on Thu, Apr 24, 2003 at 03:40:13PM -0400 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Thu, Apr 24, 2003 at 03:40:13PM -0400, Mark Allman wrote: > option A - no ER > option B - ER as defined in the draft > option C - ER, but only once per connection > option D - use Eifel or DSACKs to ensure that bogus ERs are < > some small percent of the data sent; if we don't have DSACK > or timestamps, then just say that ERs cannot amount to more > than this small percent of the data we send > option E - use Eifel or DSACKs as option D; if we don't have > timestamps or DSACKs then revert to option C and ER at most > once per connection > option F - ER after ownd - 1 dupacks arrive and some timeout > occurs (hoping that in the idle time we get an ACK that > indicates reordering or a new segment to send ala limited > transmit) > > I still don't like A. Go figure... > > And, I still think C-E are predicated on us thinking that B would > cause too much spurious traffic in the network. F tries to be more > robust than B (at the cost of a bit of extra machinery). Is F > enough better that we then don't need to think about C-E? > > I still like B. But, wait .... > > I guess what I'd really like to know is whether folks are worried > about option B. Several people have indicated on the list (and off > to me today) that they think ER ala B is scoped enough that it is > Just OK. Before having a long discussion about C-F I guess I'd like > to get a feeling for whether some are concerned about B (which I > think is clearly the easiest path). I can't think a way to really break option B, so I'd vote for it ;) However, I think it would be beneficial to research the benefit of options that strengthen ER (~if needed~). So, if network conditions change and reordering becomes more prevalent, we would know what the benefit/impact of using ER would be (in its different forms). On a side note. There are studies to try and make TCP more robust to packet reordering. One such method is to increase dupthresh, and I'll use that in the next example. Suppose that during a connection, we've grown dupthresh to a value greater than three. If the connection then later experiences an ER situation, is ER still valid? (b/c an increased dupthresh would mean that you've experienced some amount of reordering, which is non-negligible) -Joseph _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Apr 24 22:23:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13475 for ; Thu, 24 Apr 2003 22:23:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3P2Ptl01755 for tsvwg-archive@odin.ietf.org; Thu, 24 Apr 2003 22:25:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P2Oj801725; Thu, 24 Apr 2003 22:24:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P2ND801691 for ; Thu, 24 Apr 2003 22:23:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13388 for ; Thu, 24 Apr 2003 22:19:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198sqk-00041M-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 22:22:07 -0400 Received: from x86unx3.comp.nus.edu.sg ([137.132.90.3]) by ietf-mx with esmtp (Exim 4.12) id 198sqj-00041J-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 22:22:06 -0400 Received: from e500b.comp.nus.edu.sg (e500b.comp.nus.edu.sg [137.132.90.26]) by x86unx3.comp.nus.edu.sg (8.9.1/8.9.1) with SMTP id KAA01837 for ; Fri, 25 Apr 2003 10:22:25 +0800 (GMT-8) Received: from se11.comp.nus.edu.sg(137.132.80.19) by e500b.comp.nus.edu.sg via csmap id 14828; Fri, 25 Apr 2003 02:21:36 +0000 (UTC) Received: (from http@localhost) by se11.comp.nus.edu.sg (8.12.2+Sun/8.12.5) id h3P2MPbi004192; Fri, 25 Apr 2003 10:22:25 +0800 (SGT) X-Authentication-Warning: se11.comp.nus.edu.sg: http set sender to srijith@comp.nus.edu.sg using -f Received: from noc.comp.nus.edu.sg ([137.132.80.35]) (proxying for 137.132.83.73) (SquirrelMail authenticated user srijith) by mysoc.nus.edu.sg with HTTP; Fri, 25 Apr 2003 10:22:24 +0800 (SGT) Message-ID: <1598.137.132.80.35.1051237344.squirrel@mysoc.nus.edu.sg> Date: Fri, 25 Apr 2003 10:22:24 +0800 (SGT) Subject: Re: [Tsvwg] early retransmit limits From: "Srijith. K" To: In-Reply-To: References: <200304241507.LAA35464@guns.lerc.nasa.gov> X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.11) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit To add to option F, the *max* of the delay should be such that you give just enough time for the ACK of the retransmitted packet to reach the sender before the timeout occurs. So, d(max)=RTO-x where x can be RTT(smooth) or RTT(max) or RTT(prev). Srijith > Yes. I am not sure about the 20ms begin the delay though. Maybe Urtzi's > idea of the same delay as the delayed ack algorithm uses would fine. But > anyway, let's first understand the idea properly... > > The idea is to allow early retransmit to occur, but to try being > conservative by allowing the chance for either (a) 3 dupacks or (b) the > hole to be filled in case of reordering. > > case (a) > > 1. Suppose the sender sends segments 1, 2, and 3. > > 2. The receiver receives segments 2 and 3, and sends two dupacks for > 1. > > 3. The sender receives two dupacks for 1 (i.e., segment 1 is > missing). > > 4. Since the TCP sender has no other data in flight and no more > data to send, ER comes into play. However, the sender delays x ms > before retransmitting. > > 5. If within the x ms delay the sending application provides the > TCP sender with more data to send, ER is not triggered. Instead, > the TCP sender sends segment 4 and waits for the third dupack for > segment 1 to arrive. Upon receiving the third dupack for segment > 1, the TCP can do a "normal" Fast Retransmit. > > 6. Otherwise, retransmit segment 1. > > > case (b) > > 1. Sender sends segments 1, 2, and 3. > > 2. The receiver receives segments 2, 3, and 1... in that order. > > 3. The sender receives two dupacks for 1, which may begin to imply > that segment 1 is missing. > > 4. Again, since the TCP sender has no other data in flight and no > more data to send, ER comes into play, but delays x ms before > retransmitting. > > 5. If the ack for segment 1 arrives at the sender before the x ms > delay expires, then the sender infers that a reordering occured > (as in this example) and no retransmission is necessary. > > 6. Otherwise, retransmit segment 1. > > > ~armando > > 0-- --0 > | Armando L. Caro Jr. | Protocol Engineering Lab | > | www.cis.udel.edu/~acaro | University of Delaware | > 0-- --0 > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Apr 24 22:29:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13620 for ; Thu, 24 Apr 2003 22:29:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3P2WHN02161 for tsvwg-archive@odin.ietf.org; Thu, 24 Apr 2003 22:32:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P2V5802085; Thu, 24 Apr 2003 22:31:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P2U4801876 for ; Thu, 24 Apr 2003 22:30:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13553 for ; Thu, 24 Apr 2003 22:26:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198sxO-000447-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 22:28:58 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 198sxO-000444-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 22:28:58 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 9171732986; Thu, 24 Apr 2003 22:29:26 -0400 (EDT) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id C7DC8328D4; Thu, 24 Apr 2003 22:29:25 -0400 (EDT) Date: Thu, 24 Apr 2003 22:29:25 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Joseph Ishac Cc: Subject: Re: [Tsvwg] early retransmit limits In-Reply-To: <20030424173823.A28115@sunfire.grc.nasa.gov> Message-ID: X-Spam-Status: No, hits=-5.0 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Thu, 24 Apr 2003, Joseph Ishac wrote: > I can't think a way to really break option B, so I'd vote for it ;) Yes, you do... reordering ;-) > However, I think it would be beneficial to research the benefit of > options that strengthen ER (~if needed~). So, if network conditions > change and reordering becomes more prevalent, we would know what the > benefit/impact of using ER would be (in its different forms). > > On a side note. There are studies to try and make TCP more robust to > packet reordering. One such method is to increase dupthresh, and I'll Well, my assumption was that the work that people are doing with TCP and reordering is because reordering _does_ occur. I remember reading at least one paper which said that reordering wasn't pathological (that was the title actually). So my question is... is it _that_ unlikely that the network is reordering, ownd < 4, and the sender doesn't have any more data to send. Personally, _I_ don't know that we can say that, but maybe someone else has more insight in this area. > use that in the next example. Suppose that during a connection, we've > grown dupthresh to a value greater than three. If the connection then > later experiences an ER situation, is ER still valid? (b/c an increased > dupthresh would mean that you've experienced some amount of reordering, > which is non-negligible) Maybe this problem is where option F would work well. If the dupack threshold is dynamic based on reordering experienced, then ER comes into play anytime ownd < dupack threshold. Then by using a delayed ER (option F), the sender is being extra conservative and taking into consideration the reordering already experienced. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Apr 24 22:30:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13659 for ; Thu, 24 Apr 2003 22:30:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3P2XJW02209 for tsvwg-archive@odin.ietf.org; Thu, 24 Apr 2003 22:33:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P2W3802134; Thu, 24 Apr 2003 22:32:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P2V2802069 for ; Thu, 24 Apr 2003 22:31:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13581 for ; Thu, 24 Apr 2003 22:27:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198syK-00044v-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 22:29:56 -0400 Received: from x86unx3.comp.nus.edu.sg ([137.132.90.3]) by ietf-mx with esmtp (Exim 4.12) id 198syJ-00044g-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 22:29:55 -0400 Received: from e500b.comp.nus.edu.sg (e500b.comp.nus.edu.sg [137.132.90.26]) by x86unx3.comp.nus.edu.sg (8.9.1/8.9.1) with SMTP id KAA02336 for ; Fri, 25 Apr 2003 10:30:21 +0800 (GMT-8) Received: from se11.comp.nus.edu.sg(137.132.80.19) by e500b.comp.nus.edu.sg via csmap id 14669; Fri, 25 Apr 2003 02:29:32 +0000 (UTC) Received: (from http@localhost) by se11.comp.nus.edu.sg (8.12.2+Sun/8.12.5) id h3P2UKZ6004753; Fri, 25 Apr 2003 10:30:20 +0800 (SGT) X-Authentication-Warning: se11.comp.nus.edu.sg: http set sender to srijith@comp.nus.edu.sg using -f Received: from noc.comp.nus.edu.sg ([137.132.80.35]) (proxying for 137.132.83.73) (SquirrelMail authenticated user srijith) by mysoc.nus.edu.sg with HTTP; Fri, 25 Apr 2003 10:30:20 +0800 (SGT) Message-ID: <4073.137.132.80.35.1051237820.squirrel@mysoc.nus.edu.sg> Date: Fri, 25 Apr 2003 10:30:20 +0800 (SGT) Subject: Re: [Tsvwg] early retransmit limits From: "Srijith. K" To: In-Reply-To: References: <200304241507.LAA35464@guns.lerc.nasa.gov> X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.11) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Opps.. on second thought: d(max)=(RTO-time_already_waiting_for_ack) - x x=RTT(smooth) or RTT(max) or RTT(prev) Regards, Srijith > Yes. I am not sure about the 20ms begin the delay though. Maybe Urtzi's > idea of the same delay as the delayed ack algorithm uses would fine. But > anyway, let's first understand the idea properly... > > The idea is to allow early retransmit to occur, but to try being > conservative by allowing the chance for either (a) 3 dupacks or (b) the > hole to be filled in case of reordering. > > case (a) > > 1. Suppose the sender sends segments 1, 2, and 3. > > 2. The receiver receives segments 2 and 3, and sends two dupacks for > 1. > > 3. The sender receives two dupacks for 1 (i.e., segment 1 is > missing). > > 4. Since the TCP sender has no other data in flight and no more > data to send, ER comes into play. However, the sender delays x ms > before retransmitting. > > 5. If within the x ms delay the sending application provides the > TCP sender with more data to send, ER is not triggered. Instead, > the TCP sender sends segment 4 and waits for the third dupack for > segment 1 to arrive. Upon receiving the third dupack for segment > 1, the TCP can do a "normal" Fast Retransmit. > > 6. Otherwise, retransmit segment 1. > > > case (b) > > 1. Sender sends segments 1, 2, and 3. > > 2. The receiver receives segments 2, 3, and 1... in that order. > > 3. The sender receives two dupacks for 1, which may begin to imply > that segment 1 is missing. > > 4. Again, since the TCP sender has no other data in flight and no > more data to send, ER comes into play, but delays x ms before > retransmitting. > > 5. If the ack for segment 1 arrives at the sender before the x ms > delay expires, then the sender infers that a reordering occured > (as in this example) and no retransmission is necessary. > > 6. Otherwise, retransmit segment 1. > > > ~armando > > 0-- --0 > | Armando L. Caro Jr. | Protocol Engineering Lab | > | www.cis.udel.edu/~acaro | University of Delaware | > 0-- --0 > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Apr 24 22:32:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13696 for ; Thu, 24 Apr 2003 22:32:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3P2Z9J02293 for tsvwg-archive@odin.ietf.org; Thu, 24 Apr 2003 22:35:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P2Y2802254; Thu, 24 Apr 2003 22:34:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P2Xc802225 for ; Thu, 24 Apr 2003 22:33:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13652 for ; Thu, 24 Apr 2003 22:30:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198t0q-00045z-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 22:32:32 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 198t0q-00045w-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 22:32:32 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id EF0A9328D4; Thu, 24 Apr 2003 22:33:00 -0400 (EDT) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 39F183289D; Thu, 24 Apr 2003 22:33:00 -0400 (EDT) Date: Thu, 24 Apr 2003 22:33:00 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: "Srijith. K" Cc: Subject: Re: [Tsvwg] early retransmit limits In-Reply-To: <1598.137.132.80.35.1051237344.squirrel@mysoc.nus.edu.sg> Message-ID: X-Spam-Status: No, hits=-5.0 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Fri, 25 Apr 2003, Srijith. K wrote: > To add to option F, the *max* of the delay should be such that you give > just enough time for the ACK of the retransmitted packet to reach the > sender before the timeout occurs. > > So, d(max)=RTO-x > where x can be RTT(smooth) or RTT(max) or RTT(prev). I think that the guidelines used for the delayed ack algorithm is a good starting point. Recommended: 200ms. Max: 500ms. If delayed ER gets close to a timeout, then the extra complexity isn't worth the potential gain. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Apr 24 23:35:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14210 for ; Thu, 24 Apr 2003 23:35:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3P3cSM06680 for tsvwg-archive@odin.ietf.org; Thu, 24 Apr 2003 23:38:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P3bP806347; Thu, 24 Apr 2003 23:37:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P3aq805791 for ; Thu, 24 Apr 2003 23:36:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14180 for ; Thu, 24 Apr 2003 23:33:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198u01-0004Gt-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 23:35:45 -0400 Received: from d53-66-209.clv.wideopenwest.com ([64.53.209.66] helo=lawyers.ir.bbn.com) by ietf-mx with esmtp (Exim 4.12) id 198tzw-0004Gq-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 23:35:40 -0400 Received: by lawyers.ir.bbn.com (Postfix, from userid 9076) id 7E4226B2B9; Thu, 24 Apr 2003 23:15:50 -0400 (EDT) To: Joseph Ishac From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] early retransmit limits In-Reply-To: <20030424173823.A28115@sunfire.grc.nasa.gov> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Dead Flowers Date: Thu, 24 Apr 2003 23:15:50 -0400 Message-Id: <20030425031550.7E4226B2B9@lawyers.ir.bbn.com> Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > However, I think it would be beneficial to research the benefit of > options that strengthen ER (~if needed~). So, if network > conditions change and reordering becomes more prevalent, we would > know what the benefit/impact of using ER would be (in its > different forms). I agree that if reordering became a lot more prevlent then it would behoove us to re-think ER (both in terms of network resource wasteage and the cwnd sacrifice that ER causes). Put another way, spurious ERs cause a penalty for the connection itself and so there is an incentive to not spuriously ER. > On a side note. There are studies to try and make TCP more robust > to packet reordering. One such method is to increase dupthresh, > and I'll use that in the next example. Suppose that during a > connection, we've grown dupthresh to a value greater than three. > If the connection then later experiences an ER situation, is ER > still valid? (b/c an increased dupthresh would mean that you've > experienced some amount of reordering, which is non-negligible) Maybe. In the dupthresh adjustment schemes sketched in draft-blanton-tcp-reordering-00.txt the dupthresh is cwnd-1 at its maximum. So, as the window drains dupthresh is reduced. But, clearly, we could keep a maxdupthresh that indicates if we have ever changed dupthresh based on reordering. But, if we're headed down that road then I think all we really need to do is look for duplicate ACKs and no loss and set a flag if we see such an event. Then we can use that as input to some sort of ER decision. (A dupack can be caused by packet replication in the network, but everything I have seen shows that to be quite rare.) My own opinion right now is that this is a bit of overkill for ER because its so tightly scoped. But, something to keep in mind for down the road if ER ends up busting a lot. Thanks! allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Apr 24 23:47:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14545 for ; Thu, 24 Apr 2003 23:47:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3P3oIu07433 for tsvwg-archive@odin.ietf.org; Thu, 24 Apr 2003 23:50:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P3n7807394; Thu, 24 Apr 2003 23:49:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P3mq807374 for ; Thu, 24 Apr 2003 23:48:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14531 for ; Thu, 24 Apr 2003 23:45:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198uBc-0004Mg-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 23:47:44 -0400 Received: from d53-66-209.clv.wideopenwest.com ([64.53.209.66] helo=lawyers.ir.bbn.com) by ietf-mx with esmtp (Exim 4.12) id 198uBc-0004Md-00 for tsvwg@ietf.org; Thu, 24 Apr 2003 23:47:44 -0400 Received: by lawyers.ir.bbn.com (Postfix, from userid 9076) id 756216B2B5; Thu, 24 Apr 2003 23:48:14 -0400 (EDT) To: "Armando L. Caro Jr." From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: Joseph Ishac , tsvwg@ietf.org Subject: Re: [Tsvwg] early retransmit limits In-Reply-To: Organization: BBN Technologies/NASA GRC Song-of-the-Day: Dead Flowers Date: Thu, 24 Apr 2003 23:48:14 -0400 Message-Id: <20030425034814.756216B2B5@lawyers.ir.bbn.com> Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > So my question is... is it _that_ unlikely that the network is > reordering, ownd < 4, and the sender doesn't have any more data to > send. Personally, _I_ don't know that we can say that, but maybe > someone else has more insight in this area. I would be concerned if I thought that this would cause a whole lot of extra stuff to be sent into the network. But, my feeling is that the situation that breaks ER is actually not going to add a huge percentage of unnecessary traffic to the network in general. I bet you could find some paths where it may be worse that others, but in the overall scheme of things I don't think it will lead to problems. But, without a whole pile of data from a whole pile of places I cannot say that for sure. (And, that sounds like a good argument for experimental to me.) > Maybe this problem is where option F would work well. If the > dupack threshold is dynamic based on reordering experienced, then > ER comes into play anytime ownd < dupack threshold. Which may be exactly what we have now if the dupack threshold is tied to cwnd (ala another i-d of mine). (Note that not all schemes might have the same properties.) allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 25 08:38:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06830 for ; Fri, 25 Apr 2003 08:38:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PCfSU22014 for tsvwg-archive@odin.ietf.org; Fri, 25 Apr 2003 08:41:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PCe5821880; Fri, 25 Apr 2003 08:40:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PCbl821686 for ; Fri, 25 Apr 2003 08:37:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06686 for ; Fri, 25 Apr 2003 08:34:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1992RJ-0000A4-00 for tsvwg@ietf.org; Fri, 25 Apr 2003 08:36:29 -0400 Received: from web10908.mail.yahoo.com ([216.136.131.44]) by ietf-mx with smtp (Exim 4.12) id 1992RI-0000A1-00 for tsvwg@ietf.org; Fri, 25 Apr 2003 08:36:28 -0400 Message-ID: <20030425123656.10324.qmail@web10908.mail.yahoo.com> Received: from [12.237.229.250] by web10908.mail.yahoo.com via HTTP; Fri, 25 Apr 2003 05:36:56 PDT Date: Fri, 25 Apr 2003 05:36:56 -0700 (PDT) From: Spencer Dawkins Subject: Re: [Tsvwg] early retransmit limits To: tsvwg@ietf.org In-Reply-To: <20030425034814.756216B2B5@lawyers.ir.bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Dear Mark, You guys understand this stuff more clearly than I do, but my spin is - the only connections affected are either in slow-start or application-limited, right? - the biggest burst we would see (on average) is one-half the dupack threshold, right? - with a dupack threshold of 3, we're within the burst rate we see at the beginning of a new connection using initial cwnd=4, right? - if we actually DO succeed in losing something on the forward path, we perform congestion avoidance anyway, right? If these are true, I don't think we need to worry about the effect of ER on the network with dupack threshold = 3. For higher values of dupack threshold, I'm less certain, but the answer is almost certainly tied to how big the dupack threshold is allowed to become. Spencer --- Mark Allman wrote: > > > So my question is... is it _that_ unlikely that the network > is > > reordering, ownd < 4, and the sender doesn't have any more > data to > > send. Personally, _I_ don't know that we can say that, but > maybe > > someone else has more insight in this area. > > I would be concerned if I thought that this would cause a > whole lot > of extra stuff to be sent into the network. But, my feeling > is that > the situation that breaks ER is actually not going to add a > huge > percentage of unnecessary traffic to the network in general. > I bet > you could find some paths where it may be worse that others, > but in > the overall scheme of things I don't think it will lead to > problems. But, without a whole pile of data from a whole pile > of > places I cannot say that for sure. (And, that sounds like a > good > argument for experimental to me.) > > > Maybe this problem is where option F would work well. If the > > dupack threshold is dynamic based on reordering experienced, > then > > ER comes into play anytime ownd < dupack threshold. > > Which may be exactly what we have now if the dupack threshold > is > tied to cwnd (ala another i-d of mine). (Note that not all > schemes > might have the same properties.) > > allman _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 25 09:02:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07442 for ; Fri, 25 Apr 2003 09:02:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PD5XB23275 for tsvwg-archive@odin.ietf.org; Fri, 25 Apr 2003 09:05:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PD4D823203; Fri, 25 Apr 2003 09:04:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PD3h823163 for ; Fri, 25 Apr 2003 09:03:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07423 for ; Fri, 25 Apr 2003 09:00:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1992qO-0000NP-00 for tsvwg@ietf.org; Fri, 25 Apr 2003 09:02:24 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 1992qO-0000NH-00 for tsvwg@ietf.org; Fri, 25 Apr 2003 09:02:24 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 1F7EC6899B for ; Fri, 25 Apr 2003 09:02:13 -0400 (EDT) Received: from guns.lerc.nasa.gov (guns.grc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3PD1buW020503; Fri, 25 Apr 2003 09:01:52 -0400 (EDT) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id JAA49978; Fri, 25 Apr 2003 09:01:37 -0400 (EDT) Message-Id: <200304251301.JAA49978@guns.lerc.nasa.gov> To: Spencer Dawkins From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] early retransmit limits In-Reply-To: <20030425123656.10324.qmail@web10908.mail.yahoo.com> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Dead Flowers Date: Fri, 25 Apr 2003 09:01:37 -0400 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Spencer- > - the only connections affected are either in slow-start or > application-limited, right? Or, if the advertised window is quite small. The slow start case may not actually be an issue because you can use limited transmit if you have new data to send and advertised window to do it. > - the biggest burst we would see (on average) is one-half the > dupack threshold, right? I don't follow this... ER acts just like a fast retransmit -- only it requires fewer duplicate ACKs. So, I don't understand where the bursting is coming from. > - with a dupack threshold of 3, we're within the burst rate we > see at the beginning of a new connection using initial cwnd=4, > right? (So, I can't answer this one either.) > - if we actually DO succeed in losing something on the forward > path, we perform congestion avoidance anyway, right? Right. ER is just an early fast retransmit. All the CC changes still apply. Really, we're just looking at all the information and judging that we could never fast retransmit if something was lost and given that then we're readjusting the trigger for fast retransmit. > For higher values of dupack threshold, I'm less certain, but the > answer is almost certainly tied to how big the dupack threshold > is allowed to become. Right. And, all that would have to be worked out if you wanted to apply ER to dupthresh > 3 -- but, the current document scopes it to specifically the current, static dupthresh. Thanks! allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 25 09:15:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07697 for ; Fri, 25 Apr 2003 09:15:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PDISq24836 for tsvwg-archive@odin.ietf.org; Fri, 25 Apr 2003 09:18:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PDHE824725; Fri, 25 Apr 2003 09:17:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PDDv824548 for ; Fri, 25 Apr 2003 09:13:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07579 for ; Fri, 25 Apr 2003 09:10:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19930I-0000Qw-00 for tsvwg@ietf.org; Fri, 25 Apr 2003 09:12:38 -0400 Received: from web10902.mail.yahoo.com ([216.136.131.38]) by ietf-mx with smtp (Exim 4.12) id 19930I-0000Qt-00 for tsvwg@ietf.org; Fri, 25 Apr 2003 09:12:38 -0400 Message-ID: <20030425131305.94007.qmail@web10902.mail.yahoo.com> Received: from [12.237.229.250] by web10902.mail.yahoo.com via HTTP; Fri, 25 Apr 2003 06:13:05 PDT Date: Fri, 25 Apr 2003 06:13:05 -0700 (PDT) From: Spencer Dawkins Subject: Re: [Tsvwg] early retransmit limits To: mallman@grc.nasa.gov Cc: tsvwg@ietf.org In-Reply-To: <200304251301.JAA49978@guns.lerc.nasa.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , OK, I mispoke... Me-getting-smarter inline... Spencer --- Mark Allman wrote: > > Spencer- > > > - the only connections affected are either in slow-start or > > application-limited, right? > > Or, if the advertised window is quite small. > > The slow start case may not actually be an issue because you > can use > limited transmit if you have new data to send and advertised > window > to do it. OK, so with the current dupack threshold = 3, the amount of additional traffic we might throw in is still less than 3 segments, right? > > > - the biggest burst we would see (on average) is one-half > the > > dupack threshold, right? > > I don't follow this... ER acts just like a fast retransmit -- > only > it requires fewer duplicate ACKs. So, I don't understand > where the > bursting is coming from. Sorry, I misused the word. I meant additional traffic that might not have happened if we'd RTOed instead. (and if I'm still confused). > > > - with a dupack threshold of 3, we're within the burst rate > we > > see at the beginning of a new connection using initial > cwnd=4, > > right? > > (So, I can't answer this one either.) Again, my point was that we are sending a small number of additional segments (compared to RTO) ... > > > - if we actually DO succeed in losing something on the > forward > > path, we perform congestion avoidance anyway, right? > > Right. ER is just an early fast retransmit. All the CC > changes > still apply. Really, we're just looking at all the > information and > judging that we could never fast retransmit if something was > lost > and given that then we're readjusting the trigger for fast > retransmit. So I think we are managing to agree, even though I was incoherent... > > > For higher values of dupack threshold, I'm less certain, but > the > > answer is almost certainly tied to how big the dupack > threshold > > is allowed to become. > > Right. And, all that would have to be worked out if you > wanted to > apply ER to dupthresh > 3 -- but, the current document scopes > it to > specifically the current, static dupthresh. > > Thanks! > > allman Thanks for helping me understand better... Spencer _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 25 09:23:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07963 for ; Fri, 25 Apr 2003 09:23:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PDQQW25482 for tsvwg-archive@odin.ietf.org; Fri, 25 Apr 2003 09:26:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PDPD825319; Fri, 25 Apr 2003 09:25:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PDOB825199 for ; Fri, 25 Apr 2003 09:24:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07848 for ; Fri, 25 Apr 2003 09:20:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1993A6-0000W3-00 for tsvwg@ietf.org; Fri, 25 Apr 2003 09:22:46 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 1993A6-0000Va-00 for tsvwg@ietf.org; Fri, 25 Apr 2003 09:22:46 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 3FA8968988 for ; Fri, 25 Apr 2003 09:22:34 -0400 (EDT) Received: from guns.lerc.nasa.gov (guns.grc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3PDM4uW025536; Fri, 25 Apr 2003 09:22:19 -0400 (EDT) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id JAA50275; Fri, 25 Apr 2003 09:22:04 -0400 (EDT) Message-Id: <200304251322.JAA50275@guns.lerc.nasa.gov> To: Spencer Dawkins From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] early retransmit limits In-Reply-To: <20030425131305.94007.qmail@web10902.mail.yahoo.com> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Dead Flowers Date: Fri, 25 Apr 2003 09:22:04 -0400 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > Sorry, I misused the word. I meant additional traffic that might > not have happened if we'd RTOed instead. (and if I'm still > confused). Ah... ok. So, the amount of additional traffic that ER would inject into the network over and above what the RTO would is: * zero in the case when the segment in question is actually lost * likely one segment in the case when reordering fools ER (that is, we likely resent a packet that would never have been resent via the RTO timer) Does that make sense? allman _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 25 12:13:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13427 for ; Fri, 25 Apr 2003 12:13:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PGGtv07226 for tsvwg-archive@odin.ietf.org; Fri, 25 Apr 2003 12:16:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PGFK807154; Fri, 25 Apr 2003 12:15:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PGEV807103 for ; Fri, 25 Apr 2003 12:14:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13364 for ; Fri, 25 Apr 2003 12:10:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1995oy-0001ke-00 for tsvwg@ietf.org; Fri, 25 Apr 2003 12:13:08 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 1995oy-0001jq-00 for tsvwg@ietf.org; Fri, 25 Apr 2003 12:13:08 -0400 Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 5FB81245A5D; Fri, 25 Apr 2003 12:13:21 -0400 (EDT) Date: Fri, 25 Apr 2003 11:15:54 -0500 From: Caitlin Bestler Subject: Re: [Tsvwg] PR-SCTP To: Spencer Dawkins Cc: TSV WG list X-Priority: 3 In-Reply-To: <20030423155914.41814.qmail@web10901.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 4/23/03, Spencer Dawkins wrote: >If an application gives clues to transport that something >isn't as interesting as something else, how is this >different from per-packet priority marking? Actually PR-SCTP is very different from per-packet priority marking in several important ways: -- Per-packet priority marking could be used by network elements to drop packets themselves. PR-SCTP only drops packets in the sending service, and only drops retransmissions. -- Because drops are done by the sending service, the set of packets dropped can be done in a service sensitive fashion and based upon dynamic information not available at the time the packet was originally sent. While at first glance it might seem preferable to allow the network elements forced to drop packets in the face of congenstion to be given hints on which packets to drop. But to be effective, such hints would have to be available on *most* of the packets going through the element. PR-SCTP is effective in optimizing an applications response to network congestion, no matter how many or how few other competing users are employing the same or similiar algorithms. Keep in mind that the purpose of dropping a packet for retransmission will typically be to avoid holding up more critical data that would otherwise be behind the retransmitted data. The sending PR-SCTP service can also consider many factors in determining which data to abandon retransmission of, not all of which could be translated to a per-packet priority: -- When the data must be received to be useful. The primary example of this is being streaming media delivery. -- What portion of a useful work unit the dropped data was. For example, it makes more sense to retransmit one packet that will complete 17 other packets that made it, rather than to retransmit a packet that was part of a message that had been totally lost. -- The importance of the data to the receiver. Many lossy encoding schemes can employ a pyramid encoding, where a few data chunks can give a crude picture, and later chunks refine the quality of the image. Obviously there would be little need to retransmit the refining chunks in preference to the base chunks. In all likelihood, PR-SCTP services will only support a comibniation of SCTP message integrity and a timed expiration. But the draft is quite explicit that the sending service is free to provide other value added services, and free to evolve them over time. So PR-SCTP can be implemented by any two peers, and the "drop selection" algorithm can be refined by the sending service at any time. A packet-priority scheme would sit around for a long time before network elements actually implemented it, and once implemented it would be frozen. So I would say that PR-SCTP is quite a bit friendlier to both the network and application than packet priority marking. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 25 16:03:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20697 for ; Fri, 25 Apr 2003 16:03:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PK6p423693 for tsvwg-archive@odin.ietf.org; Fri, 25 Apr 2003 16:06:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PK5S823613; Fri, 25 Apr 2003 16:05:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PK2l823494 for ; Fri, 25 Apr 2003 16:02:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20498 for ; Fri, 25 Apr 2003 15:59:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1999Nn-0003E6-00 for tsvwg@ietf.org; Fri, 25 Apr 2003 16:01:19 -0400 Received: from gw.openss7.com ([142.179.199.224] ident=[yRob8ah3rSnCDbVzjJ9dUVHM2k9LlLXa]) by ietf-mx with esmtp (Exim 4.12) id 1999Nm-0003E2-00 for tsvwg@ietf.org; Fri, 25 Apr 2003 16:01:18 -0400 Received: from ns.pigworks.openss7.net (IDENT:DBMVfbespbIgtdBFEdgPZwnf98HIljia@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h3PK1f907866; Fri, 25 Apr 2003 14:01:41 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h3PK1fg21084; Fri, 25 Apr 2003 14:01:41 -0600 Date: Fri, 25 Apr 2003 14:01:41 -0600 From: "Brian F. G. Bidulock" To: Caitlin Bestler Cc: Spencer Dawkins , TSV WG list Subject: Re: [Tsvwg] PR-SCTP Message-ID: <20030425140141.A20509@openss7.org> Reply-To: bidulock@openss7.org References: <20030423155914.41814.qmail@web10901.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from cait@asomi.com on Fri, Apr 25, 2003 at 11:15:54AM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id h3PK1f907866 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3PK2l823496 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Caitlin, On Fri, 25 Apr 2003, Caitlin Bestler wrote: > On 4/23/03, Spencer Dawkins wrote: > > >If an application gives clues to transport that something > >isn't as interesting as something else, how is this > >different from per-packet priority marking? > > Actually PR-SCTP is very different from per-packet priority > marking in several important ways: > > -- Per-packet priority marking could be used by network > elements to drop packets themselves. PR-SCTP only > drops packets in the sending service, and only drops > retransmissions. Correct me if I'm wrong, but is not a PR-SCTP implementation also allowed drop packets that have exipired before they are transmitted for the first time (i.e due to congestion)? --brian > > -- Because drops are done by the sending service, the > set of packets dropped can be done in a service sensitive > fashion and based upon dynamic information not available > at the time the packet was originally sent. > > While at first glance it might seem preferable to allow the > network elements forced to drop packets in the face of > congenstion to be given hints on which packets to drop. > But to be effective, such hints would have to be available > on *most* of the packets going through the element. > > PR-SCTP is effective in optimizing an applications response > to network congestion, no matter how many or how few other > competing users are employing the same or similiar > algorithms. Keep in mind that the purpose of dropping > a packet for retransmission will typically be to avoid > holding up more critical data that would otherwise be > behind the retransmitted data. > > The sending PR-SCTP service can also consider many factors > in determining which data to abandon retransmission of, not > all of which could be translated to a per-packet priority: > > -- When the data must be received to be useful. The primary > example of this is being streaming media delivery. > > -- What portion of a useful work unit the dropped data was. > For example, it makes more sense to retransmit one packet > that will complete 17 other packets that made it, rather > than to retransmit a packet that was part of a message > that had been totally lost. > > -- The importance of the data to the receiver. Many lossy > encoding schemes can employ a pyramid encoding, where > a few data chunks can give a crude picture, and later > chunks refine the quality of the image. Obviously > there would be little need to retransmit the refining > chunks in preference to the base chunks. > > In all likelihood, PR-SCTP services will only support a > comibniation of SCTP message integrity and a timed > expiration. But the draft is quite explicit that the sending > service is free to provide other value added services, and > free to evolve them over time. > > So PR-SCTP can be implemented by any two peers, and the > "drop selection" algorithm can be refined by the sending > service at any time. > > A packet-priority scheme would sit around for a long time > before network elements actually implemented it, and once > implemented it would be frozen. > > So I would say that PR-SCTP is quite a bit friendlier to > both the network and application than packet priority > marking. > > > > > Caitlin Bestler > http://asomi.com/CaitlinBestler/ > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 25 16:14:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21057 for ; Fri, 25 Apr 2003 16:14:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PKHH424945 for tsvwg-archive@odin.ietf.org; Fri, 25 Apr 2003 16:17:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKG8824916; Fri, 25 Apr 2003 16:16:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKFJ824879 for ; Fri, 25 Apr 2003 16:15:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20982 for ; Fri, 25 Apr 2003 16:11:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1999Zv-0003IO-00 for tsvwg@ietf.org; Fri, 25 Apr 2003 16:13:51 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 1999Zu-0003IE-00 for tsvwg@ietf.org; Fri, 25 Apr 2003 16:13:50 -0400 Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id DE1CD244DC8; Fri, 25 Apr 2003 16:14:05 -0400 (EDT) Date: Fri, 25 Apr 2003 15:16:37 -0500 From: Caitlin Bestler Subject: Re: [Tsvwg] PR-SCTP To: bidulock@openss7.org, TSV WG list X-Priority: 3 In-Reply-To: <20030425140141.A20509@openss7.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 4/25/03, Brian F. G. Bidulock wrote: >Correct me if I'm wrong, but is not a PR-SCTP >implementation also allowed drop packets that have >exipired before they are transmitted for the first time >(i.e due to congestion)? It's after a TSN has been assigned. So it would depend on when the implementation assigned TSNs. But you are correct that theoretically a service *could* assign a TSN and then drop it before sending it even once. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 25 16:20:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21241 for ; Fri, 25 Apr 2003 16:20:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PKNeA25247 for tsvwg-archive@odin.ietf.org; Fri, 25 Apr 2003 16:23:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKMS825183; Fri, 25 Apr 2003 16:22:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKKp825092 for ; Fri, 25 Apr 2003 16:20:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21126 for ; Fri, 25 Apr 2003 16:17:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1999fH-0003Jv-00 for tsvwg@ietf.org; Fri, 25 Apr 2003 16:19:23 -0400 Received: from web10901.mail.yahoo.com ([216.136.131.37]) by ietf-mx with smtp (Exim 4.12) id 1999fG-0003Jn-00 for tsvwg@ietf.org; Fri, 25 Apr 2003 16:19:22 -0400 Message-ID: <20030425201951.78542.qmail@web10901.mail.yahoo.com> Received: from [12.237.229.250] by web10901.mail.yahoo.com via HTTP; Fri, 25 Apr 2003 13:19:51 PDT Date: Fri, 25 Apr 2003 13:19:51 -0700 (PDT) From: Spencer Dawkins Subject: Re: [Tsvwg] PR-SCTP To: TSV WG list In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Dear Caitlin, I think I knew most of this, but it's a REALLY good summary! Thanks for the clear explanation. Spencer --- Caitlin Bestler wrote: > On 4/23/03, Spencer Dawkins wrote: > > >If an application gives clues to transport that something > >isn't as interesting as something else, how is this > >different from per-packet priority marking? > > Actually PR-SCTP is very different from per-packet priority > marking in several important ways: > > -- Per-packet priority marking could be used by network > elements to drop packets themselves. PR-SCTP only > drops packets in the sending service, and only drops > retransmissions. > > -- Because drops are done by the sending service, the > set of packets dropped can be done in a service sensitive > fashion and based upon dynamic information not available > at the time the packet was originally sent. > > While at first glance it might seem preferable to allow the > network elements forced to drop packets in the face of > congenstion to be given hints on which packets to drop. > But to be effective, such hints would have to be available > on *most* of the packets going through the element. > > PR-SCTP is effective in optimizing an applications response > to network congestion, no matter how many or how few other > competing users are employing the same or similiar > algorithms. Keep in mind that the purpose of dropping > a packet for retransmission will typically be to avoid > holding up more critical data that would otherwise be > behind the retransmitted data. > > The sending PR-SCTP service can also consider many factors > in determining which data to abandon retransmission of, not > all of which could be translated to a per-packet priority: > > -- When the data must be received to be useful. The primary > example of this is being streaming media delivery. > > -- What portion of a useful work unit the dropped data was. > For example, it makes more sense to retransmit one packet > that will complete 17 other packets that made it, rather > than to retransmit a packet that was part of a message > that had been totally lost. > > -- The importance of the data to the receiver. Many lossy > encoding schemes can employ a pyramid encoding, where > a few data chunks can give a crude picture, and later > chunks refine the quality of the image. Obviously > there would be little need to retransmit the refining > chunks in preference to the base chunks. > > In all likelihood, PR-SCTP services will only support a > comibniation of SCTP message integrity and a timed > expiration. But the draft is quite explicit that the sending > service is free to provide other value added services, and > free to evolve them over time. > > So PR-SCTP can be implemented by any two peers, and the > "drop selection" algorithm can be refined by the sending > service at any time. > > A packet-priority scheme would sit around for a long time > before network elements actually implemented it, and once > implemented it would be frozen. > > So I would say that PR-SCTP is quite a bit friendlier to > both the network and application than packet priority > marking. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Apr 25 16:21:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21287 for ; Fri, 25 Apr 2003 16:21:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PKOKM25289 for tsvwg-archive@odin.ietf.org; Fri, 25 Apr 2003 16:24:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKN3825226; Fri, 25 Apr 2003 16:23:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKL9825113 for ; Fri, 25 Apr 2003 16:21:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21143 for ; Fri, 25 Apr 2003 16:17:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1999fY-0003KK-00 for tsvwg@ietf.org; Fri, 25 Apr 2003 16:19:41 -0400 Received: from gw.openss7.com ([142.179.199.224] ident=[tskhzHGnat5Y7++8eDUfIoJUtN/1Gat9]) by ietf-mx with esmtp (Exim 4.12) id 1999fY-0003KH-00 for tsvwg@ietf.org; Fri, 25 Apr 2003 16:19:40 -0400 Received: from ns.pigworks.openss7.net (IDENT:Jzujiqpqznqyi5PvO2Zebpj9Ols5MoEu@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h3PKK9908093; Fri, 25 Apr 2003 14:20:09 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h3PKK9q21368; Fri, 25 Apr 2003 14:20:09 -0600 Date: Fri, 25 Apr 2003 14:20:09 -0600 From: "Brian F. G. Bidulock" To: Caitlin Bestler Cc: TSV WG list Subject: Re: [Tsvwg] PR-SCTP Message-ID: <20030425142009.B20509@openss7.org> Reply-To: bidulock@openss7.org References: <20030425140141.A20509@openss7.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from cait@asomi.com on Fri, Apr 25, 2003 at 03:16:37PM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id h3PKK9908093 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3PKL9825114 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Caitlin, Section 4.1 of draft-stewart-tsvwg-prsctp-03.txt says: TR3) Before assigning a TSN to any message, the SCTP send MUST evaluate the lifetime of that message. If it is expired, the SCTP sender MUST NOT assign a TSN to that message, but instead SHOULD issue a notification to the upper layer and drop the mssage. So, I suppose it is wrong to say that only retransmissions are dropped. Even transmissions will be dropped *before* assigning a TSN. --brian On Fri, 25 Apr 2003, Caitlin Bestler wrote: > On 4/25/03, Brian F. G. Bidulock wrote: > > >Correct me if I'm wrong, but is not a PR-SCTP > >implementation also allowed drop packets that have > >exipired before they are transmitted for the first time > >(i.e due to congestion)? > > It's after a TSN has been assigned. So it would depend on > when the implementation assigned TSNs. But you are correct > that theoretically a service *could* assign a TSN and then > drop it before sending it even once. > > Caitlin Bestler > http://asomi.com/CaitlinBestler/ -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Apr 28 08:18:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28268 for ; Mon, 28 Apr 2003 08:18:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3SCNFX04680 for tsvwg-archive@odin.ietf.org; Mon, 28 Apr 2003 08:23:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SCLH804625; Mon, 28 Apr 2003 08:21:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SCJL804529 for ; Mon, 28 Apr 2003 08:19:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28220 for ; Mon, 28 Apr 2003 08:14:17 -0400 (EDT) From: Ivan.Arias-Rodriguez@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19A7Yd-0002Uz-00 for tsvwg@ietf.org; Mon, 28 Apr 2003 08:16:32 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19A7Yd-0002Uw-00 for tsvwg@ietf.org; Mon, 28 Apr 2003 08:16:31 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h3SCH5723337 for ; Mon, 28 Apr 2003 15:17:05 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 28 Apr 2003 15:17:04 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 28 Apr 2003 15:17:03 +0300 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 28 Apr 2003 15:17:03 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Tsvwg] PR-SCTP Date: Mon, 28 Apr 2003 15:17:02 +0300 Message-ID: Thread-Topic: [Tsvwg] PR-SCTP Thread-Index: AcMLaF3hu7ZbMpW9STOYfc0nZ2j6YwCFfumQ To: , Cc: X-OriginalArrivalTime: 28 Apr 2003 12:17:03.0626 (UTC) FILETIME=[13D5CEA0:01C30D80] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3SCJL804530 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all! > Caitlin, > > Section 4.1 of draft-stewart-tsvwg-prsctp-03.txt says: > > TR3) Before assigning a TSN to any message, the SCTP send MUST > evaluate the lifetime of that message. If it is > expired, the SCTP > sender MUST NOT assign a TSN to that message, but > instead SHOULD > issue a notification to the upper layer and drop the mssage. > > So, I suppose it is wrong to say that only retransmissions are > dropped. Even transmissions will be dropped *before* assigning a TSN. > > --brian Well, in fact this is something that the "plain" SCTP implementation might do as well... At least this has been always been my understanding about the use of the "life time" parameter in the SEND primitive in RFC 2960 10.1 E), and the "sinfo_timetolive" field of struct sctp_sndrcvinfo in section 5.2.2 of the SCTP sockets draft... So I guess that it is wrong to say that only retransmissions can be dropped, but in fact, the new thing that PR-SCTP adds is dropping retransmissions (a "plain" SCTP peer will never realize you are dropping unsent data). BR Iván Arias Rodríguez > On Fri, 25 Apr 2003, Caitlin Bestler wrote: > > > On 4/25/03, Brian F. G. Bidulock wrote: > > > > >Correct me if I'm wrong, but is not a PR-SCTP > > >implementation also allowed drop packets that have > > >exipired before they are transmitted for the first time > > >(i.e due to congestion)? > > > > It's after a TSN has been assigned. So it would depend on > > when the implementation assigned TSNs. But you are correct > > that theoretically a service *could* assign a TSN and then > > drop it before sending it even once. > > > > Caitlin Bestler > > http://asomi.com/CaitlinBestler/ > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Apr 28 09:17:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29902 for ; Mon, 28 Apr 2003 09:17:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3SDLnb09175 for tsvwg-archive@odin.ietf.org; Mon, 28 Apr 2003 09:21:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SDKC809143; Mon, 28 Apr 2003 09:20:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SDJZ809092 for ; Mon, 28 Apr 2003 09:19:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29841 for ; Mon, 28 Apr 2003 09:14:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19A8Uu-0002s4-00 for tsvwg@ietf.org; Mon, 28 Apr 2003 09:16:44 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19A8Ut-0002s1-00 for tsvwg@ietf.org; Mon, 28 Apr 2003 09:16:43 -0400 Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3SDHII3019951; Mon, 28 Apr 2003 15:17:18 +0200 (MEST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id JZ7575CN; Mon, 28 Apr 2003 15:17:18 +0200 Received: from res0010384da36.eed.ericsson.se (dhcp5-109 [164.48.135.109]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id PAA09543; Mon, 28 Apr 2003 15:17:16 +0200 (MET DST) Message-Id: <5.2.0.9.0.20030428151415.025d2b28@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 28 Apr 2003 15:17:31 +0200 To: Phil Karn From: Reiner Ludwig Subject: Re: [Tsvwg] Re: Rethinking Karn's algorithm Cc: tsvwg@ietf.org In-Reply-To: <3E94C9EC.2060605@qualcomm.com> References: <5.1.0.14.0.20030325221003.00aa6300@mailhost.eed.ericsson.se> <5.1.0.14.0.20030325221003.00aa6300@mailhost.eed.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At 03:33 10.04.2003, Phil Karn wrote: >TCP header timestamps have made my algorithm essentially obsolete, [...] > >Header overhead is a non-issue here, IHMO. The savings in unnecessary >retransmits more than pays back the investment in a larger TCP header. catching up ... I pretty much agree since that is also what we have seen in our investigations. A different question that was discussed before on the list is the exponential backoff; up to ~60 seconds. Don't you think that that is a bit too conservative? ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Apr 28 11:06:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03894 for ; Mon, 28 Apr 2003 11:06:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3SFArT17834 for tsvwg-archive@odin.ietf.org; Mon, 28 Apr 2003 11:10:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SF9U817790; Mon, 28 Apr 2003 11:09:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SF8C817737 for ; Mon, 28 Apr 2003 11:08:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03834 for ; Mon, 28 Apr 2003 11:03:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AABz-0003O5-00 for tsvwg@ietf.org; Mon, 28 Apr 2003 11:05:19 -0400 Received: from web10901.mail.yahoo.com ([216.136.131.37]) by ietf-mx with smtp (Exim 4.12) id 19AABz-0003O2-00 for tsvwg@ietf.org; Mon, 28 Apr 2003 11:05:19 -0400 Message-ID: <20030428150553.51029.qmail@web10901.mail.yahoo.com> Received: from [12.237.229.250] by web10901.mail.yahoo.com via HTTP; Mon, 28 Apr 2003 08:05:53 PDT Date: Mon, 28 Apr 2003 08:05:53 -0700 (PDT) From: Spencer Dawkins Subject: Re: [Tsvwg] Re: Rethinking Karn's algorithm To: tsvwg@ietf.org In-Reply-To: <5.2.0.9.0.20030428151415.025d2b28@mailhost.eed.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , And, just so I'm not confused and confusing others... The one notification that we had room-consensus on at the San Francisco Trigtran BoF was "link up", which makes - less sense when you're talking about an RTO that's backed off to 2-3 seconds, and - more sense when you're talking about an RTO that's backed off to 60 seconds. What I think Reiner and I are both asking, on two different mailing lists under two different threads, is "how do we keep fully-backed-off TCPs from waiting for 30 seconds, on average, with a human in the loop and a working connection path, before the TCP figures out that the connection path is working?" So, if people think the Internet would melt down if the maximum RTO timer was reduced to 10 seconds, that's interesting; if people think the Internet would not melt down if it was reduced to 15 seconds, that's also interesting ... But I would also like to see other opinions expressed here (Reiner and I already talk, so ...). Spencer --- Reiner Ludwig wrote: > A different question that was discussed before on the list is > the > exponential backoff; up to ~60 seconds. Don't you think that > that is a bit > too conservative? _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Apr 28 11:45:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05155 for ; Mon, 28 Apr 2003 11:45:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3SFnwM20457 for tsvwg-archive@odin.ietf.org; Mon, 28 Apr 2003 11:49:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SFmL820413; Mon, 28 Apr 2003 11:48:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SFlo820391 for ; Mon, 28 Apr 2003 11:47:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05093 for ; Mon, 28 Apr 2003 11:42:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AAoK-0003a7-00 for tsvwg@ietf.org; Mon, 28 Apr 2003 11:44:56 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 19AAoK-0003Zt-00 for tsvwg@ietf.org; Mon, 28 Apr 2003 11:44:56 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 047A868957 for ; Mon, 28 Apr 2003 11:45:01 -0400 (EDT) Received: from guns.lerc.nasa.gov (guns.grc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3SFj0uW021384; Mon, 28 Apr 2003 11:45:00 -0400 (EDT) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id LAA86417; Mon, 28 Apr 2003 11:45:00 -0400 (EDT) Message-Id: <200304281545.LAA86417@guns.lerc.nasa.gov> To: Spencer Dawkins From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] Re: Rethinking Karn's algorithm In-Reply-To: <20030428150553.51029.qmail@web10901.mail.yahoo.com> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Dead Flowers Date: Mon, 28 Apr 2003 11:45:00 -0400 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Spencer- Nobody answers my questions, so I am using that spirit to not answer your's, but rather to turn it around on you... :) > So, if people think the Internet would melt down if the maximum > RTO timer was reduced to 10 seconds, that's interesting; if people > think the Internet would not melt down if it was reduced to 15 > seconds, that's also interesting ... What I am interested in knowing is where you think the line needs to be drawn to obviate the need for link-up. If an average wait of 30 seconds is too much what about 15 seconds? 10? 5? 2? Now I'll sort of answer your question... I believe that the max RTO should be "significant". It should not be 3 seconds. Should it be 60 seconds? Maybe not. Is it worth worrying about? Well, I think that depends on your answer to the above question. allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Apr 28 19:09:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18423 for ; Mon, 28 Apr 2003 19:09:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3SNEeu24238 for tsvwg-archive@odin.ietf.org; Mon, 28 Apr 2003 19:14:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SNDW824132; Mon, 28 Apr 2003 19:13:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SN4W822923 for ; Mon, 28 Apr 2003 19:04:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18196 for ; Mon, 28 Apr 2003 18:59:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AHcn-000627-00 for tsvwg@ietf.org; Mon, 28 Apr 2003 19:01:29 -0400 Received: from gw.openss7.com ([142.179.199.224] ident=[hquxVhdFIGRjQjUqCVNUIHSRqBqvUaUF]) by ietf-mx with esmtp (Exim 4.12) id 19AHcm-000624-00 for tsvwg@ietf.org; Mon, 28 Apr 2003 19:01:28 -0400 Received: from ns.pigworks.openss7.net (IDENT:NCe5aGKSAZYqmAm1pHEVAsaZWLzJ0Ukx@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h3SKN2908883; Mon, 28 Apr 2003 14:23:02 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h3SKM5W23073; Mon, 28 Apr 2003 14:22:05 -0600 Date: Mon, 28 Apr 2003 14:22:05 -0600 From: "Brian F. G. Bidulock" To: Ivan.Arias-Rodriguez@nokia.com Cc: cait@asomi.com, tsvwg@ietf.org Subject: Re: [Tsvwg] PR-SCTP Message-ID: <20030428142205.E22792@openss7.org> Reply-To: bidulock@openss7.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Ivan.Arias-Rodriguez@nokia.com on Mon, Apr 28, 2003 at 03:17:02PM +0300 Organization: http://www.openss7.org/ Dsn-Notification-To: X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id h3SKN2908883 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3SN4W822924 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Ivan.Arias-Rodriguez, On Mon, 28 Apr 2003, Ivan.Arias-Rodriguez@nokia.com wrote: > Hi all! > > > Caitlin, > > > > Section 4.1 of draft-stewart-tsvwg-prsctp-03.txt says: > > > > TR3) Before assigning a TSN to any message, the SCTP send MUST > > evaluate the lifetime of that message. If it is > > expired, the SCTP > > sender MUST NOT assign a TSN to that message, but > > instead SHOULD > > issue a notification to the upper layer and drop the mssage. > > > > So, I suppose it is wrong to say that only retransmissions are > > dropped. Even transmissions will be dropped *before* assigning a TSN. > > > > --brian > > Well, in fact this is something that the "plain" SCTP implementation > might do as well... At least this has been always been my > understanding about the use of the "life time" parameter in the SEND > primitive in RFC 2960 10.1 E), and the "sinfo_timetolive" field of > struct sctp_sndrcvinfo in section 5.2.2 of the SCTP sockets draft... > > So I guess that it is wrong to say that only retransmissions can be > dropped, but in fact, the new thing that PR-SCTP adds is dropping > retransmissions (a "plain" SCTP peer will never realize you are > dropping unsent data). > > BR Iván Arias Rodríguez But PR-SCTP "timed reliability" says MUST (RFC 2960 says that lifetimes are OPTIONAL). So making this behavior mandatory is another change of PR-SCTP. I think that it is important to note when speaking of junk data that, according to TR3 above, PR-SCTP can, under circumstances of congestion, discard messages *before* they are sent for the first time, resulting in even less traffic on the network than provided for by the congestion algorithm. That is, PR-SCTP will exhibit even *more* conservative congestion avoidance than regular SCTP using "timed-reliability" than would be exhibited otherwise. --brian > > > On Fri, 25 Apr 2003, Caitlin Bestler wrote: > > > > > On 4/25/03, Brian F. G. Bidulock wrote: > > > > > > >Correct me if I'm wrong, but is not a PR-SCTP > > > >implementation also allowed drop packets that have > > > >exipired before they are transmitted for the first time > > > >(i.e due to congestion)? > > > > > > It's after a TSN has been assigned. So it would depend on > > > when the implementation assigned TSNs. But you are correct > > > that theoretically a service *could* assign a TSN and then > > > drop it before sending it even once. > > > > > > Caitlin Bestler > > > http://asomi.com/CaitlinBestler/ > > > > -- > > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > > ¦ Therefore all progress depends on the ¦ > > ¦ unreasonable man. -- George Bernard Shaw ¦ > > _______________________________________________ > > tsvwg mailing list > > tsvwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 30 04:47:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25473 for ; Wed, 30 Apr 2003 04:47:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3U8rAD17767 for tsvwg-archive@odin.ietf.org; Wed, 30 Apr 2003 04:53:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U8pl817700; Wed, 30 Apr 2003 04:51:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U8mD817535 for ; Wed, 30 Apr 2003 04:48:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25418 for ; Wed, 30 Apr 2003 04:42:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AnCW-0005Bq-00 for tsvwg@ietf.org; Wed, 30 Apr 2003 04:44:28 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19AnCV-0005Bn-00 for tsvwg@ietf.org; Wed, 30 Apr 2003 04:44:27 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3U8j4Rs010393; Wed, 30 Apr 2003 10:45:04 +0200 (MEST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id J71Z51JW; Wed, 30 Apr 2003 10:45:03 +0200 Received: from res0010384da36.eed.ericsson.se (dhcp5-109 [164.48.135.109]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id KAA21046; Wed, 30 Apr 2003 10:45:03 +0200 (MET DST) Message-Id: <5.2.0.9.0.20030430100631.00ab8b78@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 30 Apr 2003 10:45:19 +0200 To: Phil Karn From: Reiner Ludwig Subject: Re: [Tsvwg] Re: Rethinking Karn's algorithm Cc: tsvwg@ietf.org In-Reply-To: <3EAD8B64.40308@qualcomm.com> References: <5.2.0.9.0.20030428151415.025d2b28@mailhost.eed.ericsson.se> <5.1.0.14.0.20030325221003.00aa6300@mailhost.eed.ericsson.se> <5.1.0.14.0.20030325221003.00aa6300@mailhost.eed.ericsson.se> <5.2.0.9.0.20030428151415.025d2b28@mailhost.eed.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At 22:13 28.04.2003, Phil Karn wrote: >Reiner Ludwig wrote: >>A different question that was discussed before on the list is the >>exponential backoff; up to ~60 seconds. Don't you think that that is a >>bit too conservative? > >Well, I have seen some router queues that get amazingly long... Are you saying that because we *might* have a *few* broken boxes in the Internet all TCPs must "suffer" and do exponential RTO backoff up to 60 seconds? I hate to say it, but with claims like yours I can probably kill any attempt to modify or add new features to an e2e protocol. To me this is only creating "worst-case paranoia", and that's not constructive! The discussions around packet reordering is going in a similar direction. Sure, there could be backbone routers connected by multiple links for redundancy, and the load balancing software might not care to keep packets of the same flow on the same link. And voila, we have huge reordering problems in the Internet; and for TCP. Now, we could have Best-Current-Practice RFCs that recommend routers: "don't queue more than 10 seconds worth of data", "don't throw packets of the same flow (or dest. IP addr.) onto different links", etc. in case they don't already do that, anyway (which I personally believe is mostly the case); then trust that this is the case in most places of the Internet, and design our e2e protocols towards that. Or, we continue to believe that the Internet is a *possibly* crazy black-box, and design our e2e protocols with maximum conservativeness. ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 30 19:01:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28895 for ; Wed, 30 Apr 2003 19:01:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3UN7Wl20252 for tsvwg-archive@odin.ietf.org; Wed, 30 Apr 2003 19:07:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UN6N819404; Wed, 30 Apr 2003 19:06:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UN57819376 for ; Wed, 30 Apr 2003 19:05:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28755; Wed, 30 Apr 2003 18:58:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B0ZS-0004MF-00; Wed, 30 Apr 2003 19:01:02 -0400 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 19B0ZN-0004MA-00; Wed, 30 Apr 2003 19:00:57 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h3UN1B005277; Wed, 30 Apr 2003 16:01:11 -0700 (PDT) Message-Id: <200304302301.h3UN1B005277@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, tsvwg@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 30 Apr 2003 16:01:11 -0700 Subject: [Tsvwg] RFC 3522 on The Eifel Detection Algorithm for TCP Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3522 Title: The Eifel Detection Algorithm for TCP Author(s): R. Ludwig, M. Meyer Status: Experimental Date: April 2003 Mailbox: Reiner.Ludwig@eed.ericsson.se, Michael.Meyer@eed.ericsson.se Pages: 14 Characters: 33729 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tsvwg-tcp-eifel-alg-07.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3522.txt The Eifel detection algorithm allows a TCP sender to detect a posteriori whether it has entered loss recovery unnecessarily. It requires that the TCP Timestamps option defined in RFC 1323 be enabled for a connection. The Eifel detection algorithm makes use of the fact that the TCP Timestamps option eliminates the retransmission ambiguity in TCP. Based on the timestamp of the first acceptable ACK that arrives during loss recovery, it decides whether loss recovery was entered unnecessarily. The Eifel detection algorithm provides a basis for future TCP enhancements. This includes response algorithms to back out of loss recovery by restoring a TCP sender's congestion control state. This document is a product of the Transport Area Working Group Working Group of the IETF. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030430155932.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3522 --OtherAccess Content-Type: Message/External-body; name="rfc3522.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030430155932.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 30 19:18:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29289 for ; Wed, 30 Apr 2003 19:18:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3UNOYr21042 for tsvwg-archive@odin.ietf.org; Wed, 30 Apr 2003 19:24:34 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UNN9821007; Wed, 30 Apr 2003 19:23:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UNMX820966 for ; Wed, 30 Apr 2003 19:22:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29247 for ; Wed, 30 Apr 2003 19:16:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B0q6-0004TH-00 for tsvwg@ietf.org; Wed, 30 Apr 2003 19:18:14 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 19B0q0-0004Si-00 for tsvwg@ietf.org; Wed, 30 Apr 2003 19:18:08 -0400 Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id A3AE224489D; Wed, 30 Apr 2003 19:18:07 -0400 (EDT) Date: Wed, 30 Apr 2003 18:20:29 -0500 From: Caitlin Bestler Subject: Re: [Tsvwg] Re: Rethinking Karn's algorithm To: Reiner Ludwig , tsvwg@ietf.org X-Priority: 3 In-Reply-To: <5.2.0.9.0.20030430100631.00ab8b78@mailhost.eed.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 4/30/03, Reiner Ludwig wrote: >At 22:13 28.04.2003, Phil Karn wrote: >>Reiner Ludwig wrote: >>>A different question that was discussed before on the >>>list is the exponential backoff; up to ~60 seconds. >>>Don't you think that that is a bit too conservative? >> >>Well, I have seen some router queues that get amazingly long... > >Are you saying that because we *might* have a *few* broken >boxes in the Internet all TCPs must "suffer" and do >exponential RTO backoff up to 60 seconds? > >I hate to say it, but with claims like yours I can >probably kill any attempt to modify or add new features to >an e2e protocol. To me this is only creating "worst-case >paranoia", and that's not constructive! > >The discussions around packet reordering is going in a >similar direction. Sure, there could be backbone routers >connected by multiple links for redundancy, and the load >balancing software might not care to keep packets of the >same flow on the same link. And voila, we have huge >reordering problems in the Internet; and for TCP. > >Now, we could have Best-Current-Practice RFCs that >recommend routers: "don't queue more than 10 seconds worth >of data", "don't throw packets of the same flow (or dest. >IP addr.) onto different links", etc. in case they don't >already do that, anyway (which I personally believe is >mostly the case); then trust that this is the case in most >places of the Internet, and design our e2e protocols >towards that. Or, we continue to believe that the Internet >is a *possibly* crazy black-box, and design our e2e >protocols with maximum conservativeness. > To agree with you even more strongly, consider that for many applications a human is part of the "backoff algorithm". In onther words, how long of a delay will be *tolerated* before the human consumer initiates corrective action, such as a new connection, on their own. Once predictable human responses are factored in, I doubt that a 60 second backoff will ever truly result in improved service. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 30 20:07:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00782 for ; Wed, 30 Apr 2003 20:07:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h410DO626441 for tsvwg-archive@odin.ietf.org; Wed, 30 Apr 2003 20:13:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h410CF826313; Wed, 30 Apr 2003 20:12:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4105E825252 for ; Wed, 30 Apr 2003 20:05:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00385 for ; Wed, 30 Apr 2003 19:58:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B1N3-0004hg-00 for tsvwg@ietf.org; Wed, 30 Apr 2003 19:52:17 -0400 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 19B1Mx-0004hM-00 for tsvwg@ietf.org; Wed, 30 Apr 2003 19:52:11 -0400 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h3UNqP1f000613 for ; Wed, 30 Apr 2003 16:52:25 -0700 (MST) Received: from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h3UNqNj0008628 for ; Wed, 30 Apr 2003 18:52:23 -0500 Received: from motorola.com (d50-39f8.cig.mot.com [160.47.57.248]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id J9S6SXYD; Wed, 30 Apr 2003 18:52:22 -0500 Message-ID: <3EB06204.FAB6DCAC@motorola.com> Date: Wed, 30 Apr 2003 18:53:40 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Caitlin Bestler CC: Reiner Ludwig , tsvwg@ietf.org Subject: Re: [Tsvwg] Re: Rethinking Karn's algorithm References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Caitlin Bestler wrote: ... > To agree with you even more strongly, consider that for > many applications a human is part of the "backoff > algorithm". > > In onther words, how long of a delay will be *tolerated* > before the human consumer initiates corrective action, > such as a new connection, on their own. > > Once predictable human responses are factored in, I doubt > that a 60 second backoff will ever truly result in improved > service. Aren't lining up and waiting to be served part of the fun of being human? :-) -Qiaobing _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 30 21:35:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02502 for ; Wed, 30 Apr 2003 21:35:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h411fPK31789 for tsvwg-archive@odin.ietf.org; Wed, 30 Apr 2003 21:41:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h411eI831774; Wed, 30 Apr 2003 21:40:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h411ds831725 for ; Wed, 30 Apr 2003 21:39:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02488 for ; Wed, 30 Apr 2003 21:33:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B2zD-0005Hm-00 for tsvwg@ietf.org; Wed, 30 Apr 2003 21:35:47 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19B2z3-0005Hj-00 for tsvwg@ietf.org; Wed, 30 Apr 2003 21:35:41 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h410md1G005313; Wed, 30 Apr 2003 19:48:40 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3EB06EE7.1040106@stewart.chicago.il.us> Date: Wed, 30 Apr 2003 19:48:39 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Qiaobing Xie CC: Caitlin Bestler , Reiner Ludwig , tsvwg@ietf.org Subject: Re: [Tsvwg] Re: Rethinking Karn's algorithm References: <3EB06204.FAB6DCAC@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Qiaobing Xie wrote: > Caitlin Bestler wrote: > ... > >>To agree with you even more strongly, consider that for >>many applications a human is part of the "backoff >>algorithm". >> >>In onther words, how long of a delay will be *tolerated* >>before the human consumer initiates corrective action, >>such as a new connection, on their own. >> >>Once predictable human responses are factored in, I doubt >>that a 60 second backoff will ever truly result in improved >>service. > > > Aren't lining up and waiting to be served part of the fun of being > human? :-) > > -Qiaobing Maybe.. But when you give the human another choice... (a different line to go into) they will run to it... screwing up everything as murphy puts it.. You can think of a different line as the little stop/reload button on your web browser... gets a new connection and in cases of congestion.. guess what.. it will speed things up at times... So unless we take the "get a new connection aka switch lines" buttons off of all applications I can't help but agree with Caitlin.. R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Apr 30 22:30:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03362 for ; Wed, 30 Apr 2003 22:30:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h412aXJ01710 for tsvwg-archive@odin.ietf.org; Wed, 30 Apr 2003 22:36:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h412ZD801680; Wed, 30 Apr 2003 22:35:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h412Ys801655 for ; Wed, 30 Apr 2003 22:34:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03342 for ; Wed, 30 Apr 2003 22:28:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B3qP-0005UP-00 for tsvwg@ietf.org; Wed, 30 Apr 2003 22:30:45 -0400 Received: from web10906.mail.yahoo.com ([216.136.131.42]) by ietf-mx with smtp (Exim 4.12) id 19B3qJ-0005UJ-00 for tsvwg@ietf.org; Wed, 30 Apr 2003 22:30:39 -0400 Message-ID: <20030501023044.89984.qmail@web10906.mail.yahoo.com> Received: from [12.237.229.250] by web10906.mail.yahoo.com via HTTP; Wed, 30 Apr 2003 19:30:44 PDT Date: Wed, 30 Apr 2003 19:30:44 -0700 (PDT) From: Spencer Dawkins Subject: Re: [Tsvwg] Re: Rethinking Karn's algorithm To: tsvwg@ietf.org In-Reply-To: <3EB06EE7.1040106@stewart.chicago.il.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , So I'm thinking that - the 60 second max RTO is to save the Internet from connections between computers that don't have humans in the loop, and - the stop/reload button is to save humans in the loop from the 60 second max RTO? :-} Spencer --- Randall Stewart wrote: > You can think of a different line as the little stop/reload > button > on your web browser... gets a new connection and in cases of > congestion.. guess what.. it will speed things up at times... > > So unless we take the "get a new connection aka switch lines" > buttons > off of all applications I can't help but agree with Caitlin.. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg