Subject: RE: [pilc] interoperability issue with TCP PEP

From: "Lakshmi Priya" <[email-masked]>
Date: Tue, 3 Aug 2004 11:16:53 +0530

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.

      It means the P1-P2 session should also retain the same properties as
the end host sessions. This is one of the methods of passing the
information. But this is not standardised. One could use a totally new set
of properties over P1-P2, may be even a different protocol, and yet pass on
the session information from P1 to P2 for the terrestial sessions using any
other control packet.

In this aspect, if P1 and P2 are 2 different implementations, I foresee an
interoperability issue.
Please correct me if I am wrong.

regards,
Lakshmi

-----Original Message-----
From: Eric Travis [mailto:[email-masked]]
Sent: Monday, 2 August 2004 10:07 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [pilc] interoperability issue with TCP PEP

Lakshmi,

This is interesting:

>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.
>
>
What sort of information do you have in mind, and in what manner would
the other node make use of this information?

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.

While an intermediate proxy may very well [need to] resegment the data
in the
flow,  this would be transparent to the ultimate end-system anyway it
isn't clear
if this activity needs to be conveyed to the peer-proxy.

Is there some other information that you had in mind?

Eric

***************************************************************************
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/

---

From: "Lakshmi Priya" <[email-masked]>
Date: Mon, 2 Aug 2004 10:29:23 +0530

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: [email-masked] [mailto:[email-masked]]On Behalf Of
Keith L. Scott
Sent: Wednesday, 28 July 2004 9:14 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
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
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

>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Lakshmi Priya
>Sent: Wednesday, July 28, 2004 7:42 AM
>To: [email-masked]
>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
>
>
>

_______________________________________________
Sis-SCPS-INTEREST mailing list
[email-masked]
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-scps-interest

---

From: "Lakshmi Priya" <[email-masked]>
Date: Tue, 3 Aug 2004 11:16:53 +0530

hi,
   Thanks, Eric.

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

Eric, as per your reply

regards,
Lakshmi

-----Original Message-----
From: Eric Travis [mailto:[email-masked]]
Sent: Monday, 2 August 2004 10:07 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [pilc] interoperability issue with TCP PEP

Lakshmi,

Eric