Subject: [Tsvwg] Placement "outside of" TCP

From: Caitlin Bestler <[email-masked]>
Date: Wed, 18 Dec 2002 11:57:29 -0600

Joe Touch wrote:
> > 
> > An optimal interface supporting MPA will make validated TCP
> > segments available for *placement* to MPA out-of-order, but
> > it does not *deliver* them early. The data is not
> > "available".
> 
> If the data exits TCP, it is delivered. If it is delivered out of order, 
> it is a violation of the spec.
> 
> > This is merely co-operative buffer management -- something
> > already done in existing stacks.
> 
> Inside the stack, yes. But not between TCP and something outside TCP.
> 

When I worked on Cable TV systems I designed conditional access modules that
actually had their code and working data entirely within a single chip. The
data being decrypted, and especially the keys, never ever left the sealed
chip.

For an implementation like that, you can meaningfully talk about something
not being "outside" the subsystem. The subsystem literally had physical
boundaries.

I've never seen a TCP stack implemeneted as a seal sub-component however.
Most of them run as one piece of code on a processor under supervision of a
kernel or even a full Operating System. The processor has a memory subsystem.
The TCP software may think it controls that buffer, but it in fact does not
know that the OS has not authorized some debugger to access those buffers,
or for that matter that some emulator might access that memory without the
processor even knowing about it.

Even without debugging the meaning of that memory location is actually a
complex issue that is totally invisible to the TCP software. How is the
virtual address translated to a physical address. Which chip is that physical
address stored in? Is that addressed cached? In multi-processor systems, in
*which* cache? Are the bytes stored in adjacent locations, or is there an
interleaving factor? Is calculating a parity bit (or even worse an error
correcting code) constitute the memory system an illegal examination of TCP's
data? TCP is byte oriented, is it legal to use 64-bit wide memory?

What really matters is that the TCP stack has assurance that it has the sole
right to update that buffer. And that it has not authorized anyone else to
process that buffers contents.

All of which is true for DDP/MPA/TCP.

The only difference is how and where TCP stores the data before delivery.
Placement allows the TCP stack to tell its ULP "you store this", rather than
telling the memory subsystem to do it.

In neither case does TCP have any means of enforcing this rule. But it is not
responsible for the results if the other side cheats. I doubt you could find
any TCP stack robust enough to withstand a debugger altering in-process buffers.

Are you suggesting that TCP semantics *demands* a conventional memory
architecture? If the implementation uses a CAM (Content Addressed Memory)
to identify the connection, would that violate TCP semantics?

Placement is not delivery. It merely relieves the TCP stack from having to
provide its own buffering. Just as with the memory system, it is performing a
service *for* TCP. TCP has not yielded control of this datal Nothing has been
made available to anyone.

An interesting real-world analogy: New CDs are made available for distribution
every Tuesday. These CDs were not magically shipped from the distributor's
warehouse to eveyr music shop in the  world at midnight. They are physically
there before they are available. They refuse to implement an inefficient
physical distribution system just so no copy of the CD is in the physical
possession of a store "early".

If not delivering the CDs before their release date meant they could not be
in the retail store itself (i.e. "outside of the distributor") the cost of
distributing CDs would go up and/or they would not be available to the end
consumers as early.

Ultimately, DDP is doing the same thing. It is placing data optimally in
prepration for later official delivery. But it does not change that the sender
still controls when the contents are legally available.

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Joe Touch <[email-masked]>
Date: Wed, 18 Dec 2002 10:14:17 -0800

> processor even knowing about it.

That's the whole point of an OS.

Debuggers either run outside the OS (and thus can't get at data), or 
you're debugging the kernel itself.

> data? TCP is byte oriented, is it legal to use 64-bit wide memory?

Please review an OS text on this matter.

...
> architecture?

No - but implementation inside an OS presumes that there is an OS and 
that protection is enforced therein, e.g., in the VM system. VM systems 
handle this just fine, as others have pointed out.

...
> made available to anyone.

Whether or not an OS component can snoop (it can snoop anything, if it 
wants), TCP must tag the data as non-delivered to the next layer up. If 
that layer is in userspace, then TCP wouldn't have released it, and the 
user process would not have access to it.

...
> still controls when the contents are legally available.

TCP says that it doesn't release data - for ANY purpose - until ACKd, 
and doesn't ACK data until preceeding data bas been received. Changing 
that changes TCP.

If you can ensure that this TCP' variant runs
	a) ONLY under DDP
	b) never without DDP
then what you have is a new protocol - "TCP'-DDP", which clearly is not TCP.

Joe