Subject: PILC ASYM-04: Finding some correct wording for PEP/ASYM

From: Dr G Fairhurst <[email-masked]>
Date: Fri, 01 Jun 2001 12:55:47 +0100

Could you and others on the PILC list help?

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...

Thanks John, Mahesh raised this at the end of the last edit, but
we couldn't quite see how to change the text.  The two of us
had a meeting today to discuss this and came up with the starting
text at the bottom of this email.

-------------------------

The problem, as we see it:

The PEP draft defines a PEP as:

"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. I do not dispute that it is
USEFUL for PEP to describe these schemes - it IS useful.

I would like to be clear that the ASYM schemes are very different
to split TCP / TCP snooping / Application proxies etc:

In ASYM, the ACK manipulation involves, queuing packets, dropping packets
and scheduling packets - these are normal network operations (e.g. a routing
doing, e.g.  diffserv, may do all these).

For ASYM modifications to work efficiently requires looking at TCP headers.
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. 

---
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:

PLEASE DO SUGGEST CHANGES or alternate text!

"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."

We could include an abbreviated version at the end of the document.

-----

gorry

------------------------------
http://www.erg.abdn.ac.uk/users/gorry 
------------------------------
http://www.erg.abdn.ac.uk/users/gorry

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 1 Jun 2001 16:30:26 +0100 (BST)

> to enhance protocol performance."

should be _existing_ (or known) protocol performance. Any incremental
modifications to the protocol or changes in its patterns of use can
severely break the operating assumptions of the entity.

local optimisations really -are- local. In time and and in space.

> doing, e.g.  diffserv, may do all these).

The ACK reconstruction/compaction/companding described in ASYM aren't
normal router operations, though.

> For ASYM modifications to work efficiently requires looking at TCP headers.

depends on how you define efficency. Router CPU/throughput efficiency
this isn't...

> The ASYM schemes are either (i) TCP modifications 

yet still described as 'transparent'...

> or are (ii) network

yet in assuming a degree of responsibility for state seen by the other
end system and slightly altering that state, that is _exactly_ what
they're doing.

> They therefore do not inspect/modify any TCP or UDP payload data.

I believe that header inspection for ACK bits qualifies as such,
negating this. And the semantics are being modified, albeit to a very
limited extent; there's some impact on congestion control expectations
etc.

> which also compares the various approaches."

that much is fine.

cheers,

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Dr G Fairhurst <[email-masked]>
Date: Fri, 01 Jun 2001 17:28:44 +0100

Looking at the proposed text:

> negating this. 

Lloyd, surely the ACK bits are in the TCP header, not payload.

> And the semantics are being modified, albeit to a very

I don't see an intended change to the meaning or significance of the 
TCP header. Can you elaborate?

--

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 1 Jun 2001 19:04:04 +0100 (BST)

> Lloyd, surely the ACK bits are in the TCP header, not payload.

TCP _is_ the packet payload, header and all.

> TCP header. Can you elaborate?

regenerating acks changes the congestion behaviour of the sender. That
_is_ a change in semantics imo. The meaning may be implicit in the
flow, but it's still meaning.

L.

---

From: Joe Touch <[email-masked]>
Date: Fri, 01 Jun 2001 13:21:28 -0700

> text at the bottom of this email.

I thought, as above, that PEP was the general concept that includes
techniques at all levels, and that the ASYM uses specific 
techniques that can be classified in the general PEP taxonomy.

The rest is splitting hairs.

> forwarding changes - there is no intention to act "on behalf"

But the intent is to increase performance. The end-system's
performance. That's exactly "on behalf" of the end system.

> the end to end semantics of the TCP packets exchanged between hosts.

That depends on semantics - is it the in-band data, or does this
include the metadata (congestion window, etc.)? The next sentence
hints at the former, but it isn't so clear whether this is modifying
the semantics of TCP protocol, or the semantics of the service the 
protocol provides.

> exist for such schemes.

I believe the distinction here is not as useful as it appears.
Even the allegedly benign replication of packets can cause
detrimental effects (see Savage's work at Univ. Wash.) There
are risks in any system that correlates its function or behavior
with the behavior of the endpoints - including the endpoints'
emission of packets.

Joe