From owner-rmt@listserv.lbl.gov Thu Sep 7 16:07:45 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26048 for ; Thu, 7 Sep 2000 16:07:45 -0400 (EDT) Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id MAA14434; Thu, 7 Sep 2000 12:01:23 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA14430 for ; Thu, 7 Sep 2000 12:01:21 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA22007 for ; Thu, 7 Sep 2000 12:01:20 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA21996 for ; Thu, 7 Sep 2000 12:01:19 -0700 (PDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA05488; Thu, 7 Sep 2000 12:01:17 -0700 (PDT) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA13675; Thu, 7 Sep 2000 15:01:16 -0400 (EDT) Received: from bridge (bridge [129.148.75.125]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id PAA08321; Thu, 7 Sep 2000 15:01:15 -0400 (EDT) Message-Id: <200009071901.PAA08321@bcn.East.Sun.COM> Date: Thu, 7 Sep 2000 15:01:14 -0400 (EDT) From: Dah Ming Chiu - Sun Microsystems Reply-To: Dah Ming Chiu - Sun Microsystems Subject: Re: Choices for TRACK/NACK report encoding To: rmt@lbl.gov Cc: whetten@talarian.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: IqPwktKKWF/+PS9/WA2fiA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-rmt@lbl.gov Precedence: bulk I had a brief discussion with Brian Whetten regarding his concerns on loss packet report encoding. He seems to be concerned with a scenario where there are a large number, K, packets in flight (meaning potentially a receiver may report a loss of any one of them), where K can be as large as many thousands. A receiver lost the first of the K packets; and due to the fat-long pipe to its repair head (or sender), it soon is receiving the Kth packet before the first lost packet is repaired. In this "worse case" example, the receiver also lost the (K-1)th packet. So this receiver needs an efficient way to report the status of K packets (received or not received) to its repair head or the sender. Based on this, he did a quick analysis of three schemes: a) listing out the sequence number of each lost packet b) use a bitmask of size K to indicate which ones are lost c) use Run Length Encoding to indicate which ones are lost and concluded that RLE is the best. In the particular example above, a total of 2 of K packets lost, the rough encoding overhead is respectively: a) 2*W b) W+K c) W+2*logK where W is the size of a sequence number (32). If in additional to the above 2 lost packet, there are an additional (n-2) lost packets - making it a total of n lost packets, then: a) n*W b) W+K c) W+n*logK What is wrong with this analysis, I think some other people have also pointed out, is that it does not take into account the option of sending multiple ACKs (here an ACK is a general term for a common receipt/lost reporting message). Of course, there is some overhead in sending each ACK. But in the case of (b), sending multiple ACKs would be more efficient than sending a huge bitmask of size K. It is complicated to do an exact analysis of the different encodings taking into account of the option of sending multiple ACKs. On the other hand, I don't think the result differ that much for us to be concerned about it. I think we should just adopt something simple. Having a sequence number plus an optional bit mask - where the sequence number indicates receipt up to, and the mask indicates lost packets - is simple and flexible. As to whether it makes sense to run a reliability service with K packets in flight for such large K makes sense or not, that is another debate. Does this make sense? Dah Ming From owner-rmt@listserv.lbl.gov Fri Sep 8 04:35:03 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18935 for ; Fri, 8 Sep 2000 04:35:02 -0400 (EDT) Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id AAA17019; Fri, 8 Sep 2000 00:15:45 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA17015 for ; Fri, 8 Sep 2000 00:15:43 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA18894 for ; Fri, 8 Sep 2000 00:15:43 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id AAA18891 for ; Fri, 8 Sep 2000 00:15:41 -0700 (PDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 8 Sep 2000 08:15:26 +0100 To: Dah Ming Chiu - Sun Microsystems cc: rmt@lbl.gov, whetten@talarian.com Subject: Re: Choices for TRACK/NACK report encoding In-reply-to: Your message of "Thu, 07 Sep 2000 15:01:14 EDT." <200009071901.PAA08321@bcn.East.Sun.COM> Date: Fri, 08 Sep 2000 08:15:24 +0100 Message-ID: <1132.968397324@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-rmt@lbl.gov Precedence: bulk analysis looks ok to me - there was an analysis done for SACK in TCP that is worth re-reading (look on end2end-interest archive) its not clear why multicast is so different (theres probably enough reasons for occasional feedback messages and a hierarchy for very large groups that within each group the loss feedback packet encdoding can be similar to SACK or possibly RTCP... one thing is do we believe in long loss bursts or scattered bursts...? In message <200009071901.PAA08321@bcn.East.Sun.COM>, Dah Ming Chiu - Sun Micros ystems typed: >>I had a brief discussion with Brian Whetten regarding his concerns >>on loss packet report encoding. >> >>He seems to be concerned with a scenario where there are a large number, >>K, packets in flight (meaning potentially a receiver may report a >>loss of any one of them), where K can be as large as many thousands. >>A receiver lost the first of the K packets; and due to the fat-long >>pipe to its repair head (or sender), it soon is receiving the Kth packet >>before the first lost packet is repaired. In this "worse case" example, >>the receiver also lost the (K-1)th packet. So this receiver needs an >>efficient way to report the status of K packets (received or not received) >>to its repair head or the sender. >> >>Based on this, he did a quick analysis of three schemes: >>a) listing out the sequence number of each lost packet >>b) use a bitmask of size K to indicate which ones are lost >>c) use Run Length Encoding to indicate which ones are lost >>and concluded that RLE is the best. >> >>In the particular example above, a total of 2 of K packets lost, the rough >>encoding overhead is respectively: >>a) 2*W >>b) W+K >>c) W+2*logK >>where W is the size of a sequence number (32). >> >>If in additional to the above 2 lost packet, there are an additional (n-2) >>lost packets - making it a total of n lost packets, then: >>a) n*W >>b) W+K >>c) W+n*logK >> >>What is wrong with this analysis, I think some other people have also >>pointed out, is that it does not take into account the option of sending >>multiple ACKs (here an ACK is a general term for a common receipt/lost >>reporting message). Of course, there is some overhead in sending each >>ACK. But in the case of (b), sending multiple ACKs would be more efficient >>than sending a huge bitmask of size K. >> >>It is complicated to do an exact analysis of the different encodings taking >>into account of the option of sending multiple ACKs. On the other hand, >>I don't think the result differ that much for us to be concerned about it. >> >>I think we should just adopt something simple. Having a sequence number >>plus an optional bit mask - where the sequence number indicates receipt >>up to, and the mask indicates lost packets - is simple and flexible. >> >>As to whether it makes sense to run a reliability service with K packets >>in flight for such large K makes sense or not, that is another debate. >> >>Does this make sense? >> >>Dah Ming >> >> cheers jon From owner-rmt@listserv.lbl.gov Fri Sep 8 05:31:30 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA19363 for ; Fri, 8 Sep 2000 05:31:29 -0400 (EDT) Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id BAA17110; Fri, 8 Sep 2000 01:33:10 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA17106 for ; Fri, 8 Sep 2000 01:33:03 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA24604 for ; Fri, 8 Sep 2000 01:33:02 -0700 (PDT) Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA24597 for ; Fri, 8 Sep 2000 01:33:01 -0700 (PDT) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id KAA32615; Fri, 8 Sep 2000 10:34:37 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200009080834.KAA32615@info.iet.unipi.it> Subject: Re: Choices for TRACK/NACK report encoding In-Reply-To: <1132.968397324@cs.ucl.ac.uk> from Jon Crowcroft at "Sep 8, 2000 08:15:24 am" To: Jon Crowcroft Date: Fri, 8 Sep 2000 10:34:37 +0200 (CEST) CC: Dah Ming Chiu - Sun Microsystems , rmt@lbl.gov, whetten@talarian.com X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Content-Transfer-Encoding: 7bit > analysis > looks ok to me - there was an analysis done for SACK in TCP that is > worth re-reading (look on end2end-interest archive) i do not remember the details but the result ("we only need 3 sack blocks") look more driven by available option space than other considerations. I believe one reason multicast is somewhat different is that delayed feedback gives you the chance to report slightly higher amt of losses in a single msg as opposed to what you do in TCP where you {S|N}AK immediately. > one thing is do we believe in long loss bursts or scattered > bursts...? the experience with mbone sessions is often 30s bursts of silence, but that can be fixed hopefully... Seriously speaking, as long as multicast sessions are not as bursty as TCP, i think that more than long loss bursts (which are usually due to routing problems) we can see the typical losses due to rate mismatches, or patterns like this ....x....x....x....x....x.... ...x..x..x..x..x..x..x..x..x. .xxx.xxx.xxx.xxx.xxx.xxx.xxx. cheers luigi From owner-rmt@listserv.lbl.gov Fri Sep 8 05:43:21 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA19420 for ; Fri, 8 Sep 2000 05:43:20 -0400 (EDT) Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id BAA17138; Fri, 8 Sep 2000 01:38:05 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA17134 for ; Fri, 8 Sep 2000 01:38:03 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA25031 for ; Fri, 8 Sep 2000 01:38:03 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id BAA25028 for ; Fri, 8 Sep 2000 01:38:02 -0700 (PDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 8 Sep 2000 09:37:56 +0100 To: Luigi Rizzo cc: Dah Ming Chiu - Sun Microsystems , rmt@lbl.gov, whetten@talarian.com Subject: Re: Choices for TRACK/NACK report encoding In-reply-to: Your message of "Fri, 08 Sep 2000 10:34:37 +0200." <200009080834.KAA32615@info.iet.unipi.it> Date: Fri, 08 Sep 2000 09:37:54 +0100 Message-ID: <2045.968402274@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-rmt@lbl.gov Precedence: bulk In message <200009080834.KAA32615@info.iet.unipi.it>, Luigi Rizzo typed: >>> analysis >>> looks ok to me - there was an analysis done for SACK in TCP that is >>> worth re-reading (look on end2end-interest archive) >> >>i do not remember the details but the result ("we only need 3 >>sack blocks") look more driven by available option space than >>other considerations. I believe one reason multicast is somewhat different >>is that delayed feedback gives you the chance to report slightly higher >>amt of losses in a single msg as opposed to what you do in TCP >>where you {S|N}AK immediately. >> >>> one thing is do we believe in long loss bursts or scattered >>> bursts...? >> >>the experience with mbone sessions is often 30s bursts of silence, >>but that can be fixed hopefully... >>Seriously speaking, as long as multicast sessions are not as bursty >>as TCP, i think that more than long loss bursts (which are usually >>due to routing problems) we can see the typical losses due to rate >>mismatches, or patterns like this >> >> ....x....x....x....x....x.... >> ...x..x..x..x..x..x..x..x..x. >> .xxx.xxx.xxx.xxx.xxx.xxx.xxx. luigi and of course wee might want to consider router or repair server assist in aggregating the loss patterns... cheers jon From owner-rmt@listserv.lbl.gov Fri Sep 8 11:42:07 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24694 for ; Fri, 8 Sep 2000 11:42:07 -0400 (EDT) Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id HAA18547; Fri, 8 Sep 2000 07:52:29 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA18543 for ; Fri, 8 Sep 2000 07:52:27 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA01041 for ; Fri, 8 Sep 2000 07:52:27 -0700 (PDT) Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA01037 for ; Fri, 8 Sep 2000 07:52:26 -0700 (PDT) Received: from [132.250.92.151] (manimac.itd.nrl.navy.mil [132.250.92.151]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA06465; Fri, 8 Sep 2000 10:52:05 -0400 (EDT) Mime-Version: 1.0 X-Sender: adamson@pop.itd.nrl.navy.mil Message-Id: In-Reply-To: <200009080834.KAA32615@info.iet.unipi.it> References: <200009080834.KAA32615@info.iet.unipi.it> Date: Fri, 8 Sep 2000 10:52:05 -0400 To: Luigi Rizzo From: Brian Adamson Subject: Re: Choices for TRACK/NACK report encoding Cc: Jon Crowcroft , Dah Ming Chiu - Sun Microsystems , rmt@lbl.gov, whetten@talarian.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-rmt@lbl.gov Precedence: bulk At 10:34 AM +0200 9/8/00, Luigi Rizzo wrote: > > analysis > > looks ok to me - there was an analysis done for SACK in TCP that is > > worth re-reading (look on end2end-interest archive) > >i do not remember the details but the result ("we only need 3 >sack blocks") look more driven by available option space than >other considerations. I believe one reason multicast is somewhat different >is that delayed feedback gives you the chance to report slightly higher >amt of losses in a single msg as opposed to what you do in TCP >where you {S|N}AK immediately. > > > one thing is do we believe in long loss bursts or scattered > > bursts...? > >the experience with mbone sessions is often 30s bursts of silence, >but that can be fixed hopefully... >Seriously speaking, as long as multicast sessions are not as bursty >as TCP, i think that more than long loss bursts (which are usually >due to routing problems) we can see the typical losses due to rate >mismatches, or patterns like this > > ....x....x....x....x....x.... > ...x..x..x..x..x..x..x..x..x. > .xxx.xxx.xxx.xxx.xxx.xxx.xxx. One of the nice applications of reliable multicast is over satellite services ... at reasonable data rates (several megabits per second), outages which are relatively momentary (a few seconds) can span several FEC coding blocks worth of information and do occur occasionally ... Also depending upon different application policies of when/how receivers join & leave groups or discontinuities during handoff in mobile-wireless systems, there will be times when receivers need to NACK for large portions of data ... Those are some of the reasons I would propose a hierarchical scheme for NACK encoding given that use of FEC blocks (if applicable) provide a natural boundary ... I suppose this isn't much different from the end result of a run-length encoding scheme, but alignment of hierarchical NACKs to coding blocks was easy to implement. > cheers > luigi Brian __________________________________ Brian Adamson From owner-rmt@listserv.lbl.gov Fri Sep 8 12:04:13 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25060 for ; Fri, 8 Sep 2000 12:04:12 -0400 (EDT) Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id IAA18582; Fri, 8 Sep 2000 08:11:10 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA18578 for ; Fri, 8 Sep 2000 08:11:08 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA05502 for ; Fri, 8 Sep 2000 08:11:08 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id IAA05499 for ; Fri, 8 Sep 2000 08:11:07 -0700 (PDT) Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 8 Sep 2000 16:10:49 +0100 To: Brian Adamson cc: rmt@lbl.gov Subject: Re: Choices for TRACK/NACK report encoding In-reply-to: Your message of "Fri, 08 Sep 2000 10:52:05 EDT." Date: Fri, 08 Sep 2000 16:10:49 +0100 Message-ID: <2163.968425849@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-rmt@lbl.gov Precedence: bulk so we have a large range+accuracy problem in returning data to the sender(s) about missing sequence numbers and so if the ack return path is noisy, then lets subject the problem to the same attack s we did to data in the forward path layered FEC encoded SACK messages... cheers jon From owner-rmt@listserv.lbl.gov Fri Sep 8 14:36:52 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27665 for ; Fri, 8 Sep 2000 14:36:51 -0400 (EDT) Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id KAA19209; Fri, 8 Sep 2000 10:40:49 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA19205 for ; Fri, 8 Sep 2000 10:40:48 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA23042 for ; Fri, 8 Sep 2000 10:40:47 -0700 (PDT) Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA23038 for ; Fri, 8 Sep 2000 10:40:46 -0700 (PDT) Received: from tahoe (talarian32-66.talarian.com [207.5.32.66]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id KAA01685; Fri, 8 Sep 2000 10:40:10 -0700 (PDT) Message-Id: <4.1.20000908100047.021b5eb0@mailhost.talarian.com> X-Sender: bwhetten@mailhost.talarian.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 08 Sep 2000 10:39:30 -0700 To: Jon Crowcroft , Brian Adamson From: Brian Whetten Subject: Re: Choices for TRACK/NACK report encoding Cc: rmt@lbl.gov In-Reply-To: <2163.968425849@cs.ucl.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rmt@lbl.gov Precedence: bulk Hello, My original concern were that I would like us to come up with ONE form for NACK encoding, that is the same for both TRACK and NACK, and is as simple as possible. Also, I would like the mechanism to have enough redundancy built in that reliable NACKs are not needed. Jon, RM is different than unicast primarily because optimizing the return control traffic is one of our primary challenges (i.e. minimizing ACK/NACK implosion). Dah Ming, good point. Actually, the biggest problem with bitmaps, that I forgot about, is how you do the aggregation of FEC counts as you move up a hierarchy. You can solve this, but only with added complexity. If you are using one big RLE bitmap, you have to unpack it to make it intelligible by the intermediary nodes, which is probably too much overhead. Jon, I think FEC encoded NACK bitmaps is overly complex and unecessary, but I'm not sure I actually understand what your proposal is. Brian, my initial reaction to your proposal was that it was too complex, but now I'm not so sure. One issue though, is that you need to pass up the most recent congestion information you have in each NACK. If you are not NACKing the most recent packets, then this has to definitely be explicitly reported, rather than implicitly derived at the sender. This might cause problems for PGMCC, for example. I think that the need to do FEC count aggregation is a good argument against using a single long RLE bitmap. So I think we are left with three primary design choices: 1) How to encode each block of packets? i.e. Count, Bitmap, None (for list NACKs, each block is of size 1) 2) How to encode the series of blocks? Do we assume that they are all sequential, or do you encode each block with its starting sequence number? (note that this assumes the length of each block is the same) 3) How much history to put in each NACK? Do we just list the most immediate packets, or do we have some partial redundancy, or do we always encode the entire outstanding window? The more information we encode, the simpler the NACK generation algorithms become, but the harder the encoding algorithms in order to be able to deal with large windows. Brian At 04:10 PM 9/8/2000 +0100, Jon Crowcroft wrote: > >so we have a large range+accuracy problem in returning >data to the sender(s) about missing sequence numbers >and so if the ack return path is noisy, then lets subject >the problem to the same attack s we did to data in the forward >path > >layered FEC encoded SACK messages... > > cheers > > jon > From owner-rmt@listserv.lbl.gov Fri Sep 8 15:14:25 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28464 for ; Fri, 8 Sep 2000 15:14:24 -0400 (EDT) Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id LAA19496; Fri, 8 Sep 2000 11:22:31 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA19492 for ; Fri, 8 Sep 2000 11:22:29 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA07554 for ; Fri, 8 Sep 2000 11:22:28 -0700 (PDT) Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA07542 for ; Fri, 8 Sep 2000 11:22:27 -0700 (PDT) Received: from [132.250.92.151] (manimac.itd.nrl.navy.mil [132.250.92.151]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA13297; Fri, 8 Sep 2000 14:19:02 -0400 (EDT) Mime-Version: 1.0 X-Sender: adamson@pop.itd.nrl.navy.mil Message-Id: In-Reply-To: <4.1.20000908100047.021b5eb0@mailhost.talarian.com> References: <4.1.20000908100047.021b5eb0@mailhost.talarian.com> Date: Fri, 8 Sep 2000 14:19:02 -0400 To: Brian Whetten From: Brian Adamson Subject: Re: Choices for TRACK/NACK report encoding Cc: Jon Crowcroft , rmt@lbl.gov Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-rmt@lbl.gov Precedence: bulk At 10:39 AM -0700 9/8/00, Brian Whetten wrote: >Hello, > >My original concern were that I would like us to come up with ONE form for >NACK encoding, that is the same for both TRACK and NACK, and is as simple >as possible. Also, I would like the mechanism to have enough redundancy >built in that reliable NACKs are not needed. > >Jon, RM is different than unicast primarily because optimizing the return >control traffic is one of our primary challenges (i.e. minimizing ACK/NACK >implosion). > >Dah Ming, good point. Actually, the biggest problem with bitmaps, that I >forgot about, is how you do the aggregation of FEC counts as you move up a >hierarchy. You can solve this, but only with added complexity. If you are >using one big RLE bitmap, you have to unpack it to make it intelligible by >the intermediary nodes, which is probably too much overhead. > >Jon, I think FEC encoded NACK bitmaps is overly complex and unecessary, but >I'm not sure I actually understand what your proposal is. I haven't grok'd that yet either. > >Brian, my initial reaction to your proposal was that it was too complex, >but now I'm not so sure. One issue though, is that you need to pass up the >most recent congestion information you have in each NACK. If you are not >NACKing the most recent packets, then this has to definitely be explicitly >reported, rather than implicitly derived at the sender. This might cause >problems for PGMCC, for example. The congestion control feedback could use different sequence information than the data content identification ... For example, if a different sequence number (i.e. different than the data content identification sequencing) is used to mark packets for loss detection that could be used in congestion control feedback ... In our MDP congestion control implementation, we don't insert congestion control probing information (which is marked with its own sequence number) separately from transmitted data ... For something like PGMCC which is doing a TCP-like ACK of the data packets, the "packet loss" sequence marker on the data packets could perhaps be used? ... I think data content identification needs to be separate for selective repair anyway? ... The "hierarchy" of coding block and segments gives you a degree of NACK compression analogous to RLE and then aggregation doesn't require the RLE decompression/re-encoding step you mention above > >I think that the need to do FEC count aggregation is a good argument >against using a single long RLE bitmap. > >So I think we are left with three primary design choices: >1) How to encode each block of packets? i.e. Count, Bitmap, None (for >list NACKs, each block is of size 1) >2) How to encode the series of blocks? Do we assume that they are all >sequential, or do you encode each block with its starting sequence number? >(note that this assumes the length of each block is the same) Yes ... my assumption was that the bitmask marked a sequential series of coding blocks ... in our case, the blocks are uniform in size so the "offset" or data content sequence identifier of the first segment of the block serves as the block identifier ... I think non-uniform blocks could be accommodated, but the block identifier might need to be interpreted differently ... but that might only be the concern of the end systems ... intermediate systems (like generic assist routers) might still be able to perform aggregation/pruning, etc without needing to know that information ... this would be different for more tree-based protocols which might wish to perform repair subcasting, etc. >3) How much history to put in each NACK? Do we just list the most >immediate packets, or do we have some partial redundancy, or do we always >encode the entire outstanding window? The more information we encode, the >simpler the NACK generation algorithms become, but the harder the encoding >algorithms in order to be able to deal with large windows. The policy I have used in the past is to put as much history in the NACK (only back to the point to where repair is needed) which will fit into a single NACK message using the multicast session MTU as the maximum payload size ... For normal circumstances, NACKs tend to be small ... this limit is only hit when conditions are bad ... In our protocol, the sender actually sort of nacks NACKs when those repair requests ask for repairs earlier in history than the server is willing to repair (for whatever reason, buffer limitations, expired data, etc) ... In this NACK to the NACK (which we actually call a SQUELCH command in protocol specification), the sender advertises his current "window" of data he is willing to repair ... This "SQUELCH" is multicast so that all receivers (some of which may be in the same state as the original NACKer) can "re-sync" to the sender and not generate anymore useless NACKs ... again this is the _exceptional_ occurrence when conditions are very bad, and server buffer limits (or other limits) are otherwise exceeded. >Brian Brian __________________________________ Brian Adamson From owner-rmt@listserv.lbl.gov Fri Sep 8 17:23:33 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00846 for ; Fri, 8 Sep 2000 17:23:32 -0400 (EDT) Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id NAA19869; Fri, 8 Sep 2000 13:17:17 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA19865 for ; Fri, 8 Sep 2000 13:17:15 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA14174 for ; Fri, 8 Sep 2000 13:17:15 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA14163 for ; Fri, 8 Sep 2000 13:17:14 -0700 (PDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA10058 for ; Fri, 8 Sep 2000 13:17:12 -0700 (PDT) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA22672 for ; Fri, 8 Sep 2000 16:17:11 -0400 (EDT) Received: from bridge (bridge [129.148.75.125]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id QAA12322 for ; Fri, 8 Sep 2000 16:17:11 -0400 (EDT) Message-Id: <200009082017.QAA12322@bcn.East.Sun.COM> Date: Fri, 8 Sep 2000 16:17:09 -0400 (EDT) From: Dah Ming Chiu - Sun Microsystems Reply-To: Dah Ming Chiu - Sun Microsystems Subject: Re: Choices for TRACK/NACK report encoding To: rmt@lbl.gov MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ipYhK4dbBjoAN6bKrs/siw== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-rmt@lbl.gov Precedence: bulk Brian Whetthen wrote: >My original concern were that I would like us to come up with ONE form for >NACK encoding, that is the same for both TRACK and NACK, and is as simple >as possible. Also, I would like the mechanism to have enough redundancy >built in that reliable NACKs are not needed. Yes, this is a very good goal. I am having a little trouble following Brian Adamson's "hierarchical coding block" proposal. I think the problem is with terminology. If you can bear with me and explain your needs in simple terms, perhaps we can work out some common format. Let me state what I understand, and you can correct me where I err: In TRACK terminology, regular FEC encoded stream does not require loss feedback - it is "open loop". In "reactive" FEC usage, the sender computes "parity" packets but does not send them until losses are reported. This is the case error reporting is needed. What is needed at the sender to determine what parity packets to send is a count of lost packets (given a window of packets), rather than the specific packets lost. This count determines the number of parity packets needed. To aggregate the count up the tree to the sender, you need a bitmap to know which packets are lost by each receiver so you don't count duplicate packets. This makes the requirement for reporting losses roughly the same wether it is ACK, NACK or reactive FEC. I think the common format can be as simple as plus other flags and identifiers. If we really have a huge bitmask, the question is whether it should sent as ... or i.e. separate packets. Could you explain your proposal in this simple terminology? Thanks Dah Ming From owner-rmt@listserv.lbl.gov Sun Sep 10 10:54:00 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08715 for ; Sun, 10 Sep 2000 10:54:00 -0400 (EDT) Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id GAA25770; Sun, 10 Sep 2000 06:59:50 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA25766 for ; Sun, 10 Sep 2000 06:59:48 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA17059 for ; Sun, 10 Sep 2000 06:59:47 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id GAA17056 for ; Sun, 10 Sep 2000 06:59:46 -0700 (PDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 10 Sep 2000 14:58:24 +0100 To: Brian Whetten cc: Brian Adamson , rmt@lbl.gov Subject: Re: Choices for TRACK/NACK report encoding In-reply-to: Your message of "Fri, 08 Sep 2000 10:39:30 PDT." <4.1.20000908100047.021b5eb0@mailhost.talarian.com> Date: Sun, 10 Sep 2000 14:58:22 +0100 Message-ID: <2030.968594302@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-rmt@lbl.gov Precedence: bulk In message <4.1.20000908100047.021b5eb0@mailhost.talarian.com>, Brian Whetten t yped: >>Jon, I think FEC encoded NACK bitmaps is overly complex and unecessary, but >>I'm not sure I actually understand what your proposal is. the info in the return path does not have to be 100% accurate -we can err in either direction - not giveing enough detail _can_ result in excessive retransmits (not necessariyl a big problem for aggregating/filtering routers or servers), or excessive stall/congestion back off.....giving too much detail clogs the return path.....layered fec coding the receive sequence number lists allows the aggregtion ponts to choose how to err... >> >>Brian, my initial reaction to your proposal was that it was too complex, >>but now I'm not so sure. One issue though, is that you need to pass up the >>most recent congestion information you have in each NACK. If you are not >>NACKing the most recent packets, then this has to definitely be explicitly >>reported, rather than implicitly derived at the sender. This might cause >>problems for PGMCC, for example. >> >>I think that the need to do FEC count aggregation is a good argument >>against using a single long RLE bitmap. >> >>So I think we are left with three primary design choices: >>1) How to encode each block of packets? i.e. Count, Bitmap, None (for >>list NACKs, each block is of size 1) >>2) How to encode the series of blocks? Do we assume that they are all >>sequential, or do you encode each block with its starting sequence number? >>(note that this assumes the length of each block is the same) >>3) How much history to put in each NACK? Do we just list the most >>immediate packets, or do we have some partial redundancy, or do we always >>encode the entire outstanding window? The more information we encode, the >>simpler the NACK generation algorithms become, but the harder the encoding >>algorithms in order to be able to deal with large windows. >> >>Brian >> >>At 04:10 PM 9/8/2000 +0100, Jon Crowcroft wrote: >>> >>>so we have a large range+accuracy problem in returning >>>data to the sender(s) about missing sequence numbers >>>and so if the ack return path is noisy, then lets subject >>>the problem to the same attack s we did to data in the forward >>>path >>> >>>layered FEC encoded SACK messages... >>> >>> cheers >>> >>> jon >>> >> >> cheers jon From owner-rmt@listserv.lbl.gov Tue Sep 12 08:06:35 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01000 for ; Tue, 12 Sep 2000 08:06:35 -0400 (EDT) Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id DAA01518; Tue, 12 Sep 2000 03:55:30 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA01514 for ; Tue, 12 Sep 2000 03:55:27 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA23805 for ; Tue, 12 Sep 2000 03:55:27 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id DAA23801 for ; Tue, 12 Sep 2000 03:55:26 -0700 (PDT) Received: from sonic2.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 12 Sep 2000 11:55:21 +0100 to: rmt@lbl.gov Subject: MSc report on multicast and crowded virtual spaces Date: Tue, 12 Sep 2000 11:55:20 +0100 Message-ID: <969.968756120@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-rmt@lbl.gov Precedence: bulk some relevance to some of this group: ftp://cs.ucl.ac.uk/darpa/crowded.ps.gz on mapping large crowded distributed LSVEs into multicast... part funded by sprintlabs, work by MSc student Roula Abou-Haidar on our graphics course, has a review of network support for LSVEs etc.... (warning 7M gzipped ps uncompresses to 65M due to color images) cheers jon From owner-rmt@listserv.lbl.gov Fri Sep 22 12:21:30 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19602 for ; Fri, 22 Sep 2000 12:21:30 -0400 (EDT) Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id IAA14821; Fri, 22 Sep 2000 08:18:24 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA14817 for ; Fri, 22 Sep 2000 08:18:21 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA15576 for ; Fri, 22 Sep 2000 08:18:21 -0700 (PDT) Received: from mailman.sprintlabs.com (mx.sprintlabs.com [208.30.174.2]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA15573 for ; Fri, 22 Sep 2000 08:18:20 -0700 (PDT) Received: from sprintlabs.com (ip199-2-53-110.sprintlabs.com [199.2.53.110]) by mailman.sprintlabs.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id R668PN5Y; Fri, 22 Sep 2000 08:17:50 -0700 Message-ID: <39CB77B9.5AE3FD7D@sprintlabs.com> Date: Fri, 22 Sep 2000 08:16:09 -0700 From: christophe diot Reply-To: cdiot@sprintlabs.com Organization: Sprint ATL X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Cost264@lip6.fr, rm@mash.CS.Berkeley.EDU, end2end-interest@ISI.EDU, tccc@ieee.org, itc@ieee.org, maddogs@ietf.org, ssm-interest@external.cisco.com, rmt@lbl.gov Subject: NGC 2000: call for posters Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Content-Transfer-Encoding: 7bit There will be 2 poster sessions during NGC 2000, November 8, 9, 10, in Stanford, CA. http://www.cs.ucsb.edu/ngc2000 Poster sessions are highly interactive sessions that give posters' authors an opportunity to discuss with workshop participants early research result or on-going research. The call for poster available on the NGC 2000 web site gives more details on how to submit a poster. From owner-rmt@listserv.lbl.gov Mon Sep 25 20:29:32 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18302 for ; Mon, 25 Sep 2000 20:29:31 -0400 (EDT) Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id PAA28441; Mon, 25 Sep 2000 15:17:36 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA28437 for ; Mon, 25 Sep 2000 15:17:34 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA07523 for ; Mon, 25 Sep 2000 15:17:32 -0700 (PDT) Received: from mailman.sprintlabs.com (mx.sprintlabs.com [208.30.174.2]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA07510 for ; Mon, 25 Sep 2000 15:17:31 -0700 (PDT) Received: from sprintlabs.com (ip199-2-54-230.sprintlabs.com [199.2.54.230]) by mailman.sprintlabs.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id R668PSDF; Mon, 25 Sep 2000 15:17:02 -0700 Message-ID: <39CF829E.A45A14A2@sprintlabs.com> Date: Mon, 25 Sep 2000 09:51:42 -0700 From: Christophe Diot Organization: SPRINT ATL X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Cost264@lip6.fr, rm@mash.CS.Berkeley.EDU, end2end-interest@ISI.EDU, tccc@ieee.org, itc@ieee.org, maddogs@ietf.org, ssm-interest@external.cisco.com, rmt@lbl.gov Subject: NGC 2000: posters submission extension References: <39CB77B9.5AE3FD7D@sprintlabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Content-Transfer-Encoding: 7bit Given that we have allocated a week extension to almost all poster authors, we decided to extend the poster submission deadline until until next sunday. But there will be no further extension granted :) NGC 2000 - Networked Group Communication http://www.cs.ucsb.edu/ngc2000 From owner-rmt@listserv.lbl.gov Tue Sep 26 19:13:29 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17540 for ; Tue, 26 Sep 2000 19:13:29 -0400 (EDT) Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id PAA02375; Tue, 26 Sep 2000 15:13:53 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA02370 for ; Tue, 26 Sep 2000 15:13:51 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA03438 for ; Tue, 26 Sep 2000 15:13:50 -0700 (PDT) Received: from mailman.sprintlabs.com (mx.sprintlabs.com [208.30.174.2]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA03435 for ; Tue, 26 Sep 2000 15:13:49 -0700 (PDT) Received: from sprintlabs.com (ip199-2-53-110.sprintlabs.com [199.2.53.110]) by mailman.sprintlabs.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id R668P42G; Tue, 26 Sep 2000 15:13:19 -0700 Message-ID: <39D11F0B.934908B9@sprintlabs.com> Date: Tue, 26 Sep 2000 15:11:23 -0700 From: christophe diot Reply-To: cdiot@sprintlabs.com Organization: Sprint ATL X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Cost264@lip6.fr, rm@mash.CS.Berkeley.EDU, end2end-interest@ISI.EDU, tccc@ieee.org, itc@ieee.org, maddogs@ietf.org, ssm-interest@external.cisco.com, rmt@lbl.gov Subject: NGC 2000: registration open Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Content-Transfer-Encoding: 7bit Registration in now open for NGC 2000 www.cs.ucsb.edu/ngc2000 Please notice that workshop participation is limited 100.