Re: [pilc] interoperability issue with TCP PEP
John Border <border@hns.com> Mon, 02 August 2004 03:43 UTC
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26047 for <pilc-archive@lists.ietf.org>; Sun, 1 Aug 2004 23:43:24 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrTda-0006Fw-1y; Sun, 01 Aug 2004 23:37:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrTYu-0003ou-3j for pilc@megatron.ietf.org; Sun, 01 Aug 2004 23:32:34 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25511 for <pilc@ietf.org>; Sun, 1 Aug 2004 23:32:29 -0400 (EDT)
Received: from hnse2.hns.com ([208.236.67.201]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrTbd-00066O-Ap for pilc@ietf.org; Sun, 01 Aug 2004 23:35:24 -0400
Received: from excore8.hns.com (excore8.hns.com [139.85.52.126]) by hnse2.hns.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id i723VV3C028436 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 1 Aug 2004 23:31:31 -0400 (EDT)
Received: from hns.com (rasnvpn53.hns.com [139.85.221.136]) by excore8.hns.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id i723VGQg004345; Sun, 1 Aug 2004 23:31:19 -0400 (EDT)
Message-ID: <410DB583.9090004@hns.com>
Date: Sun, 01 Aug 2004 23:31:15 -0400
From: John Border <border@hns.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: lakshmips@future.futsoft.com
Subject: Re: [pilc] interoperability issue with TCP PEP
References: <0I1K00FKJJPZTK@mailsrv2a.mitre.org>
In-Reply-To: <0I1K00FKJJPZTK@mailsrv2a.mitre.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Filtered: Sendmail Attachment Filter v2.6.0 hnse2.hns.com i723VV3C028436
X-AntiVirus: Sendmail Anti-Virus Filter hnse2.hns.com 4.3.20 4382 i723VV3C028436
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8
Content-Transfer-Encoding: 7bit
Cc: sis-scps-interest@mailman.ccsds.org, ip-dvb@erg.abdn.ac.uk, pilc@ietf.org
X-BeenThere: pilc@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Performance Implications of Link Characteristics IETF Working Group <pilc.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pilc>, <mailto:pilc-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:pilc@ietf.org>
List-Help: <mailto:pilc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pilc>, <mailto:pilc-request@ietf.org?subject=subscribe>
Sender: pilc-bounces@ietf.org
Errors-To: pilc-bounces@ietf.org
Content-Transfer-Encoding: 7bit
DVB-RCS, via SatLabs, is currently looking into standardizing a minimum interoperable PEP. Not sure of the current status of the effort... Keith L. Scott wrote: >Lakshmi, > >It is entirely possible for PEPs made by different vendors to interoperate, >provided the vendors implement a common standard; and yes, there _is_ a >standard for how the information is carried across the satellite link. > >The Space Communications Protocol Standards: Transport Protocol (SCPS-TP, >also sometimes referred to as TCP tranquility) defines a set of TCP options >that can improve TCP performance in stressed environments, including >satellite communications. PEP products that implement these options are >available from a number of vendors, and should interoperate if they all >conform to the specification. There is also a freely available reference >implementation of the SCPS protocols that includes a PEP application that is >available by sending mail to the point of contact listed at >http://www.scps.org. > >Tranquility is completely backward-compatible with other TCP >implementations; all of the Tranquility-specific functionality is negotiated >during the SYN exchange. By using different settings for the terrestrial >and satcom sides of the PEPs, they can dramatically improve performance over >the satcom link. There is currently no implementation that I know of that >does private, out-of-band signaling between the PEPs, though I can envision >uses for such signaling. > >I'd be happy to answer any other questions you have or to point you at some >vendors. > >The SCPS-TP protocol spec is available from >http://www.ccsds.org/CCSDS/documents/714x0b1.pdf > >Best regards, > > --keith > > > > > > >>-----Original Message----- >>From: pilc-bounces@ietf.org [mailto:pilc-bounces@ietf.org] On >>Behalf Of Lakshmi Priya >>Sent: Wednesday, July 28, 2004 7:42 AM >>To: pilc@ietf.org >>Subject: [pilc] interoperability issue with TCP PEP >> >> >>hi, >> >> Would it be possible to implement PEP such that it is >>interoperable >>with other PEP implementations? >>That is, in a split connection, is it possible to have 2 >>different vendor >>implementations running on either end of satellite link PEP >>nodes? Are there >>any such implementations? >> >> Since there are no standards to the way in which the end host >>information is carried over the satlink after spoofing, I >>guess this would >>not be possible. There could also exist many other proprietary control >>packets. Any inputs in this regard is welcome. >> >>thanks and regards, >>Lakshmi Priya >> >> >> >>*************************************************************** >>************ >>This message is proprietary to Future Software Limited (FSL) >>and is intended solely for the use of the individual to whom it >>is addressed. It may contain privileged or confidential information >>and should not be circulated or used for any purpose other than for >>what it is intended. >> >>If you have received this message in error, please notify the >>originator immediately. If you are not the intended recipient, >>you are notified that you are strictly prohibited from using, >>copying, altering, or disclosing the contents of this message. >>FSL accepts no responsibility for loss or damage arising from >>the use of the information transmitted by this email including >>damage from virus. >>*************************************************************** >>************ >> >> >>_______________________________________________ >>pilc mailing list >>pilc@ietf.org >>https://www1.ietf.org/mailman/listinfo/pilc >>http://www.ietf.org/html.charters/pilc-charter.html >>http://pilc.grc.nasa.gov/ >> >> >> > > >_______________________________________________ >pilc mailing list >pilc@ietf.org >https://www1.ietf.org/mailman/listinfo/pilc >http://www.ietf.org/html.charters/pilc-charter.html >http://pilc.grc.nasa.gov/ > > _______________________________________________ pilc mailing list pilc@ietf.org https://www1.ietf.org/mailman/listinfo/pilc http://www.ietf.org/html.charters/pilc-charter.html http://pilc.grc.nasa.gov/
- [pilc] tcppep Lakshmi Priya
- Re: [pilc] tcppep John Border
- RE: [pilc] tcppep Lakshmi Priya
- Re: [pilc] tcppep Joe Touch
- [pilc] interoperability issue with TCP PEP Lakshmi Priya
- RE: [pilc] interoperability issue with TCP PEP Keith L. Scott
- Re: [pilc] interoperability issue with TCP PEP John Border
- RE: [pilc] interoperability issue with TCP PEP Lakshmi Priya
- Re: [pilc] interoperability issue with TCP PEP Gorry Fairhurst