headers
John Border | 2 Aug 2004 05:31

Re: interoperability issue with TCP PEP


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.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Lakshmi Priya | 2 Aug 2004 06:59

RE: interoperability issue with TCP PEP

Keith and John thanks for the response.

The SCPS-TP as mentioned would surely help in having a interoperable
transport protocol over satellite.
But yet it does not suggest any ways to interoperate PEP i.e. the means of
informing the other PEP node (in a split connection)of the end host session
information which has been spoofed. Hope the DVB-RCS standard would help
clarify on these aspects.

regards,
Lakshmi Priya

-----Original Message-----
From: pilc-bounces <at> ietf.org [mailto:pilc-bounces <at> ietf.org]On Behalf Of
Keith L. Scott
Sent: Wednesday, 28 July 2004 9:14 PM
To: lakshmips <at> future.futsoft.com; pilc <at> ietf.org
Cc: sis-scps-interest <at> mailman.ccsds.org
Subject: RE: [pilc] interoperability issue with TCP PEP

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lakshmi Priya | 3 Aug 2004 07:46

RE: interoperability issue with TCP PEP

hi,
   Thanks, Eric.

Guess I was not very clear with my question.
Consider the scenario below:

H1-P1 -> terrestial link
P1--P2 -> satellite link
H2-P2 -> terrestial link

End host	PEP node	PEP node	End host

H1 ----------P1------------P2----------H2

In a split PEP connection there would be 3 TCP connections (between the
nodes).
If PEP is transparent to end user the session properties (atleast the 4
tuples H1,H2,srcport1,dstport1)
should be the same for the TCP sessions between H1-P1 and P2-H2.Both these
sessions would ideally be spoofed with session tuples -
H1,H2,srcport1,dstport1 as expected by end users H1 and H2. This can be done
in many ways, since there is no specification. The information of the
session just needs to be passed from P1 to P2.

Eric, as per your reply
>> It seems that an ideally constructed transport proxy would leave all the
relevant information (obviously port numbers, but also bidirectional
sequence
space, urgent pointers, I suppose the Push flag and any IP header service
markings) undisturbed.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gorry Fairhurst | 5 Aug 2004 00:42
Picon
Picon

Re: 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 <at> 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...
(Continue reading)

Permalink | Reply | 0 comments |

Gmane