Subject: Re: [tcpm] TCP consolidation doc

From: Janardhan Iyengar <[email-masked]>
Date: Mon, 1 Mar 2004 12:41:40 -0500 (EST)

Hi all,

> I find myself really wondering what a longer document would buy us.
> It'd be damn hard to write and agree on, I bet.  And, it'd be cumbersome
> to change -- and, I think one lesson we have learned is that TCP is
> always evolving.  So, especially if one puts experimental things into
> the document I think it'd be way hard to make that work.  Think about
> this... say one wanted to include early retransmit and we have this
> mega-doc.  Now we have to open up the document to put in this one
> change.  But, while the document is open people want to throw other
> things in.  Can they?  Do we now have charter lines that say "open
> section X of The TCP Thome only"?

I agree. I was thinking along the same lines myself, and was wondering
whether a document like this could be written up with mass consent
*before* another enhancement pops up and becomes important.

IMHO, the roadmap should be able to provide what, with mass consent, the
"latest and greatest" TCP includes. It seems to me that a practical goal
is a good consolidation doc that would include pointers and have
discussion about interoperations between the different extensions (Sourabh
is looking into something similar at this time) and maybe implementation
notes about possible pitfalls during consolidation (from implementers'
experiences).

Granted that for an implementer, it is a headache to get n documents and
piece together the n extensions/enhancements, and leaves room for error in
the implementation.

regards,
jana

---------------------------------------------------------------
         Visit www.narmada.org, www.indiatogether.org
---------------------------------------------------------------

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 1 Mar 2004 18:00:04 +0000 (GMT)

allman wrote:

> It'd be damn hard to write and agree on, I bet.

Note the history of aborted/unpublished TCP documents. RFC1323bis, the
whole SACK thing. A long document is doomed before you start. Adding
new/experimental stuff dooms you too.

What you really want is a very short RFC relying heavily on the
normative mechanism, commenting on the current standards-track RFCs as
normative references, saying what is considered important to
implement, what is worthwhile implementing, possibly known
implementation gotchas, etc. This RFC would go BCP, and be updated by
subsequent BCP docs replacing it. You'd expct a yearly or two-yearly
commentary on the state of the art of TCP, really.

Given the existing IETF document focus on TCP and the narrow focus of
this doc on that, it's the one instance where normative references in
a BCP doc actually make sense.

L.

I can't believe I just said that.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>