[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pilc] interoperability issue with TCP PEP

To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Subject: Re: [pilc] interoperability issue with TCP PEP
From: Harald Skinnemoen <harald.skinnemoen@nera.no>
Date: Thu, 5 Aug 2004 10:34:24 +0200
Cc: ip-dvb@erg.abdn.ac.uk, ipdvb@erg.abdn.ac.uk, lakshmips@future.futsoft.com, pilc@ietf.org, pilc-bounces@ietf.org, sis-scps-interest@mailman.ccsds.org
In-reply-to: <>
Reply-to: ipdvb@erg.abdn.ac.uk
Sender: owner-ipdvb@erg.abdn.ac.uk

To follow up Gorry's request (Nera is a Satlabs member), the last SATLABS meeting came up with the the following topics to standardise to come to interoperability:

- The basic SCPS-TP Messages and their options

- Basic TCP State Machines

- Minimal receiver behavior

- Inter-working between TCP and SCPS-TP

Plans are to start implementation and freeze the short term spec in November 2004.

/harald

Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Sent by: pilc-bounces@ietf.org

05.08.2004 00:42

To	<ipdvb@erg.abdn.ac.uk>, <lakshmips@future.futsoft.com>
cc	sis-scps-interest@mailman.ccsds.org, ip-dvb@erg.abdn.ac.uk, pilc@ietf.org
Subject	Re: [pilc] interoperability issue with TCP PEP

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/

References:
- Re: [pilc] interoperability issue with TCP PEP
  - From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>

Prev by Date: Re: [pilc] interoperability issue with TCP PEP
Next by Date: Joel Grotz is out of office.
Previous by thread: Re: [pilc] interoperability issue with TCP PEP
Next by thread: Status of ULE IMPLEMENTATIONS - July 2004
Index(es):
- Date
- Thread