Re: [tcpm] 793bis update

[Joe Touch <[e-mail]>]

Hi, Wes,

Sorry for the delay in responding. I had a few thoughts, below.

Joe

On 2/6/2015 12:11 PM, Wesley Eddy wrote:
> FYI - I posted an update to the proposed RFC793bis (still an individual,
> not a working group draft):
> http://tools.ietf.org/html/draft-eddy-rfc793bis-05
>
> The main goals in this revision was to introduce a section on
> segmentation of data and place into that section the normative
> content from RFCs that updated 793 and cover the MSS & PMTU
> topics.

The section is useful, but I think also ignores a few key issues that 
would be useful to highlight:

- there's a tension between sending "as large as possible" and a few 
other goals:

	- sending as few short segments as possible

	- avoiding delays to the stream, esp. when the user data
	is NOT always available (i.e., when TCP has to wait)

- "as large as possible" is nearly never a useful goal; it's a 
consequence of some other goal

	The goal is often either performance or fate-sharing.

	Performance argues for larger packets, but the benefit
	decreases as the size increases. Further, there are some
	sizes that, while bigger, are not always better (e.g.,
	1025 bytes can be worse than 1024, even when both fit
	in a segment, due to data alignment on copy).

	Fate sharing argues for smaller packets because TCP
	is not always aware of fragmentation/reassembly at lower
	layers (the degenerate case being AAL5 over ATM, but there
	are other examples). So just because the next-layer down
	has a given MTU, does NOT automatically make that MTU a goal.

- TCP's default MSS has other rules

	I thought there was a rule about being on the same subnet
	and using the interface as the starting MSS.

- I thought TCP SHOULD also support PLMTUD, not just PMTUD.
	
	The difference should be discussed in more detail than given in
	sec 3.7.2.

- Regarding:
    o  TCPhdrsize is the size of the fixed TCP header; this is normally
       20, but may be larger if TCP options are to be sent.

	If TCPhdrsize is the size of the fixed TCP header then it is
	ALWAYS 20. And TCP headers almost always have options.

	I think you may have intended:

	TCPhdrsize is the size of the TCP header and any options;
	this is 20 in the (rare) case that no options are present.

- Regarding:
    o  IPoptionsize is the size of any IP options that TCP will pass to
       the IP layer with the current message.

	TCP doesn't pass options. That happens as a result of settings
	to the socket.

- it would be useful, IMO, to highlight the relationship between TCP 
segment boundaries and user data

	I.e., that TCP guarantees NO such boundary coherence.

Joe