🚀 go-pugleaf

In article <1992Apr7.065040.20698@ugle.unit.no> 
harald.alvestrand@delab.sintef.no quotes me and writes:

>|> TCP could be treated as a Permanent Virtual Circuit and a single channel
>|> CONS provided over that. The TCP "urgent data" pointer could be used to
>|> mark the end octet of each DLSDU or NPDU for the "data link" version...

>I had this idea also (about using the URG pointer for something).
>I actually checked it with Jon Postel at the time (1984):
>When a recipient is reassembling TCP segments, and finds the sequence
>
>
>(byte 12 to 72; URG at 73)
>(byte 73 to 112; URG at 113)
>
>it is perfectly legal to return to the user bytes 12 to 112, and only signal
>the URG at position 113.
>So URGs are useless for anything other than their stated purpose: To indicate
>to the recipient that there is urgent data somewhere down the data stream.
>It gives no help in finding out where the urgent data actually is.

Ok, thanks for the warning, but I checked the TCP RFC again and I still
think my proposal would work. This point is the reason why I thought it
might be difficult to make use of PUSH or use the URGENT pointer for
additional functions (like Q bit or expedited data), though I still
wonder whether something could be done by monitoring STATUS and would
appreciate any advice on that.

But note that I said the urgent pointer could be used to "mark the END octet"
of the Protocol Data Unit (emphasis added). I mean that having reached the 
end of a PDU, the last octet is sent in a separate SEND primitive with
both PUSH and URGENT flags. The way I understand it, this will result in
an IP (or whatever) segment being despatched, that ends at the end of
the PDU and has an URGENT pointer pointing to that end, as well as a
PUSH flag. This should avoid much of the wastage that may result from
the lack of any connection between RFC1006 blocks and the underlying
network segments.

I believe that any READ buffer will either contain no PUSH nor URGENT
flags or else will contain both flags and end at that PDU end octet.

Thus whenever TCP signals urgent data, any READ buffer that has urgent data
can only be an end of PDU buffer. The receiver gets signalled by the
urgent data when each PDU has fully arrived (i.e. it's last octet has
arrived).

For this to fail, there would have to be a READ buffer which contained
non-urgent data following the single octet that was PUSHed and marked
URGENT, which cannot happen. Is there a flaw in my reasoning?

BTW, I would appreciate any comments on my main theme, that one could
easily run CONS over TCP (or TP4) as a migration strategy that avoids
any need for "transport bridges" etc. That assertion holds independently
of using PUSH + URGENT for greater efficiency than RFC1006 - it could
for example use exactly the same method as RFC1006 (a length indicator)
to delimit Data Link or Network Layer PDUs instead of Transport PDUs.
Alternatively, for improved latency, it could use framing bytes with
byte stuffing for transparency instead of a length indicator.

This seems a very obvious and natural approach to me but I haven't seen
any reference to it in any of the literature about CO-CL interworking
etc. What gives?