Subject: RE: [Tsvwg] TCP ULP Framing: PUSH bit alternative

From: [email-masked]
Date: Sat, 25 Aug 2001 17:38:28 -0400

Jacob,

The following text from RFC 1122, Section 4.2.2.2 is at odds
with the notion of using the PSH bit for framing:

    The PSH bit is not a record marker and is independent of
    segment boundaries.  The transmitter SHOULD collapse
    successive PSH bits when it packetizes data, to send the
    largest possible segment.

There was also a serious effort to use the URG bit and pointer
for a similar purpose leading to an IESG statement that such use
of the URG bit and pointer was unacceptable.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

> -----Original Message-----
> From: Jacob Heitz [mailto:[email-masked]]
> Sent: Saturday, August 25, 2001 3:37 PM
> To: [email-masked]
> Subject: [Tsvwg] TCP ULP Framing: PUSH bit alternative
> 
> 
> I have a simple alternative that requires no additional headers.
> I'm sure it must have already been thought of, but rejected.
> If so, I'd like to know why it was rejected.
> 
> Modify the sending TCP to send one ULP PDU in one IP packet,
> ie, a one to one correspondence between ULP PDU and IP packet.
> Do this for retransmissions as well as transmissions. 
> TCP needs this modification for either proposal.
> 
> Modify the receiving TCP to pass data up to the ULP as PDUs
> corresponding to received IP packets.
> TCP needs this modification for either proposal.
> 
> If a PDU to be sent exceeds the maximum segment size, the
> sending TCP would segment it into the required number of
> segments and set the PUSH bit on only the last segment.
> This way, the receiver can reassemble them.
> 
> I make no proposal for bundling short ULP PDUs together into
> a single TCP segment.
> 
> -- 
> // Jacob Heitz. Tel:510-747-2917
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/tsvwg
> 

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

---

From: Jacob Heitz <[email-masked]>
Date: Sat, 25 Aug 2001 15:11:04 -0700

>     largest possible segment.

Then why not change it to say that it IS a record marker
for when framing aware TCP is being used ?

My understanding is that the intention of the push bit is
to avoid unnecessary wakeup calls to the receiving application 
process. With framing aware TCP, the receiving application
will get exactly one wakeup per user record, PSH or no PSH.

---

From: Joe Touch <[email-masked]>
Date: Sat, 25 Aug 2001 23:07:23 -0700

> for when framing aware TCP is being used ?

Exactly. Once you've negotiated that framing aware TCP 
is being used, you're not using TCP, so you're free
to redefine things.

At that point, however, why confuse the issue by reusing and
redefining so many bits of an existing protocol, rather
than just calling it another one?

Joe

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 26 Aug 2001 01:44:05 -0500

Joe,

> than just calling it another one?

One closely related bit doesn't sound like so many.  Rather than
viewing it as negotiating a whole new protocol, should it not be
viewed as negotiating just another option of TCP?

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Joe Touch <[email-masked]>
Date: Sun, 26 Aug 2001 10:49:26 -0700

> viewed as negotiating just another option of TCP?

So far this changes the API, the rules for ACKing and retransmitting
(must be a packet boundary - current TCP is permitted to retransmit
aligned with any byte, not just these boundaries), and now the PUSH
bit.

Other than the handshake and windowing, what's the same anymore?

There should be room for variations of TCP that do other things, i.e.,
force packet boundaries, allow out-of-order delivery to the app, 
allow drops while maintaining order, or even change the constants
(+1, /2 in AIMD, or initial window) to suit particular domains
(satellite use, e.g.)

(as I mentioned at in London, this could be done by factoring the
state exchange, windowing, and data transport portions of TCP into
specification modules that can be used to develop OTHER protocols;
if anyone is interested in this, please contact me).

There is, however, no reason to build all this cruft into a single
protocol. It jeapardizes the interoperability of the default case
(i.e., each protocol has to ENSURE backward compatibility). And
there is further no reason to standardize these variations in the IETF,
especially where they are used by domains of cooperating parties.

It is sufficient to document these variations as INFORMATIONAL,
and run them on other reserved protocol numbers. 

IF, in a few years, their use is that demonstrable, it would be appropriate
to consider rolling them into TCP. At this time, all we end up with is a 
whole bunch of complexity, much of which is admittedly a stop-gap fix
until a new protocol comes along anyway.

Joe

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 26 Aug 2001 13:13:55 -0500

Joe,

Please see comments below...

> aligned with any byte, not just these boundaries), and now the PUSH

I don't think it really changes the API.  The ipso facto interface
for TCP is the sockets API, which supports record delimitation: it
is just not currently used by TCP.

> Other than the handshake and windowing, what's the same anymore?

Oh, about 9000 lines of code is still the same.

> (+1, /2 in AIMD, or initial window) to suit particular domains

Try SCTP (a separate protocol from TCP) for these features.

> if anyone is interested in this, please contact me).

That was not the IETF's own approach for SCTP.

> especially where they are used by domains of cooperating parties.

No need to build them at all: they already exist in SCTP.

> and run them on other reserved protocol numbers. 

Why even document them as INFORMATIONAL?  These features are already
Proposed Standard in SCTP.

> until a new protocol comes along anyway.

The new protocol has come along for most of the features you
mention: SCTP.  There is no need for divergent approaches.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Joe Touch <[email-masked]>
Date: Mon, 27 Aug 2001 08:45:40 -0700

> is just not currently used by TCP.

Having TCP use anything except a stream interface changes the API.
Granted, there is a preexisting API - that of UDP - which you can
adopt. But that's still changing _TCP's_ API.

> Oh, about 9000 lines of code is still the same.

Reusing code need not warrant reusing a protocol number,
especially when the semantics of the protocol change.

> Try SCTP (a separate protocol from TCP) for these features.

SCTP is one possible solution. There is room for a variety until
experience shows which is best. 

> That was not the IETF's own approach for SCTP.

With the expected result. That in of itself may be reason to examine
that approach now.
 
Joe