From mailnull@www1.ietf.org Wed Feb 5 06:59: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 GAA20308 for ; Wed, 5 Feb 2003 06:59:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15C57X18727 for rmt-archive@odin.ietf.org; Wed, 5 Feb 2003 07:05: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 h15C57J18724 for ; Wed, 5 Feb 2003 07:05:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20254 for ; Wed, 5 Feb 2003 06:58:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15C4QJ18637; Wed, 5 Feb 2003 07:04:26 -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 h15C2cJ18422 for ; Wed, 5 Feb 2003 07:02:38 -0500 Received: from cs.tut.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20070 for ; Wed, 5 Feb 2003 06:56:10 -0500 (EST) Received: from rampe (rampe.atm.tut.fi [130.230.52.68]) by cs.tut.fi (8.8.8/8.8.8) with SMTP id NAA20953 for ; Wed, 5 Feb 2003 13:59:48 +0200 (EET) From: "Rami Lehtonen" To: Date: Wed, 5 Feb 2003 14:00:06 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Rmt] ALC header modifications Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Multicast Transport List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, If you are planning to revise the ALC header format to make it possible to get rid off congestion control identification in some cases (make it optional), it could make sense to make the forward error correction optional as well (reliability could be handled by retransmissions, we might need the sequence number field). Those fields could be moved to header options to be specified with TLV encoding. So when you don't want to use those, you don't have to waste any bytes because of those fields. In addition you could specify a field in ALC header that can be used as a message type field when specifying an actual protocol based on ALC without having out-of-band information on different message meanings. Any comments, Rami Lehtonen >I think the plan is to move ALC from Experimental RFC status to >Proposed Standard RFC status aggressively, i.e., within the next couple >of months, so perhaps it would be best to make this change when it >moves to Proposed Standard (since it is essentially through the >Experimental RFC status stage). > >Mike Luby _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From mailnull@www1.ietf.org Wed Feb 5 12:23:35 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 MAA02563 for ; Wed, 5 Feb 2003 12:23:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15HTcN08485 for rmt-archive@odin.ietf.org; Wed, 5 Feb 2003 12:29: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 h15HTcJ08482 for ; Wed, 5 Feb 2003 12:29:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02539 for ; Wed, 5 Feb 2003 12:23:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15HSVJ08298; Wed, 5 Feb 2003 12:28:31 -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 h15HNpJ08114 for ; Wed, 5 Feb 2003 12:23:51 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02337 for ; Wed, 5 Feb 2003 12:17:17 -0500 (EST) Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h15HKNSQ003128; Wed, 5 Feb 2003 09:20:23 -0800 (PST) Received: (from lorenzo@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA24541; Wed, 5 Feb 2003 09:20:22 -0800 (PST) Date: Wed, 5 Feb 2003 09:20:22 -0800 From: Lorenzo Vicisano To: Rami Lehtonen Cc: rmt@ietf.org Subject: Re: [Rmt] ALC header modifications Message-ID: <20030205092022.M27760@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Multicast Transport List-Post: List-Help: List-Subscribe: , Hi Rami, As Mike mentioned this is not the right time to revise any of the RMT RFCs, unless we discover some major flaw. said that, these are my comments: > If you are planning to revise the ALC header format to make it possible > to get rid off congestion control identification in some cases (make it this is only possible if ALC is used in confined environments, not internet-wide. Specifying for this kind of enveronment is not IETF's main concern and anyone is free to change the specs to his/her needs, if these are not going to be used internet-wide. said that, we could discuss adding some kind of statement to the spec. > optional), it could make sense to make the forward error correction > optional as well (reliability could be handled by retransmissions, we > might need the sequence number field). Those fields could be moved to ALC is not a general-pourpose reliable multicast protocol. Retransmissions are against the ALC design principle. Please use another protocol (e.g. NORM) if you want retransmission. > header options to be specified with TLV encoding. So when you don't want > to use those, you don't have to waste any bytes because of those fields. > > In addition you could specify a field in ALC header that can be used as > a message type field when specifying an actual protocol based on ALC > without having out-of-band information on different message meanings. not sure I understand this. thanks, Lorenzo > > Any comments, > > Rami Lehtonen > > >I think the plan is to move ALC from Experimental RFC status to > >Proposed Standard RFC status aggressively, i.e., within the next couple > > >of months, so perhaps it would be best to make this change when it > >moves to Proposed Standard (since it is essentially through the > >Experimental RFC status stage). > > > >Mike Luby > _______________________________________________ > Rmt mailing list > Rmt@ietf.org > https://www1.ietf.org/mailman/listinfo/rmt _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From mailnull@www1.ietf.org Thu Feb 6 00:22: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 AAA23303 for ; Thu, 6 Feb 2003 00:22:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h165Shi22961 for rmt-archive@odin.ietf.org; Thu, 6 Feb 2003 00:28:43 -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 h165Shp22958 for ; Thu, 6 Feb 2003 00:28:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23290 for ; Thu, 6 Feb 2003 00:21:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h165Rep22907; Thu, 6 Feb 2003 00:27: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 h165P8p22860 for ; Thu, 6 Feb 2003 00:25:08 -0500 Received: from mx.webfountain.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23227 for ; Thu, 6 Feb 2003 00:18:19 -0500 (EST) Received: (qmail 28999 invoked from network); 6 Feb 2003 05:21:57 -0000 Received: from mail.intranet (10.1.1.37) by mx.webfountain.com with SMTP; 6 Feb 2003 05:21:57 -0000 Received: by mail.intranet (8.12.1/8.12.1/Debian -5) with SMTP id h165V2Fd023600; Wed, 5 Feb 2003 21:31:02 -0800 From: "Michael Luby" To: "Lorenzo Vicisano" , "Rami Lehtonen" Cc: Subject: RE: [Rmt] ALC header modifications Date: Wed, 5 Feb 2003 21:21:44 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <20030205092022.M27760@cisco.com> Content-Transfer-Encoding: 7bit Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Multicast Transport List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Comments interspersed below. > -----Original Message----- > From: rmt-admin@ietf.org [mailto:rmt-admin@ietf.org]On Behalf Of Lorenzo > Vicisano > Sent: Wednesday, February 05, 2003 9:20 AM > To: Rami Lehtonen > Cc: rmt@ietf.org > Subject: Re: [Rmt] ALC header modifications > > > Hi Rami, > > As Mike mentioned this is not the right time to revise any > of the RMT RFCs, unless we discover some major flaw. > > said that, these are my comments: > > > If you are planning to revise the ALC header format to make it possible > > to get rid off congestion control identification in some cases (make it > > this is only possible if ALC is used in confined environments, not > internet-wide. Specifying for this kind of enveronment is not IETF's > main concern and anyone is free to change the specs to his/her needs, > if these are not going to be used internet-wide. said that, we could > discuss adding some kind of statement to the spec. This is something that several people have asked about, are concerned about, would like to happen, and there is even some proposed language that we can add/change the text to when the time comes. I'd rather wait till we are ready to move this from Experimental to Proposed Standard for this though. I suggest we discuss that at the upcoming IETF meeting just to make sure that there is consensus on this issue. I know a lot of applications/companies where ALC could be used without congestion control in a controlled environment or where flow/congestion control is provided by other means, and I would like to encourage the use of ALC in those environments by making the standard cover those cases (with the proper language) but clearly if it is being deployed broadly across the open Internet then flow/congestion control is a must. > > > optional), it could make sense to make the forward error correction > > optional as well (reliability could be handled by retransmissions, we > > might need the sequence number field). Those fields could be moved to > > ALC is not a general-pourpose reliable multicast protocol. > Retransmissions are against the ALC design principle. Please > use another protocol (e.g. NORM) if you want retransmission. I concur with Lorenzo's comment on this. > > > header options to be specified with TLV encoding. So when you don't want > > to use those, you don't have to waste any bytes because of those fields. > > > > In addition you could specify a field in ALC header that can be used as > > a message type field when specifying an actual protocol based on ALC > > without having out-of-band information on different message meanings. > > not sure I understand this. My feeling is that this is getting too general and outside the scope of what ALC is intended for, but honestly it is not explained well enough to evaluate. > > thanks, > Lorenzo > > > > Any comments, > > > > Rami Lehtonen > > > > >I think the plan is to move ALC from Experimental RFC status to > > >Proposed Standard RFC status aggressively, i.e., within the next couple > > > > >of months, so perhaps it would be best to make this change when it > > >moves to Proposed Standard (since it is essentially through the > > >Experimental RFC status stage). > > > > > >Mike Luby > > _______________________________________________ > > Rmt mailing list > > Rmt@ietf.org > > https://www1.ietf.org/mailman/listinfo/rmt > _______________________________________________ > Rmt mailing list > Rmt@ietf.org > https://www1.ietf.org/mailman/listinfo/rmt > _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From mailnull@www1.ietf.org Thu Feb 6 01:48: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 BAA25487 for ; Thu, 6 Feb 2003 01:48:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h166sOi27400 for rmt-archive@odin.ietf.org; Thu, 6 Feb 2003 01:54: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 h166sOp27397 for ; Thu, 6 Feb 2003 01:54:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25450 for ; Thu, 6 Feb 2003 01:47:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h166rZp27354; Thu, 6 Feb 2003 01:53:35 -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 h166qbp27331 for ; Thu, 6 Feb 2003 01:52:37 -0500 Received: from cs.tut.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25410 for ; Thu, 6 Feb 2003 01:45:46 -0500 (EST) Received: from rampe (rampe.atm.tut.fi [130.230.52.68]) by cs.tut.fi (8.8.8/8.8.8) with SMTP id IAA02195; Thu, 6 Feb 2003 08:49:15 +0200 (EET) From: "Rami Lehtonen" To: "Michael Luby" , "Lorenzo Vicisano" Cc: Subject: RE: [Rmt] ALC header modifications Date: Thu, 6 Feb 2003 08:49:41 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Multicast Transport List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > optional), it could make sense to make the forward error correction > > > optional as well (reliability could be handled by retransmissions, we > > > might need the sequence number field). Those fields could be moved to > > > > ALC is not a general-pourpose reliable multicast protocol. > > Retransmissions are against the ALC design principle. Please > > use another protocol (e.g. NORM) if you want retransmission. > > I concur with Lorenzo's comment on this. Even if the ALC is designed to work without retransmissions, one could send packets without FEC continuously on one ALC channel (carousel) or use several ALC channels. To allow this the use of FEC could be optional even though the implentation must support it. > > > In addition you could specify a field in ALC header that can > be used as > > > a message type field when specifying an actual protocol based on ALC > > > without having out-of-band information on different message meanings. > > > > not sure I understand this. > > My feeling is that this is getting too general and outside the > scope of what > ALC is intended for, but honestly it is not explained well enough to > evaluate. The idea was that protocol could include a message type field to be used e.g. by applications relying on ALC for multicast session information transfer. Like SAP contains a message type specifying whether it contains an announcement or deletion of a session. But maybe I have assumed ALC as too general multicast object transfer protocol with its varying header field sizes. - Rami _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From mailnull@www1.ietf.org Thu Feb 6 18:42: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 SAA09051 for ; Thu, 6 Feb 2003 18:42:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16NnHk08926 for rmt-archive@odin.ietf.org; Thu, 6 Feb 2003 18:49: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 h16NnHp08923 for ; Thu, 6 Feb 2003 18:49:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09039 for ; Thu, 6 Feb 2003 18:42:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16NlWp08795; Thu, 6 Feb 2003 18:47: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 h16NhPp08629 for ; Thu, 6 Feb 2003 18:43:25 -0500 Received: from mx.webfountain.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08868 for ; Thu, 6 Feb 2003 18:36:13 -0500 (EST) Received: (qmail 3475 invoked from network); 6 Feb 2003 23:39:51 -0000 Received: from mail.intranet (10.1.1.37) by mx.webfountain.com with SMTP; 6 Feb 2003 23:39:51 -0000 Received: by mail.intranet (8.12.1/8.12.1/Debian -5) with SMTP id h16NmwFd026598; Thu, 6 Feb 2003 15:48:58 -0800 From: "Michael Luby" To: "Rami Lehtonen" Cc: "Lorenzo Vicisano" , Subject: RE: [Rmt] ALC header modifications Date: Thu, 6 Feb 2003 15:41:59 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Multicast Transport List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Rami, More comments interspersed below. Regards, Mike > -----Original Message----- > From: Rami Lehtonen [mailto:rampe@cs.tut.fi] > Sent: Wednesday, February 05, 2003 10:50 PM > To: Michael Luby; Lorenzo Vicisano > Cc: rmt@ietf.org > Subject: RE: [Rmt] ALC header modifications > > > > > > optional), it could make sense to make the forward error correction > > > > optional as well (reliability could be handled by > retransmissions, we > > > > might need the sequence number field). Those fields could > be moved to > > > > > > ALC is not a general-pourpose reliable multicast protocol. > > > Retransmissions are against the ALC design principle. Please > > > use another protocol (e.g. NORM) if you want retransmission. > > > > I concur with Lorenzo's comment on this. > > Even if the ALC is designed to work without retransmissions, one > could send > packets without FEC continuously on one ALC channel (carousel) or use > several ALC channels. To allow this the use of FEC could be optional even > though the implentation must support it. Lorenzo and I are going to be submitting a supplement to the FEC BB today that introduces two new FEC Encoding IDs, one Fully-Specified and one Under-Specified. The Fully-Specified FEC Encoding ID uses no FEC encoding (the original data is partitioned into "encoding symbols" and each packet contains one of these encoding symbols, and the recommended sending approach is carousel. This will allow a standard and easy FEC Encoding ID to implement, and I think it answers your request (others as well have asked for a "no-coding" FEC scheme). In terms of specifying feedback from receivers to the sender, I would not put this into ALC because ALC does not include anything that limits scalability and this would. It might be a good idea to consider putting something like this in a separate draft that could be used in conjunction with ALC. I would have to think about it more though before being convinced. > > > > > In addition you could specify a field in ALC header that can > > be used as > > > > a message type field when specifying an actual protocol based on ALC > > > > without having out-of-band information on different message > meanings. > > > > > > not sure I understand this. > > > > My feeling is that this is getting too general and outside the > > scope of what > > ALC is intended for, but honestly it is not explained well enough to > > evaluate. > > The idea was that protocol could include a message type field to be used > e.g. by applications relying on ALC for multicast session information > transfer. Like SAP contains a message type specifying whether it > contains an > announcement or deletion of a session. But maybe I have assumed ALC as too > general multicast object transfer protocol with its varying header field > sizes. I believe there will be a new draft that does something like this coming soon that uses a different mechanism than what you suggest that I think is a pretty good idea. If and when it is submitted maybe it is good to look to this as a starting place to see if achieves what you were hoping to achieve. > > - Rami > > _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From mailnull@www1.ietf.org Mon Feb 10 06:48: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 GAA05224 for ; Mon, 10 Feb 2003 06:48:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1ABulO09825 for rmt-archive@odin.ietf.org; Mon, 10 Feb 2003 06:56:47 -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 h1ABulp09822 for ; Mon, 10 Feb 2003 06:56:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05204 for ; Mon, 10 Feb 2003 06:47:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ABtvp09754; Mon, 10 Feb 2003 06:55: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 h1ABsDp09701 for ; Mon, 10 Feb 2003 06:54:13 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05061; Mon, 10 Feb 2003 06:45:19 -0500 (EST) Message-Id: <200302101145.GAA05061@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rmt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 10 Feb 2003 06:45:18 -0500 Subject: [Rmt] I-D ACTION:draft-ietf-rmt-bb-fec-supp-inband-00.txt Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Multicast Transport List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Reliable Multicast Transport Working Group of the IETF. Title : Compact Forward Error Correction (FEC) Schemes Author(s) : M. Luby, L. Vicisano Filename : draft-ietf-rmt-bb-fec-supp-inband-00.txt Pages : 17 Date : 2003-2-7 This document introduces some Forward Error Correction (FEC) schemes which supplement the FEC schemes described in the FEC Building Block. The primary benefits of these additional FEC schemes is that they are designed for reliable bulk delivery of large objects using a more compact FEC Payload ID, and they can be used to sequentially deliver blocks of an object of indeterminate length. Thus, they more flexibly support different delivery models with less packet header overhead. This document describes the Fully-Specified FEC scheme corresponding to FEC Encoding ID 0. This Fully-Specified FEC scheme requires no FEC coding and is introduced primarily to allow simple interoperability testing between different implementations of protocol instantiations that use the FEC building block. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-fec-supp-inband-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rmt-bb-fec-supp-inband-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rmt-bb-fec-supp-inband-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-7094513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-bb-fec-supp-inband-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-bb-fec-supp-inband-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-7094513.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From mailnull@www1.ietf.org Wed Feb 12 11:38: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 LAA08074 for ; Wed, 12 Feb 2003 11:38:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CGlan04124 for rmt-archive@odin.ietf.org; Wed, 12 Feb 2003 11:47: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 h1CGlap04121 for ; Wed, 12 Feb 2003 11:47:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08065 for ; Wed, 12 Feb 2003 11:37:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CGkYp04069; Wed, 12 Feb 2003 11:46:34 -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 h1CGhcp03958 for ; Wed, 12 Feb 2003 11:43:38 -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 LAA08010 for ; Wed, 12 Feb 2003 11:33:40 -0500 (EST) From: toni.paila@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1CGeCm11683 for ; Wed, 12 Feb 2003 18:40:12 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 12 Feb 2003 18:37:23 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Feb 2003 18:37:23 +0200 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Feb 2003 18:37:23 +0200 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" Date: Wed, 12 Feb 2003 18:37:22 +0200 Message-ID: <26574F0076BFF449ADAE582D9E67780C017541AF@esebe006.ntc.nokia.com> Thread-Topic: File delivery for ALC -- draft-paila-rmt-fdalc-00.txt Thread-Index: AcLStQNdzp0OfTzMS221Kmn9zk3Dmw== To: X-OriginalArrivalTime: 12 Feb 2003 16:37:23.0246 (UTC) FILETIME=[04DF6CE0:01C2D2B5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1CGhdp03959 Subject: [Rmt] File delivery for ALC -- draft-paila-rmt-fdalc-00.txt Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Multicast Transport List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi all, I have submitted an Internet-Draft that specifies a way to use ALC for file delivery. In the RMT WG session of IETF-56 we will discuss the document. Regards, Toni > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : FDALC - File Delivery for ALC > Author(s) : T. Paila > Filename : draft-paila-rmt-fdalc-00.txt > Pages : 21 > Date : 2003-2-10 > > This document defines unidirectional delivery of files. The > specification builds on Asynchronous Layered Coding, the base > protocol designed for massively scalable multicast distribution. > Thus, this document specifies a technique called FDALC - a mechanism > for signalling and mapping the properties of files to concepts of ALC > in a way that allows receivers to assign those parameters for > received objects. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-paila-rmt-fdalc-00.txt _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From mailnull@www1.ietf.org Thu Feb 13 04: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 EAA07939 for ; Thu, 13 Feb 2003 04:29:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1D9dNA06989 for rmt-archive@odin.ietf.org; Thu, 13 Feb 2003 04:39:23 -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 h1D9dNp06986 for ; Thu, 13 Feb 2003 04:39:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07896 for ; Thu, 13 Feb 2003 04:29:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D9cYp06940; Thu, 13 Feb 2003 04:38:34 -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 h1D9bUp06824 for ; Thu, 13 Feb 2003 04:37:30 -0500 Received: from ebene.inrialpes.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07884 for ; Thu, 13 Feb 2003 04:27:10 -0500 (EST) Received: from imap-serv.inrialpes.fr (imap-serv.inrialpes.fr [194.199.18.72]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id h1D9UsZ04030; Thu, 13 Feb 2003 10:30:54 +0100 (MET) Received: from inrialpes.fr (iseran.inrialpes.fr [194.199.24.100]) by imap-serv.inrialpes.fr (8.11.6/8.11.3/ImagV2) with ESMTP id h1D9UrS22241; Thu, 13 Feb 2003 10:30:54 +0100 (MET) Message-ID: <3E4B65CF.B129EFA4@inrialpes.fr> Date: Thu, 13 Feb 2003 10:30:55 +0100 From: Vincent Roca Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: toni.paila@nokia.com, rmt@ietf.org Subject: Re: [Rmt] File delivery for ALC -- draft-paila-rmt-fdalc-00.txt References: <26574F0076BFF449ADAE582D9E67780C017541AF@esebe006.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Multicast Transport List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Toni, A few comments on draft-paila-rmt-fdalc-00.txt... File distribution is for sure the main use of ALC/LCT, and having guidelines explaining how to do that is useful. Yet there are several points on which I disagree. ** Your proposal is to keep file meta data (contained in the FDT object) separate from file objects. Doing that you create inter object dependencies: the receiving application cannot do anything with a file object until it has also received the associated FDT object. This is a source of inefficiencies (eg the file object can be rather large and require a large amount of RAM) and leads to useless delivery order assumptions (section 4). You can have a look at the famous Clark/Tennenhouse sigcomm90 paper on ALF for more background on why this is the wrong way of doing things. ** A file distribution over ALC scheme was already discussed in an early version (obsoleted of course) of ALC/LCT, draft-ietf-rmt-pi-alc-01.txt, in annex 1 (A File Transfer using ALC - 'Fcast'). You can retrieve it at URL: http://www.inrialpes.fr/planete/people/roca/mcl/doc/draft-ietf-rmt-pi-alc-01.txt We implemented it and have used it for more than 2 years now, under many different situations/assumptions without any problem. The approach is totally different from FDALC since file meta data are appended to the file content, and everything is submitted as a SINGLE ALC object. There is no inter-object dependencies and objects can be received in any order. The only limitation is that the number of objects in a session and the TOI of these objects are not specified with this approach (whereas these two informations are part of the FDT table in FDALC). In our implementation we bypass this problem by using sequential TOIs and adding a private header extension (PI specific extension of HET>63) indicating the number of TOIs in a session once this is known (ie. at session start if the sender must distribute a fixed number of files, or during the session if objects are produced dynamically). Of course this information can also be carried out of band (eg. in the SDP announcement) if this is known in advance. ** Requiring (or even recommending) that a single channel (layer) is used per ALC session (section 4) prevents the use of layered congestion control protocol and therefore the use of FDALC on the Internet... Even if this appropriate for closed non-Internet networks, it would be a pity to define a file delivery standard that cannot be used for the Internet. The remaining is for non critical remarks: ** Don't require that object be files; managing file slices within a file distribution session brings many benefits, especially when small block FEC codes are used (see our INRIA RR #4411 or the ISCC'02 paper). ** The use of SDP for session description is fine. Yet I would add (even if it is not always used) several additional information as mentioned in the LCT RFC: - congestion control protocol (this is a MUST!) - authentication scheme if used (something else ???) ** You say in section 3.2 that "delivery of a previous FDT MUST end before the delivery of the next FDT starts." What about delayed packets arriving several seconds after their transmission? Even if not common, it may happen. ** I have the feeling that you often assume a sequential delivery of packets on the channel(s). If ALC/LCT does not specify anything on the packet transmission order, in practice (at least in our implementation, I don't know for others) transmissions take place in a more or less random order (once again see INRIA RR #4411/ISCC'02 for the motivations behind it: congestion control, on-demand delivery, robustness...). ** Why should FDT version be limited to 65535 max ? Usually this is the kind of limitation we have with binary 16bit fields, but in case of FDALC this information is carried in a textual field and it makes no sense to have such a strict limitation. A limitation of 2^32-1 seems better. ** section 3.2, it is said that "a rx may use an FDT after its expiration time if..."! Why do you define expiration times it they are not used in certain cases ? ** section 3.2, it is said: "... or drop it [TOI 3 in the FDT]. In the latter case the interpretation should be that the file has already been delivered." Am I right if I replace "delivered" by "the source will not send any further packet for object TOI=3" ? In that case another way of doing it is to use the Close Object flag (B) of LCT. Hope it will help. And feel free to continue this discussion in-line or off-line, to share our respective experience on the subject. Cheers, vincent. ---------------------- http://www.inrialpes.fr/planete/people/roca/ INRIA Rhone-Alpes - projet planete vincent.roca@inrialpes.fr Zirst; 655 av. de l'Europe; Montbonnot phone (+33) 4.76.61.52.16 38334 ST ISMIER cedex - France fax (+33) 4.76.61.52.52 _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From mailnull@www1.ietf.org Thu Feb 13 06:21: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 GAA09506 for ; Thu, 13 Feb 2003 06:21:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DBV3i12514 for rmt-archive@odin.ietf.org; Thu, 13 Feb 2003 06:31: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 h1DBV3p12510 for ; Thu, 13 Feb 2003 06:31:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09486 for ; Thu, 13 Feb 2003 06:20:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DBQEp12267; Thu, 13 Feb 2003 06:26: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 h1DBPYp12219 for ; Thu, 13 Feb 2003 06:25:34 -0500 Received: from cs.tut.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09345 for ; Thu, 13 Feb 2003 06:15:13 -0500 (EST) Received: from rampe (rampe.atm.tut.fi [130.230.52.68]) by cs.tut.fi (8.8.8/8.8.8) with SMTP id NAA20221; Thu, 13 Feb 2003 13:18:53 +0200 (EET) From: "Rami Lehtonen" To: "Vincent Roca" , , Subject: RE: [Rmt] File delivery for ALC -- draft-paila-rmt-fdalc-00.txt Date: Thu, 13 Feb 2003 13:18:34 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <3E4B65CF.B129EFA4@inrialpes.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Multicast Transport List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > ** Requiring (or even recommending) that a single channel (layer) is > used per ALC session (section 4) prevents the use of layered congestion > control protocol and therefore the use of FDALC on the Internet... > Even if this appropriate for closed non-Internet networks, it would be a > pity to define a file delivery standard that cannot be used for the > Internet. Why this can't be used in the Internet? In my understanding the ALC base layer is always delivered to receivers and that can't be congestion controlled (of cource you can leave ALC session...). Why this is any different? Of course you don't have extra layers for higher bandwidth receivers. - Rami _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From mailnull@www1.ietf.org Thu Feb 13 08:19: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 IAA11650 for ; Thu, 13 Feb 2003 08:19:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DDTWl19534 for rmt-archive@odin.ietf.org; Thu, 13 Feb 2003 08:29: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 h1DDTWp19531 for ; Thu, 13 Feb 2003 08:29:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11641 for ; Thu, 13 Feb 2003 08:19:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DDPcp19395; Thu, 13 Feb 2003 08:25: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 h1DDOvp19362 for ; Thu, 13 Feb 2003 08:24:57 -0500 Received: from ebene.inrialpes.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11553 for ; Thu, 13 Feb 2003 08:14:28 -0500 (EST) Received: from imap-serv.inrialpes.fr (imap-serv.inrialpes.fr [194.199.18.72]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id h1DDI9D12094; Thu, 13 Feb 2003 14:18:09 +0100 (MET) Received: from inrialpes.fr (iseran.inrialpes.fr [194.199.24.100]) by imap-serv.inrialpes.fr (8.11.6/8.11.3/ImagV2) with ESMTP id h1DDI9S23463; Thu, 13 Feb 2003 14:18:09 +0100 (MET) Message-ID: <3E4B9B12.F9A975E2@inrialpes.fr> Date: Thu, 13 Feb 2003 14:18:10 +0100 From: Vincent Roca Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: Rami Lehtonen CC: toni.paila@nokia.com, rmt@ietf.org Subject: Re: [Rmt] File delivery for ALC -- draft-paila-rmt-fdalc-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Multicast Transport List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Rami, > Why this can't be used in the Internet? In my understanding the ALC base > layer is always delivered to receivers and that can't be congestion > controlled (of cource you can leave ALC session...). Why this is any > different? Of course you don't have extra layers for higher bandwidth > receivers. A fixed rate transmission cannot be considered TCP-friendly as it provides no means for receivers to adjust their reception rate. Remind that congestion control is one of the basic requirements identified by RFC 2357. You're right in the sense that the base layer, with layered congestion control protocols, is supposed to be sufficiently low not to cause congestion. This is an intrinsic limitation, right. But there is an easy way of increasing the reception rate: add layers. On the opposite, with a single layer, the only solution is to increase the transmission rate, well above the reasonable minimum... Besides, with a single layer you can't support heterogeneous receivers, which is one of the main assets of ALC over single rate NACK/ACK-based protocols... vincent ---------------------- http://www.inrialpes.fr/planete/people/roca/ INRIA Rhone-Alpes - projet planete vincent.roca@inrialpes.fr Zirst; 655 av. de l'Europe; Montbonnot phone (+33) 4.76.61.52.16 38334 ST ISMIER cedex - France fax (+33) 4.76.61.52.52 _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From mailnull@www1.ietf.org Fri Feb 14 06:53: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 GAA17776 for ; Fri, 14 Feb 2003 06:53:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1EBvLs19319 for rmt-archive@odin.ietf.org; Fri, 14 Feb 2003 06:57:21 -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 h1EBvLp19316 for ; Fri, 14 Feb 2003 06:57:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17750 for ; Fri, 14 Feb 2003 06:53:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EBpSp18836; Fri, 14 Feb 2003 06:51:28 -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 h1EBmdp18608 for ; Fri, 14 Feb 2003 06:48:39 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16970; Fri, 14 Feb 2003 06:44:32 -0500 (EST) Message-Id: <200302141144.GAA16970@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rmt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 14 Feb 2003 06:44:32 -0500 Subject: [Rmt] I-D ACTION:draft-ietf-rmt-bb-tree-config-03.txt Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Multicast Transport List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Reliable Multicast Transport Working Group of the IETF. Title : Reliable Multicast Transport Building Block: Tree Auto-Configuration Author(s) : B. Whetten et al. Filename : draft-ietf-rmt-bb-tree-config-03.txt Pages : 27 Date : 2003-2-13 The Reliable Multicast Transport Working Group has been chartered to standardize multicast transport services. This working group expects to initially standardize three protocol instantiations. This draft is concerned with the requirements of the tree-based ACK protocol. In particular, it is concerned with defining the building block for auto-configuration of the logical ACK-tree. According to the charter, a building block is 'a coarse-grained modular component that is common to multiple protocols along with abstract APIs that define a building block's access methods and their arguments.' For more information, see the Reliable Multicast Transport Building Blocks and Reliable Multicast Design Space documents [WLKHFL01][HWKFV00]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-tree-config-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rmt-bb-tree-config-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rmt-bb-tree-config-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-13152846.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-bb-tree-config-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-bb-tree-config-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-13152846.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From mailnull@www1.ietf.org Thu Feb 20 12:49:12 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 MAA22834 for ; Thu, 20 Feb 2003 12:49:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KHtqq00815 for rmt-archive@odin.ietf.org; Thu, 20 Feb 2003 12:55:52 -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 h1KHtqp00812 for ; Thu, 20 Feb 2003 12:55:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22829 for ; Thu, 20 Feb 2003 12:48:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KHspp00730; Thu, 20 Feb 2003 12:54:51 -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 h1KHr3p00658 for ; Thu, 20 Feb 2003 12:53:03 -0500 Received: from itd.nrl.navy.mil (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22781 for ; Thu, 20 Feb 2003 12:45:50 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by itd.nrl.navy.mil (8.8.8+Sun/8.8.8) with SMTP id MAA18600; Thu, 20 Feb 2003 12:49:31 -0500 (EST) Received: from [132.250.92.151] ([132.250.92.151]) by smtp.itd.nrl.navy.mil (SAVSMTP 3.0.1.45) with SMTP id M2003022012493119048 ; Thu, 20 Feb 2003 12:49:31 -0500 Mime-Version: 1.0 X-Sender: adamson@pop.itd.nrl.navy.mil Message-Id: Date: Thu, 20 Feb 2003 12:49:31 -0500 To: widmer@informatik.uni-mannheim.de, mjh@icir.org, rmt@ietf.org From: Brian Adamson Cc: adamson@itd.nrl.navy.mil, macker@itd.nrl.navy.mil Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Rmt] TFMCC Building Block document comments Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Multicast Transport List-Post: List-Help: List-Subscribe: , Hello Jorg, Mark, I've been updating the NORM BB & PI documents to be consistent with the RMT guidelines and to be consistent with the pertinent building block documents. In the previous NORM PI draft I had taken a shot at specifying TFMCC-like congestion control for NORM based on the TFMCC SIGCOMM papers and other related work. This was prior to the release of the TFMCC draft. I'm changing terminology in the NORM draft to be consistent with the terminology in the TFMCC draft and making some other changes. I think the TFMCC draft is very well-written, very well thought-out, and very clear. However, there a couple of areas where the TFMCC document, as a "building block", perhaps over-specifies some details for RMT protocol instantiations using its techniques. In several cases, different but functionally equivalent mechanisms might better fit a particular protocol instantiation (e.g. NORM). In the case of NORM, the only significant deviations from the wording of the TFMCC document is that NORM uses a special congestion control message instead of including overhead in every packet and that individual RTT measurements are performed by the sender and provided to the receiver group. With respect to the TFMCC approach, equivalent functionality is provided. (The previous NORM PI didn't have a "receiver_leave" flag specified, but this is being remedied). For the most part, I think the remaining NORM/TFMCC inconsistencies can be addressed by adding some more general language to the TFMCC recommendation to allow for different data sender protocol assumptions. The only other issues are that the NORM BB and TFMCC BB give two different RTT_max/GRTT estimation algorithms (see below) and a minor comment on sender rate adjustment in the absence of feedback from the CLR. So, here are my comments on the TFMCC document: --------------------- 1) TFMCC Data Sender Protocol Assumptions With respect to the NORM PI, the most significant semantic difference between it and TFMCC is that the NORM protocol uses a separate message (NORM_CMD(CC)) type to which is periodically sent once per CLR RTT (or RTT_max) to excite congestion control feedback from the receiver set rather than including overhead in every NORM_DATA message. In simulations I have conducted, I seem to get congestion control performance comparable to TFMCC with this approach. The reasons for this different approach is: a) With the overhead to accommodate FEC, NORM message overhead is already quite large and the congestion control additions start to significantly eat into the space available for user data given networks with limited MTUs. b) Although congestion control operation will be mandatory for general Internet use, the anticipated NORM user base will have a great deal of application in specialized networks where TCP-friendly congestion control may not be necessary or desirable. (The separate NORM_CMD(CC) message can allow for alternate congestion control schemes to be employed in these networks and its exclusion provides for fixed sender-rate operation). c) In addition to collecting explicit feedback from the "current limiting receiver" (CLR), the NORM_CMD(CC) also provides for optional collection of explicit feedback from a small set of "potential limiting receivers" (PLRs) (This was termed "worst path candidates" in the previous NORM draft). The probing of the PLR set allows for rapid congestion control response to receivers which, although perhaps not the current CLR, have been somehow identified (perhaps even administratively) as critical in congestion control (or flow control) operation. Our reliable multicast user base has expressed interest in this option. Impact on TFMCC Document: The TFMCC document could have language added to note that the data sender protocol might provide congestion control status to the group in a fashion as described above (at least once per CLR RTT or RTT_max). This mechanism also allows for a slightly different control paradigm for the TFMCC notion of "feedback rounds". In NORM, each NORM_CMD(CC) message sent by the data sender contains a "cc_sequence" number which basically identifies the "feedback round" --------------------- 2) Determining Maximum RTT The NORM BB document had specified a different means for tracking R_max (the NORM BB had termed this "GRTT") which we have been using for some time. The NORM GRTT algorithm provides a small amount of smoothing of GRTT peaks and reduces the GRTT only after multiple (3) consecutive rounds (thus allowing for feedback loss) with feedback indicators less than the current GRTT. I don't see these two different algorithms (TFMCC and NORM-BB) likey performing extremely differently for the most part, but they are different and either one should be selected for the RMT documents or some explanation given. I don't think this issue has been thoroughly studied and I'm not sure of all of the advantages/disadvantages of either over the other. The reason we smoothed the GRTT peaks a bit was that in experience, "user-space" code on a busy operating system would often give us large peaks and this seemed to help with the trade-off between protocol latency and feedback suppression. Since the next step is Experimental RFC for these documents, I think that perhaps some discussion be provided. I can do this in the NORM-BB. As for TFMCC, it may want to present its recommendation, but note this as an area for further study/experimentation? --------------------- 3) Adjusting the Sending Rate As a congestion avoidance measure, it may be useful to also reduce the transmission rate when no feedback is received from the CLR (even though feedback might have been received from other receivers), prior to timing-out the CLR under the "crashed or left group" assumption. For example, if no feedback is received from the CLR after 2-3 RTT, the rate should be reduced as a congestion avoidance measure. --------------------- 4) Receiver-Side RTT Measurements. In the NORM PI, the receivers echo back the sender timestamp (from previous NORM_CMD(CC) messages) and the sender performs the RTT measurement (it can use the receiver's provided previous RTT to smooth the measurement if the NORM_FLAG_RTT (equalt to "have_rtt") flag is set). The sender provides the RTT to receivers in a subsequent NORM_CMD(CC) transmission using the same sort of prioritization rules that are described in TFMCC to break ties. Note that one-way delay adjustments can still be done with this approach. This approach used by NORM is a little more efficient with overhead (in the context of NORM) since the RTT field provide to receivers can be readily compressed. Also this approach allows receivers to be aware of other receivers RTT which can potentially be used to make multi-sender RTT determination more efficient (This is perhaps outside of the immediate scope of one-to-many bulk transfer but may be applicable in the long run) -- Brian __________________________________ Brian Adamson _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From mailnull@www1.ietf.org Fri Feb 28 09:44: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 JAA00111 for ; Fri, 28 Feb 2003 09:44:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SEsfg01097 for rmt-archive@odin.ietf.org; Fri, 28 Feb 2003 09:54:41 -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 h1SEsfp01094 for ; Fri, 28 Feb 2003 09:54:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00104 for ; Fri, 28 Feb 2003 09:43:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SErvp01041; Fri, 28 Feb 2003 09:53: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 h1SEphp00911 for ; Fri, 28 Feb 2003 09:51:43 -0500 Received: from pi4.informatik.uni-mannheim.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29946 for ; Fri, 28 Feb 2003 09:40:39 -0500 (EST) Received: from informatik.uni-mannheim.de (meton [134.155.48.2]) by pi4.informatik.uni-mannheim.de (8.11.4/8.11.4) with ESMTP id h1SEbCv21451; Fri, 28 Feb 2003 15:37:12 +0100 (MET) Message-ID: <3E5F743E.4080602@informatik.uni-mannheim.de> Date: Fri, 28 Feb 2003 15:37:50 +0100 From: Joerg Widmer Organization: University of Mannheim User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Adamson CC: mjh@icir.org, macker@itd.nrl.navy.mil, RMT References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Rmt] Re: TFMCC Building Block document comments Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Multicast Transport List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Brian, thanks for your comments on the TFMCC draft. 1) I don't see any problems with the proposed changes. Having the congestion control information separate from the data packet seems fine to me though it'll limit the number of possible RTT measurements per feedback round. I can add a corresponding paragraph to the draft. 2) As for how to determine the max RTT I'll implement the NORM version and run some simulations to better understand it's impact on TFMCC. 3) We could align this with the TFRC draft where the sending rate is reduced by half if a nofeedback timer expires (with timeout value 4*RTT). Seems reasonable to me. 4) If sender-side RTT measurement are better suited for NORM we can add a paragraph that either sender- or receiver-side RTT measurements are possible as long as they allow for one-way RTT adjustments. Mark, are you ok with this? Cheers, Joerg > > In the case of NORM, the only significant deviations from the wording of > the TFMCC document is that NORM uses a special congestion control > message instead of including overhead in every packet and that > individual RTT measurements are performed by the sender and provided to > the receiver group. With respect to the TFMCC approach, equivalent > functionality is provided. (The previous NORM PI didn't have a > "receiver_leave" flag specified, but this is being remedied). For the > most part, I think the remaining NORM/TFMCC inconsistencies can be > addressed by adding some more general language to the TFMCC > recommendation to allow for different data sender protocol assumptions. > The only other issues are that the NORM BB and TFMCC BB give two > different RTT_max/GRTT estimation algorithms (see below) and a minor > comment on sender rate adjustment in the absence of feedback from the CLR. > > > > So, here are my comments on the TFMCC document: > > --------------------- > > 1) TFMCC Data Sender Protocol Assumptions > > With respect to the NORM PI, the most significant semantic difference > between it and TFMCC is that the NORM protocol uses a separate message > (NORM_CMD(CC)) type to which is periodically sent once per CLR RTT (or > RTT_max) to excite congestion control feedback from the receiver set > rather than including overhead in every NORM_DATA message. In > simulations I have conducted, I seem to get congestion control > performance comparable to TFMCC with this approach. > > The reasons for this different approach is: > > a) With the overhead to accommodate FEC, NORM message overhead is > already quite large and the congestion control additions start to > significantly eat into the space available for user data given networks > with limited MTUs. > > b) Although congestion control operation will be mandatory for general > Internet use, the anticipated NORM user base will have a great deal of > application in specialized networks where TCP-friendly congestion > control may not be necessary or desirable. (The separate NORM_CMD(CC) > message can allow for alternate congestion control schemes to be > employed in these networks and its exclusion provides for fixed > sender-rate operation). > > c) In addition to collecting explicit feedback from the "current > limiting receiver" (CLR), the NORM_CMD(CC) also provides for optional > collection of explicit feedback from a small set of "potential limiting > receivers" (PLRs) (This was termed "worst path candidates" in the > previous NORM draft). The probing of the PLR set allows for rapid > congestion control response to receivers which, although perhaps not the > current CLR, have been somehow identified (perhaps even > administratively) as critical in congestion control (or flow control) > operation. Our reliable multicast user base has expressed interest in > this option. > > Impact on TFMCC Document: > > The TFMCC document could have language added to note that the data > sender protocol might provide congestion control status to the group in > a fashion as described above (at least once per CLR RTT or RTT_max). > This mechanism also allows for a slightly different control paradigm for > the TFMCC notion of "feedback rounds". In NORM, each NORM_CMD(CC) > message sent by the data sender contains a "cc_sequence" number which > basically identifies the "feedback round" > > > --------------------- > 2) Determining Maximum RTT > > The NORM BB document had specified a different means for tracking R_max > (the NORM BB had termed this "GRTT") which we have been using for some > time. > > The NORM GRTT algorithm provides a small amount of smoothing of GRTT > peaks and reduces the GRTT only after multiple (3) consecutive rounds > (thus allowing for feedback loss) with feedback indicators less than the > current GRTT. > > I don't see these two different algorithms (TFMCC and NORM-BB) likey > performing extremely differently for the most part, but they are > different and either one should be selected for the RMT documents or > some explanation given. I don't think this issue has been thoroughly > studied and I'm not sure of all of the advantages/disadvantages of > either over the other. The reason we smoothed the GRTT peaks a bit was > that in experience, "user-space" code on a busy operating system would > often give us large peaks and this seemed to help with the trade-off > between protocol latency and feedback suppression. Since the next step > is Experimental RFC for these documents, I think that perhaps some > discussion be provided. I can do this in the NORM-BB. As for TFMCC, it > may want to present its recommendation, but note this as an area for > further study/experimentation? > > --------------------- > > 3) Adjusting the Sending Rate > > As a congestion avoidance measure, it may be useful to also reduce the > transmission rate when no feedback is received from the CLR (even though > feedback might have been received from other receivers), prior to > timing-out the CLR under the "crashed or left group" assumption. For > example, if no feedback is received from the CLR after 2-3 RTT, the rate > should be reduced as a congestion avoidance measure. > > --------------------- > > 4) Receiver-Side RTT Measurements. > > In the NORM PI, the receivers echo back the sender timestamp (from > previous NORM_CMD(CC) messages) and the sender performs the RTT > measurement (it can use the receiver's provided previous RTT to smooth > the measurement if the NORM_FLAG_RTT (equalt to "have_rtt") flag is > set). The sender provides the RTT to receivers in a subsequent > NORM_CMD(CC) transmission using the same sort of prioritization rules > that are described in TFMCC to break ties. Note that one-way delay > adjustments can still be done with this approach. This approach used by > NORM is a little more efficient with overhead (in the context of NORM) > since the RTT field provide to receivers can be readily compressed. > Also this approach allows receivers to be aware of other receivers RTT > which can potentially be used to make multi-sender RTT determination > more efficient (This is perhaps outside of the immediate scope of > one-to-many bulk transfer but may be applicable in the long run) > > _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From mailnull@www1.ietf.org Fri Feb 28 13:08: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 NAA07699 for ; Fri, 28 Feb 2003 13:08:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SIIgn17055 for rmt-archive@odin.ietf.org; Fri, 28 Feb 2003 13:18:42 -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 h1SIIgp17052 for ; Fri, 28 Feb 2003 13:18:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07693 for ; Fri, 28 Feb 2003 13:07:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SIHJp16948; Fri, 28 Feb 2003 13:17:19 -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 h1SIGsp16904 for ; Fri, 28 Feb 2003 13:16:54 -0500 Received: from mmm.icir.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07595 for ; Fri, 28 Feb 2003 13:05:45 -0500 (EST) Received: from mmm.icir.org (localhost [127.0.0.1]) by mmm.icir.org (8.12.6/8.12.6) with ESMTP id h1SI9ZBE015620; Fri, 28 Feb 2003 10:09:36 -0800 (PST) From: Mark Handley X-Organisation: ICIR To: Joerg Widmer cc: Brian Adamson , macker@itd.nrl.navy.mil, RMT In-reply-to: Your message of "Fri, 28 Feb 2003 15:37:50 +0100." <3E5F743E.4080602@informatik.uni-mannheim.de> Date: Fri, 28 Feb 2003 10:09:32 -0800 Message-ID: <15619.1046455772@mmm.icir.org> Subject: [Rmt] Re: TFMCC Building Block document comments Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Multicast Transport List-Post: List-Help: List-Subscribe: , >1) I don't see any problems with the proposed changes. Having the >congestion control information separate from the data packet seems fine >to me though it'll limit the number of possible RTT measurements per >feedback round. I can add a corresponding paragraph to the draft. We should probably state that it can be piggybacked, or in separate packets. Then we should state what the requirements are for how often we need to measure, taking loss into account. >3) We could align this with the TFRC draft where the sending rate is >reduced by half if a nofeedback timer expires (with timeout value >4*RTT). Seems reasonable to me. You might want to be conservative on the nofeedback timer - you'd like to take variance into account, not just RTT, but this isn't too easy to do for TFMCC. >4) If sender-side RTT measurement are better suited for NORM we can add >a paragraph that either sender- or receiver-side RTT measurements are >possible as long as they allow for one-way RTT adjustments. Although the receiver does need to have its RTT measurement to figure out congestion events. I have a slight preference for specifying one way to do this only. I think receiver-based is slightly preferable, because it adds half an RTT less delay. Is there a good reason NORM can't do receiver-based? - Mark _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From mailnull@www1.ietf.org Fri Feb 28 15:03: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 PAA11073 for ; Fri, 28 Feb 2003 15:03:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SKDNg24900 for rmt-archive@odin.ietf.org; Fri, 28 Feb 2003 15:13:23 -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 h1SKDNp24897 for ; Fri, 28 Feb 2003 15:13:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11045 for ; Fri, 28 Feb 2003 15:02:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SKCKp24797; Fri, 28 Feb 2003 15:12:20 -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 h1SKBYp24767 for ; Fri, 28 Feb 2003 15:11:34 -0500 Received: from itd.nrl.navy.mil (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10963 for ; Fri, 28 Feb 2003 15:00:32 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by itd.nrl.navy.mil (8.8.8+Sun/8.8.8) with SMTP id PAA20517; Fri, 28 Feb 2003 15:04:13 -0500 (EST) Received: from [132.250.92.151] ([132.250.92.151]) by smtp.itd.nrl.navy.mil (SAVSMTP 3.0.1.45) with SMTP id M2003022815041309698 ; Fri, 28 Feb 2003 15:04:13 -0500 Mime-Version: 1.0 X-Sender: adamson@pop.itd.nrl.navy.mil Message-Id: In-Reply-To: <15619.1046455772@mmm.icir.org> References: <15619.1046455772@mmm.icir.org> Date: Fri, 28 Feb 2003 15:04:18 -0500 To: Mark Handley , Joerg Widmer From: Brian Adamson Subject: [Rmt] Re: TFMCC Building Block document comments Cc: macker@itd.nrl.navy.mil, RMT Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Multicast Transport List-Post: List-Help: List-Subscribe: , At 10:09 AM -0800 2/28/03, Mark Handley wrote: > >1) I don't see any problems with the proposed changes. Having the >>congestion control information separate from the data packet seems fine >>to me though it'll limit the number of possible RTT measurements per >>feedback round. I can add a corresponding paragraph to the draft. > >We should probably state that it can be piggybacked, or in separate >packets. Then we should state what the requirements are for how often >we need to measure, taking loss into account. > >>3) We could align this with the TFRC draft where the sending rate is >>reduced by half if a nofeedback timer expires (with timeout value >>4*RTT). Seems reasonable to me. > >You might want to be conservative on the nofeedback timer - you'd like >to take variance into account, not just RTT, but this isn't too easy >to do for TFMCC. > >>4) If sender-side RTT measurement are better suited for NORM we can add >>a paragraph that either sender- or receiver-side RTT measurements are >>possible as long as they allow for one-way RTT adjustments. > >Although the receiver does need to have its RTT measurement to figure >out congestion events. I have a slight preference for specifying one >way to do this only. I think receiver-based is slightly preferable, >because it adds half an RTT less delay. Is there a good reason NORM >can't do receiver-based? I think in both cases, NORM and TFMCC, the sender can determine the RTT to a receiver upon receiving a feedback message from the receiver since the receiver message has a previous sender timestamp in it. (The TFMCC receiver feedback message also has a receiver timestamp) With NORM, the sender echoes the calculated RTT back to the receiver where in TFMCC the sender echoes the receiver timestamp back to the receiver ... in this respect the TFMCC receiver RTT measurement is half an RTT fresher. I don't think this is significant with respect to congestion control performance. NORM's sender-side approach gets rid of the need to communicate the receiver timestamp in feedback messages. And in the messages sent by the NORM sender, the RTT can be compressed to a smaller field than the receiver timestamp. The current NORM approach also allows other receivers to see the RTT of other receivers ... While this isn't currently useful in a one-to-many bulk transfer paradigm, knowledge of other NORM nodes' RTT might be leveraged for multi-way RTT determination in the future. It's also a _little_ less CPU work for the sender to just provide the RTT measurement to tre receiver and not also keep track of the hold-time and adjust the receiver timestamp echoed. NORM _could_ do receiver-based if you think it will significantly impact congestion control performance. This could be done instead of or in addition to the sender-provided RTT. But in my simulations, both seem to work equivalently well - but I haven't conducted an extensive study of this issue. > > - Mark > > > >_______________________________________________ >Rmt mailing list >Rmt@ietf.org >https://www1.ietf.org/mailman/listinfo/rmt -- Brian __________________________________ Brian Adamson _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt