From Paul.Szuch at gdcanada.com Tue Oct 10 15:04:37 2006 From: Paul.Szuch at gdcanada.com (Szuch, Paul) Date: Tue Oct 10 15:13:49 2006 Subject: [Sis-SCPS-INTEREST] Error in SCPS documentation. Message-ID: <6D5FB6745F80EC45986ACD47D70799AD02453B32@CGYSVW100.gdcan.com> I notice in GW_config.pdf the CC options are 0=rate,1=Vegas,2=standard, but looking at the code 2=Vegas,1=standard. I'm not sure if this error exists elsewhere or not. ---------------------------------------- LCSS, OS & Tools Ex 5497 The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ccsds.org/pipermail/sis-scps-interest/attachments/20061010/fb508fea/attachment.html From cianm at klasonline.com Fri Oct 13 08:10:23 2006 From: cianm at klasonline.com (Cian Masterson) Date: Fri Oct 13 10:26:42 2006 Subject: [Sis-SCPS-INTEREST] SCPS + WAN Compression - rtt fluctuations throwing diff off. Message-ID: <452F822F.6050305@klasonline.com> Hi, I am working with Frank Lynam on getting SCPS working with Compression on the WAN side over satellite links (original post is here: http://tinyurl.com/f8lzy). The problem we are experiencing, as Eric suggested here: http://tinyurl.com/hgxka, is that the variations in compression rate means that SCPS sees the bandwidth dramatically increase and decrease in a very short space of time. Examining the variables used for the calculation of the diff I can see that: * cwinsegs climbs slowly and then plateaus * once cwinsegs stabilises s->rttcur continues to fluctuate (by as much as 1 second betwen samples). * This means that diff might be hovering about 7/8/9 and then will suddenly rocket to 45/50/55, hover around there for a while, then drop back to 9/10/11 again. What I understand to be happening is that s->snd_prevcwnd, which cwinsegs is calculated from, is measuring uncompressed data but s->rttcur is fluctuating based on the actual data on the line. Since fluctuations in diff are very large as a result Vegas never gets the chance to settle - the "damping" effect of the algorithm never kicks in. Does this seem like an accurate explanation of events? I have implemented Eric's "double accounting" suggestion, and now the calculations for current_credit, s->cwnd, s->awnd, s->sndwin and friends in tp_newSend and tp_iovCoalesce are done using the stored estimate of compressed data size. This does not appear to have any effect on s->snd_prevcwnd unfortunately, so hence does not seem to have any effect on the diff calculation. What I think I need to do is change s->snd_prevcwnd to somehow measure data in terms of how much compressed data was sent last time, so that the value of s->snd_prevcwnd and s->rttcur will correlate. Is that possible (or intelligent)? From my reading of tp_TFVegas s->snd_prevcwnd seems to either double, increase by s->max_data or decrease by s->maxdata, and does not get feedback of how many bytes have been sent. My current theory is that I need to maintain a count of how many compressed bytes have been sent during a period of s->rttcur, and subtract that from s->snd_prevcwnd before the diff calcuations are done. Does this seem reasonable or am I totally on the wrong track? Would appreciate any input anyone has to give. Thanks! Slan, Cian From robbiehwang at yahoo.com.cn Tue Oct 17 07:15:59 2006 From: robbiehwang at yahoo.com.cn (=?gb2312?q?=BB=C6=D5=B9?=) Date: Tue Oct 17 09:03:14 2006 Subject: [Sis-SCPS-INTEREST] The future of some SCPS protocols (SP NP FP) Message-ID: <20061017111559.15418.qmail@web15305.mail.cnb.yahoo.com> These protocols were approved as CCSDS recommendations over seven years ago. Have they been reviewed by CCSDS yet? I was alse wandering if there were mature products based on these SCPS protocol(expect TP). Regards, Robbie Hwang. --------------------------------- ÇÀ×¢ÑÅ»¢Ãâ·ÑÓÊÏä-3.5GÈÝÁ¿£¬20M¸½¼þ£¡ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ccsds.org/pipermail/sis-scps-interest/attachments/20061017/83fae6fc/attachment.htm From adrian.j.hooke at jpl.nasa.gov Wed Oct 18 17:12:25 2006 From: adrian.j.hooke at jpl.nasa.gov (Adrian J. Hooke) Date: Wed Oct 18 17:21:50 2006 Subject: [Sis-SCPS-INTEREST] The future of some SCPS protocols (SP NP FP) In-Reply-To: <20061017111559.15418.qmail@web15305.mail.cnb.yahoo.com> References: <20061017111559.15418.qmail@web15305.mail.cnb.yahoo.com> Message-ID: <6.2.1.2.2.20061018134058.06d82960@mail.jpl.nasa.gov> At 04:15 AM 10/17/2006, Robbie Hwang wrote: >These protocols were approved as CCSDS recommendations over seven years ago. Also, BTW, by ISO: http://www.iso.org/iso/en/CatalogueListPage.CatalogueList?COMMID=738 >Have they been reviewed by CCSDS yet? The SCPS Transport Protocol is currently being updated via the "Pink Sheet" process. See: http://public.ccsds.org/review/default.aspx Some Pink Sheets are currently being prepared to make some small technical updates to the SCPS Network Protocol. The SCPS Security Protocol and the SCPS File Protocol will shortly be submitted for reconfirmation without change. Comments on any of these documents should be addressed to the mailing list: http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi >I was alse wandering if there were mature products based on these SCPS >protocol(expect TP). See: http://www.scps.org/html/related_links.html Best regards Adrian Hooke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ccsds.org/pipermail/sis-scps-interest/attachments/20061018/c1f686da/attachment.html