Re: [tcpm] 793bis update

[Wesley Eddy <[e-mail]>]

On 2/23/2015 2:52 PM, Joe Touch wrote:
> Hi, Wes,
> 
> Sorry for the delay in responding. I had a few thoughts, below.


Hi Joe, many thanks for the feedback.  Since getting this right is
more important than doing it fast, there's no need to apologize
about delay in responding!

This was a trickier update among the ones that I'd worked so far,
mostly because the rules and advice on MSS and related topics is
spread out over several RFCs, and although 6691 helped quite a bit,
it didn't quite go so far as to say what the prescriptive text should
have looked like in 793 or 1122 :).

So, careful review of this is much appreciated.

I essentially agree with your points, and intend to work them all
to some extent into the next update, but some responses are inline
below with some explanations and follow-up questions.


> 
> 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)


Thanks for mentioning these; they definitely should be reflected in
the text in the next update.


> - "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.


You're obviously correct, and this should be fixed and clarified in
the text in the next update.


> - 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.


There seems to be at least a little bit of discussion on this in RFC
879, though I haven't yet bumped into a very clear statement of it.
Do you know of anyplace that this lives in the literature / RFC series?


> - 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.
> 


This seems fair to discuss at least a bit further in the document.  I'm
not positive whether there is or is not an RFC existing already that
says "SHOULD support PLPMTUD, not just PMTUD" ... I would guess that
most folks would agree with it, but I'm just not sure if there's a place
that says it in 2119-speak.  Maybe I'm being too pedantic about trying
to keep the scope to specific recommendations and changes to 793 that
have already been approved in other RFCs and errata ...

We can certainly say that RFC 4821 describes the algorithm and specific
probing mechanism for use with TCP, and that it's on the Standards Track
as an improvement to PMTUD.


> - 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.


Actually, this text is stolen directly from RFC 1122.  I have actually
been working to avoid writing or changing text, to the greatest extent
possible :).

I think you're right in clarifying this though, and it's in the spirit
of part of what went into RFC 6691 to make this clear, so I like it.
We actually may want to be stronger and say that if TCP options are
used on a segment, then the sender should adjust the data length
accordingly, just like section 4 of RFC 6691 says.


> - 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.


This is also directly from 1122.  We could probably add some clarity
here with slight text modification to remain implementation-neutral
(e.g. not assuming a socket programming model), but still say that IP
options need to be accounted for.


> - 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.


I could use some help with this.  Are you referring to something along
the lines of discussion that has been had around Bob Briscoe's "inner
space" work?

-- 
Wes Eddy
MTI Systems