Re: [pilc] interoperability issue with TCP PEP
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Wed, 04 August 2004 23:11 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 TAA18060 for <pilc-archive@lists.ietf.org>; Wed, 4 Aug 2004 19:11:13 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsUrC-0005ln-Bu; Wed, 04 Aug 2004 19:07:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsUjS-0004bE-Tr for pilc@megatron.ietf.org; Wed, 04 Aug 2004 18:59:41 -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 SAA17500 for <pilc@ietf.org>; Wed, 4 Aug 2004 18:59:35 -0400 (EDT)
Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsUmp-00027r-QE for pilc@ietf.org; Wed, 04 Aug 2004 19:03:08 -0400
Received: from [130.129.129.23] (opene-130-129-129-23.ietf60.ietf.org [130.129.129.23]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i74Mgl1G019688 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Wed, 4 Aug 2004 23:42:52 +0100 (BST)
User-Agent: Microsoft-Entourage/11.0.0.040405
Date: Wed, 04 Aug 2004 15:42:43 -0700
Subject: Re: [pilc] interoperability issue with TCP PEP
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
To: ipdvb@erg.abdn.ac.uk, lakshmips@future.futsoft.com
Message-ID: <BD36B473.D47%gorry@erg.abdn.ac.uk>
In-Reply-To: <410DB583.9090004@hns.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-ERG-MailScanner: Found to be clean
X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk
X-ERG-MailScanner-To: ip-dvb@erg.abdn.ac.uk, ipdvb@erg.abdn.ac.uk, lakshmips@future.futsoft.com, pilc@ietf.org, sis-scps-interest@mailman.ccsds.org
X-Spam-Score: 0.2 (/)
X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57
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
My take on this was the general story is that there have been a series of meetings organised to understand the issues in producing inter-operable PEPs, and the related issues of where NAT, IPSEC, etc are used and their relation to DVB-RCS network scenarios. SatLabs are considering a phased approach, looking for a short-term solution providing basic PEP functions appropriate to some scenarios for DVB-RCS (focussed on web browsing). They may also consider a more complete and powerful long-term solution. Initial effort will probably be focussed on the short term, looking at: - TCP with a split to a modified TCP transport layer (SCPS?) - a very light session layer if required to configure the two end points - optional web pre-fetching mechanisms in the application layer I believe the result of their last meeting was that this work is to progress in the months ahead. Perhaps a member of Satlabs can give a more authorative status report? Gorry (speaking on behalf of no-one in particular) ----------- On 1/8/04 8:31 pm, "John Border" <border@hns.com> wrote: > > 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/ >> >> > Looks good to me. I would add an "optional" before the "web prefetching". I am not sure how much to say on timing or actual outcome. Cheers, Joerg Gorry Fairhurst wrote: > See if you like this - or not, and I'll post it. > > Gorry > > ------ > > My take on this was the general story is that there have been a series of > meetings organised to understand the issues in producing inter-operable > PEPs, and the related issues of where NAT, IPSEC, etc are used and their > relation to DVB-RCS network scenarios. > > SatLabs are considering a phased approach, looking for a short-term solution > providing basic PEP functions appropriate to some scenarios for DVB-RCS > (focussed on web browsing). They may also consider a more complete and > powerful long-term solution. Initial effort will probably be focussed on the > short term, looking at: > > - TCP with a split to a modified TCP transport layer (SCPS?) > - a very light session layer if required to configure the two end points > - web pre-fetching mechanisms in the application layer > > I believe the result of their last meeting was that this work is to progress > in the months ahead. > > Perhaps a member of Satlabs can give a more authorative status report? > > Gorry > (speaking on behalf of no-one in particular) > > On 1/8/04 8:31 pm, "John Border" <border@hns.com> wrote: > > >>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