Subject: Re: [tcpm] WG acceptance of draft-zimmermann-tcpm-tcp-rfc4614bis-02

From: Wesley Eddy <[email-masked]>
Date: Thu, 01 Aug 2013 11:38:51 -0400

On 8/1/2013 2:07 AM, Kevin Lahey wrote:
> 
> It would be nice if, instead of saying, "Read RFC793, then read the
> additions from RFC1122, then update it with info from RFC2873, RFC3390,
> etc.," we could say, "Read RFC8888 for the on-wire protocol details, and
> RFC8889 for the congestion control details." It's tough to keep all
> those details in your head while trying to write code, and it's
> frustrating to explain all this to new engineers trying to work on the
> TCP stack (RFC4614 certainly helps a great deal!).
> 
> On the other hand, watching Richard work so hard to get consensus on
> the (relatively) simple updates to RFC1323, I'm not sure who's ready to
> bell the RFC793bis cat.

Actually, I'm interested in working on this, and have some thoughts
about what it should look like and what the ground rules would need
to be in order to make it tractable.

I can see that it would be useful as there are errata, and at least
a few strings of updates to 793 that have been made.  Plus some
material should be removed that was important at the time, but is not
really today.

-- 
Wes Eddy
MTI Systems

---

From: Joe Touch <[email-masked]>
Date: Thu, 01 Aug 2013 16:53:58 -0700

On 7/31/2013 11:07 PM, Kevin Lahey wrote:
> It would be nice if,...  we could say, "Read RFC8888 for the on-wire protocol
> details, and RFC8889 for the congestion control details."

It would be nicer, IMO, if we could avoid the erroneous concept of "on 
the wire" as meaningful.

A protocol consists of all three of the following; any subset is 
meaningless:

	state (at endpoints or intermediate nodes,
	which includes time events)

	messages ('on the wire')

	rules that relate the above two

I think I understand your intent, which is to differentiate rigorous 
protocol requirements from vague ones, e.g., where TCP is more dependent 
on the precision of its 12 connection states than the details of its 
congestion control mechanism. However, both rely on all three components 
above.

I don't have a pithy term for that distinction, but "on the wire" isn't it.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 01 Aug 2013 17:03:12 -0700

>      which includes time events)

Depending on whether you want to group these in here, this also includes 
upper layer events (messages from/to 'above'). Those can be modeled as 
state events or treated separately. FWIW.

---

From: Kevin Lahey <[email-masked]>
Date: Fri, 2 Aug 2013 08:53:27 +0200

On Aug 2, 2013, at 1:53 AM, Joe Touch wrote:

> It would be nicer, IMO, if we could avoid the erroneous concept of "on the wire" as meaningful.

And, yet, it's kind of useful to know what I'm seeing when I look at a packet trace. :-)

> I think I understand your intent, which is to differentiate rigorous protocol requirements from vague ones, e.g., where TCP is more dependent on the precision of its 12 connection states than the details of its congestion control mechanism. However, both rely on all three components above.

Sorry to get you started, Joe -- I was casually trying to suggest that we didn't necessarily need one all-singing, all-dancing RFC to combine all of the different TCP RFCs.  Dividing it up along reasonable lines would allow for easier updates, etc.

In any case, my pain comes from reading something in RFC793, then thinking to myself, "Gee, I seem to recall that this was updated, but where, exactly?"  It might be kind of cool to have, say, the description of ABC folded into a RFC793-bis, but it also seems reasonable to have just a reference to RFC3465 at the right place.

Bless you, Wes. :-)

Kevin
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Fri, 02 Aug 2013 10:46:40 -0700

> And, yet, it's kind of useful to know what I'm seeing when I look at a packet trace. :-)

Agreed. I didn't see that as your goal, though.

I agree it's useful to have a section on the packet format, e.g., for 
wireshark and tcpdump implementers.

However, the "on the wire" vs. "cong control" difference typically 
differentiates critical protocol functionality from performance 
optimization - either for the health of the net or for better individual 
connection performance.

Regardless, IMO the term "on the wire" is one we ought to know better 
than to use, at least because of the ambiguity it presents.

...
> Sorry to get you started, Joe -- I was casually trying to suggest
> thatwe didn't necessarily need one all-singing, all-dancing RFC to combine
> all of the different TCP RFCs. Dividing it up along reasonable lines
> would allow for easier updates, etc.

If you do, where do you start looking? We clearly need a roadmap to 
start. That then argues for a hierarchical roadmap, but IMO that's going 
to be nearly impossible to do orthogonally.

I see a lot of docs that might end up being in most partitions that 
might result, which means that updating one RFC then updates many of 
these partitions. That might be more work than updating a single, 
unifying roadmap.

Joe