Subject: Re: Re ...-asym-04...

From: Mahesh Sooriyabandara <[email-masked]>
Date: Fri, 01 Jun 2001 12:44:35 +0100

John Border wrote:

>     A minor point re the latest ASYM draft...
>
>     In Section 6 and 8, the ASYM document makes a comparison to the PEP
> document which is not exactly accurate.  It says that the documents differ
> because ASYM limits itself to techniques which do not alter end to end
> semantics while implying that PEP only addresses techniques which do alter end
> to end semantics.  However, this is not accurate.  The PEP document discusses
> both kinds of techniques.  The real difference between the documents is that
> the PEP document, being only a survey document, only touches on the techniques
> and does not describe them in the detail presented in the ASYM document...

Dr G Fairhurst wrote:

> Thanks John, Mahesh raised this at the end of the last edit, but
> we couldn't quite see how to change the text.  Could you and others
> on the list help?
>
> The PEP draft says a PEP is:
>
> "An entity in the network acting on behalf of an end system or user
> (with or without the knowledge of the end system or user) in order
> to enhance protocol performance."
>
> It does say that ACK manipulation is a PEP measure, to a certain
> extent it is true, but not entirely.

In ASYM, the ACK manipulation involves, queuing packets, dropping packets
and scheduling packets - these are normal network operations.
To do this efficiently requires looking at TCP headers.

> I do not dispute it is USEFUL for PEP to describe these schemes - it is useful,

> I would like to try and be clear that the ASYM schemes are very different
> to split TCP / TCP snooping / Application proxies etc.
> The ASYM schemes are either (i) TCP modifications or are (ii) network
> forwarding changes - there is no intention to act "on behalf"
> of an end system. John, can you advise on some good wording which
> helps the reader understand and is consistent with PEP.

As a starter I suggest the following for Section 6:

 "The techniques proposed in this document do not seek to modify
the end to end semantics of the TCP packets exchanged between hosts.
They therefore do not inspect/modify any TCP or UDP payload data.
They also do not modify the port numbers or addresses of packets.
Many of the risks associated with other protocol enhancing measures
(e.g.  local retransmissions, local  acknowledgements,  split TCP) do not
exist for such schemes.

A more detailed description of the issues in providing network protocol
enhancement is described in [PEP-ID] which also compares the various
approaches."

and an abbreviated version at the end of the document.

Gorry & Mahesh.

---

From: John Border <[email-masked]>
Date: Fri, 01 Jun 2001 11:07:27 -0400

Works for me...