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

_______________________________________________
pilc mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/