Re: [tcpm] On TCP Urgent processing

[Fernando Gont <[e-mail]>]

Alfred � wrote:

> The utmost first step for any follow-on draft must be to replace
> "Urgent Data" by "Urgent Processing" or "Urgent Mode" in the
> document title and similarly in the draft name.  See below!

Well, this one shouldn't be a problem. I can live with it. :-)


> The basic reason of why implementations did not follow
> the 'corrections' to RFC 793 first published in RFC 924
> ( not: RFC 961, as indicated in the last paragraph of
>   Section 2.2 of draft-gont-tcpm-urgent-data-01 ! )
> and finally codified in RFC 1122, seems to be that the
> terminology and the processing rules were partially contradictory
> from the beginning -- and that apparently was caused by historical
> circumstances and pressure exerted on the "TCP committee" over a
> long time span in these old days.

My take is that the "corrections" would not have interoperated with the
deployed code, and that even then, there was no ROI in e.g. changing the
semantics of the urgent pointer.


> Therefore, returning to the picture painted above, the *first*
> step should be to formulate strong recommendations for how
> applications and in particular implementations of applications
> should make use of TCP Urgent Processing (if any).
> This IMO should be based on the concepts explained in the two
> definitions from RFC 793 quoted above.
[....]
> Since decades, Telnet makes use of URG, and apparently this
> all works (almost) properly, independent of the underlying
> TCP stacks' behavior at the sending and receiving side.

Well, the "underlying TCP stacks' behavior" is homogeneous -- everyone
implements the same non-compliant behavior.



> (BTW: the discussion in RFC 1123 seems also to be disturbed.)
> The reason seems to be simple: being defensive, and not
> assigning semantics to the data delivered with the sending
> side's urgent call.
> According to RFC 854, the Telnet client sends a DM NVT control
> character which is a transparent NOP for the Telnet server.
> Thus, it does not matter for the Telnet server how the TCP
> stack interprets the Urgent pointer.

It should matter. If a system sends data with the deployed semantics for
the UP (i.e., it points to the byte following the last byte of urgent
data), but the receiver implements the compliant (RFC 1122) behavior
(i.e., points to the last byte of urgent data), then one control byte
(after DM NVT) will be skipped.

OTOH, if a system sends data with the IETF-compliant (RFC1122)
semantics, and the receiver implements the deployed semantics, the
"urgent byte" will not be skipped (this would be safe for telnet, as you
point out).



> (1) Give recommendations for application protocol designers
>     and application programmers of how to best use the common
>     Sockets API for Urgent Processing, in order to accommodate the
>     legacy problems and the inconsistencies in the specifications.
> 
>     This should target BCP status, and it should have a tight
>     milestone of not more than 6 months for passing to the IESG.
> 
>     Most elements of such document already are in
>     draft-gont-tspm-urgent-data-01 ;
>     my personal expectations for the basic recommendations are:
> 
>     o  MUST always use OOBINLINE;

Agreed.


>     o  SHOULD only send a single octet in the urgent call;

This would contradict RFC 793 and RFC 1122 (?)



>     o  SHOULD use syntactically transparent data in the urgent call
>        (equivalent to DM == NOP in Telnet);

But... what about the deployed sender to RFC112-compliant receiver case
sketched above? Or are you also thinking about updating the semantics of
the UP so that they reflect the deployed code?



>     o  intermediate systems MUST NOT scrub the TCP URG flag
>        (URG is an entirely end-to-end indication);

Agreed. But... they have been deployed. And Cisco PIX is widely
deployed, and does scrub the URG bit!



>     o  a hint that a parallel TCP connection ('control channel')
>        SHOULD be used if an application needs true OOB data transfer.

Agreed.



> Based on the captured intent of the original specifications,
> therefore, a unique definition for "Urgent Data" should be found.
> In RFC 793, three possible candidate definitions are sublimely used:
> 
>     a) the data 'temporally' ahead of the Urgent Pointer,

Did you mean "behind"?



>        i.e. the all the buffered data that are being invalidated
>        by the 'urgent' call (TCP 'SEND' call in the abstract TCP
>        'User Interface' of RFC 793, section 3.8, pp. 46/47, with
>        URGENT flag set);
> 
>     b) the data sent with the 'urgent' call;
> 
>     c) the union of both a) and b).

Well, ironically, what's "urgent" is the first non-urgent data! :-)

i.e., with "urgent data" being whatever you read while being in "urgent
mode", you basically want to skip those data, such that you can quickly
get to the first non-urgent data (i.e., get out of urgent mode).



> Note #3: The ambiguity in RFC 793 mostly stems from that it remains
>   underspecified whether the urgent pointer refers to the state of
>   the sequence number at entry to the event processing or at its
>   end, i.e. whether (on pg. 56)  "SND.UP <- SND.NXT - 1" should
>   happen before of after processing the data handed over in the
>   SEND with URGENT flag set.

It should happen *after*. Remember that a TCP is allowed to send
sequences of urgent data of any length. (yeah, I hate to use the term
"urgent data"... but you know what I mean).



> Note #4: There is more trouble in RFC 793 related to Urgent mode;
>   in particular, the event processing rules deal with URGENT flag
>   for the OPEN call whereas the OPEN Interface definition does not
>   contain such flag at all.

Good grief!



> Thus, the second delivery of the TCP URG work item should be:
> 
> (2)  A Normative (Standards Track) document clarifying the
>      definition of the term "Urgent Data" for TCP and Updating
>      primarily RFC 793 and RFC 1122, but for consistency also
>      RFC 854 and RFC 1123, to make them conformant to the
>      clarified definition and provide consistent and self-
>      consistent processing rules.

What, specifically, would this I-D update?



> I'd offer to work as a co-editor with Fernando Gont for a TCPM
> work item shaped along the ideas and guidelines presented above,
> but more volunteers to help with completing the investigations
> of the TCP-related IEN documents would be heartfully welcome,
> in order to give the whole effort the best possible foundation
> to be in the spirit of the original designers of TCP.

So you argue that tcpm should adopt draft-gont-tcpm-urgent-data, and use
that I-D as a basis for the BCP document, and also work on another (std
track) I-D that we'd both co-author?

BTW, is there a need to actually dig at the IENs, etc.? I'm not saying
it wouldn't be worth the effort, but... I' not sure it would be actually
"required"/needed to clarify TCP's urgent mode, etc.

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1