headers
Lakshmi Priya | 3 Mar 2004 05:31

tcppep

hi,

RFC3135 for PEP states that "In a split connection we can encapsulate
the tcp packets over satlink. These tcp packets are decapsulated at
the other end of the satlink and transmitted to the end host."

Will it be necessary to encapsulate the entire packet along with the TCP and
IP headers to maintain end to end semantics?
In such a case wouldnt it be an overhead to manupulate the send buffers on
the satellite tcp as segments(since we retain the headers) rather than
bytes.
Any documents suggesting techniques for pep encapsulation?

thanks,
lp

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

Permalink | Reply | 8 comments |
headers
John Border | 3 Mar 2004 19:47

Re: tcppep


A purist would say that even encapsulating the original header alters the end
to end semantics.  Even most non-purists would agree that changing the
original header alters the end to end semantics.  I happen to agree with the
purists.  So,...

I think the question should be does it alter any of the end to end semantics
that matter?  And, the answer to that question depends on context.  In many
environments, I think it doesn't matter.  In our case, we are very up front
with our customers re the fact that we "spoof" TCP connections when carrying
them across the satellite link...

I am unaware of any public documents other than RFC 3135 and marketing
literature from various companies.  But, that doesn't mean it doesn't exist...

John

Lakshmi Priya wrote:
> 
> hi,
> 
> RFC3135 for PEP states that "In a split connection we can encapsulate
> the tcp packets over satlink. These tcp packets are decapsulated at
> the other end of the satlink and transmitted to the end host."
> 
> Will it be necessary to encapsulate the entire packet along with the TCP and
> IP headers to maintain end to end semantics?
> In such a case wouldnt it be an overhead to manupulate the send buffers on
> the satellite tcp as segments(since we retain the headers) rather than
> bytes.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Lakshmi Priya | 4 Mar 2004 05:44

RE: tcppep

Thanks John,
  Yes, in either case end to end semantics would be lost. Because, though we
encapsulate the
headers, they would need to be modified at the TCP session on the other end
of satlink,to suit its tcp window, options etc.
May be we can do away with the overhead of constructing new headers in this
case.

But I think it is mandatory to pass at least the host IP address information
(source) for end to end semantics.
Or do some implemetations just pass the payload? Anything else mandatorily
required?

But again the following doubts do remain.

1. Wouldnt it be complicated to manupulate the send buffers on PEP nodes,
 as segments(since we retain the IP, TCP headers of end host for
encapsulating).
 Its no longer as simple as handling buffers as byte stream from
application.
Packets need to be sent as whole segments to other end of satlink.

2. The entire TCP stack has to be traversed at the PEP nodes, for flow and
congestion control, for both terrestial and satlink causing performance
overhead.Can this be avoided?

Any clarification would be helpful.

lp
(Continue reading)

Permalink | Reply | 5 comments |
headers
Joe Touch | 5 Mar 2004 07:14
Picon
Favicon

Re: tcppep


John Border wrote:

> A purist would say that even encapsulating the original header alters the end
> to end semantics.  Even most non-purists would agree that changing the
> original header alters the end to end semantics.  I happen to agree with the
> purists.  So,...

FWIW, let's me clear about what 'changing E2E semantics' means:

ALL PEP'd transactions fall to the lowest KNOWN service
	i.e., it's not good enough to say "hey, the FTP finished,
	so the file I got is what was on the other end"

	ALL. Let me repeat - ALL - TCP connections must be assumed
	to have corrupted data. There's no way to know if they don't
	from just the TCP connection semantics.

ACK doesn't mean the data is at the recipient.

FIN-ACK doesn't mean all the data got there.

CLOSE doesn't mean the transfer is either complete or correct.

---

It's not encapsulating the header that's the issue - it's modifying it, 
and sending spoof'd ACKs back.

If what you really want is to do something that the endpoint knows
(Continue reading)

Permalink | Reply | 0 comments |

Gmane