Subject: [tcpm] 793bis update

From: Wesley Eddy <[email-masked]>
Date: Fri, 06 Feb 2015 15:11:27 -0500

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.

You can easily view the diffs from -04 here:
http://tools.ietf.org/rfcdiff?url2=draft-eddy-rfc793bis-05.txt

-- 
Wes Eddy
MTI Systems

---

From: Joe Touch <[email-masked]>
Date: Mon, 23 Feb 2015 11:52:55 -0800

Hi, Wes,

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

Joe

> content from RFCs that updated 793 and cover the MSS & PMTU

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

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 24 Feb 2015 11:22:45 -0500

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

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

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

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

>     The difference should be discussed in more detail than given in

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.

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

>     TCP doesn't pass options. That happens as a result of settings

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.

>     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

---

From: Joe Touch <[email-masked]>
Date: Tue, 24 Feb 2015 08:40:04 -0800

Followup below...

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

> 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

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

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

> accordingly, just like section 4 of RFC 6691 says.

Agreed.

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

> the lines of discussion that has been had around Bob Briscoe's "inner

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