Re: [tcpm] RFC 793-bis comments

[David Borman <[e-mail]>]

On Oct 14, 2014, at 10:49 PM, Anthony Sabatini <[e-mail]> wrote:

...

> Another area of concern is that the original RFC 793 document does not recognize the existence of devices that will relay messages and the standards for forwarding and discarding of messages in that class of device, as opposed to the behavior required of an end point device. The rules that require the discarding of a message by an end point device are not applicable to a transited device which must propagate all messages which it does not understand. It is crucial that the standard identify what conditions will be discarded by both devices and which shall be discarded by end point devices but forwarded by transited devices.  
> 
> One such condition is the setting of SYN and FIN in the same packet on an end point device where this combination is undefined the packet should be discarded, but on a transited device the packet must be forwarded since future standardization may, for example, define this combination as indicating a new TCP service such as a maintenance or traffic control message.

If only it were true that "transited device which must propagate all messages which it does not understand”, but that’s not the reality.
Though TCP is an end-to-end protocol, middle boxes delve into the TCP header and make decisions on whether or not a packet is acceptable, breaking the end-to-end nature of TCP.  It is sad that this has become the reality, and every proposed enhancement to TCP now has to consider how it will survive through middle boxes.

> The single biggest obstacle to improving TCP is the fact that the data offset field is both poorly defined and greatly limited. As currently defined half the possible values are invalid and the options area which it defines is too small to provide the necessary space to allow options to fulfill their full promise. Also being an offset it hard wires the size of a TCP header preventing the addition of header fields in a future standard. 
> 
> In the current standard the data offset field should be redefined as the length of the options field and values 0 - 7 should be defined as follows: "in normal use on an end point device a value of 0-7 should be discarded but on a transited device should be forwarded.  Values 0 -7 if present represent a TCP options area length of 32 - 60 bytes (8 - 15  32 bit words). Values 0 - 7 in current use can only be used by negotiation via the options field and thus cannot appear on a packet where a SYN is set" (subject to future standardization current end point devices should discard a packet with SYN and a value of 0 -7 transited devices should forward the packet).

Redefining the meaning of Data Offset values 0-4 (5-7 are valid) is not a new idea, see http://tools.ietf.org/html/draft-kohler-tcpm-extopt-00.  As with any proposal for expanding the TCP option space, the biggest challenge is trying to make use of it in the initial SYN and still maintain backwards compatibility.

			-David Borman