Re: [tcpm] 793bis update

[Joe Touch <[e-mail]>]

Followup below...

On 2/24/2015 8:22 AM, Wesley Eddy wrote:
...
>> - 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?

Found it: RFC1122, Sec 3.3.3:

          ...In the absence of actual knowledge of the
          minimum MTU along the path, the IP layer SHOULD use
          EMTU_S <= 576 whenever the destination address is not on a
          connected network, and otherwise use the connected network's
          MTU.

"connected network's MTU" is 1990s slang for "NIC interface when on the 
same subnet".

>> - 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 don't know either. It's not in the PLPMTUD RFC, which is written more 
as "if you implement this, here's what you MUST/SHOULD/MAY do".

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

Oh, agreed - I think it's worth digging to find out, but unfortunately I 
don't have cycles (I'm writing a midterm in the other window)...

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

It is, but you're right that we've never made a statement that says that 
it should be used to replace PMTUD wherever PMTUD is required, AFAICT.

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

Agreed.

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

Agreed to avoid the socket model per se; a different way of saying it is 
that the "IP options associated with a TCP connection", rather than to 
make it sound like TCP has an interface where it tells IP which options 
to use (RFC793 certainly does not).

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

This goes back to RDMA and its precursors a long time ago. I.e., the 
point is that send/receive calls (per RFC793) pass data in chunks to 
TCP, and TCP senders pass chunks from senders to receivers, but those 
two chunks have no correlation.

RDMA gets around this by assuming they do on the sender side, and 
detecting that they're sustained through to the receiver side - i.e., it 
says "detect when it happens and take advantage of it", but it doesn't 
assume it either (I pushed back hard on that).

Joe