Subject: [tcpm] agenda items?

From: Mark Allman <[email-masked]>
Date: Mon, 23 Feb 2004 23:05:29 -0500

If anyone has agenda requests for TCPM in Korea that they have not sent
to Ted and I, please do so ASAP.

Thanks,
allman

--
Mark Allman -- ICIR -- http://www.icir.org/mallman/

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

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Fri, 27 Feb 2004 18:08:00 -0500 (EST)

Sourabh and I were thinking that it would be useful to have a document
that consolidates all the TCP modifications into a single document. The
roadmap is useful too, but someone who is implementing TCP from scratch
would have a hard time piecing together all the TCP RFCs. Perhaps there
could be an RFC which specifies the current standards track TCP. The RFC
could also have an experimental section.

What do others think?

Armando & Sourabh

0--                                              --0
| Armando L. Caro Jr.  |  Protocol Engineering Lab |
| www.armandocaro.net  |    University of Delaware |
0--                                              --0

---

From: Wesley Eddy <[email-masked]>
Date: Fri, 27 Feb 2004 18:21:12 -0500

> could also have an experimental section.

I'd like to see not just a layout of the modifications but some additional
emphasis on exactly which ones a tcp should include to be considered "modern"
(SACK + DSACK with proper recovery, timestamps, WS, autotuning, etc).  The
relative importance amongst them might be useful too for people looking to
incrementally hack on existing stacks that don't have them all.  For instance,
do we want to make window scaling a more important feature than sack support.

-Wes

---

From: Pasi Sarolahti <[email-masked]>
Date: Sun, 29 Feb 2004 04:03:36 +0200

Hi,

ext Wesley Eddy wrote:
>>that consolidates all the TCP modifications into a single document.
> 

Agree. There should be a paragraph or so on each modification discussing 
its usefulness and purpose. However, I don't know how easy it is to 
build a definite list of recommended modern features with a specific 
importance level. Likely the importance depends on the angle of view. 
Some live in environment that would prefer WS more than SACK, some don't.

Maybe there could also a section discussing implementation issues? (or 
is it a different doc?) Sometimes it seems that the biggest challenge is 
not the features current implementations have, but the bugs that may 
cause a useful TCP option to be counterproductive.

- Pasi

---

From: Mark Allman <[email-masked]>
Date: Sun, 29 Feb 2004 23:12:43 -0500

Armando-

> that consolidates all the TCP modifications into a single
> document. The roadmap is useful too, but someone who is implementing
> TCP from scratch would have a hard time piecing together all the TCP
> RFCs. Perhaps there could be an RFC which specifies the current
> standards track TCP. The RFC could also have an experimental section.
> 
> What do others think?

First, let me say that I agree that TCP stuff is just a tangled web of
specs and could be really hard to pick through from scratch.

In fact, I have had several conversations with people about a little
piece of this.  That is, rolling a bunch of the smaller changes into an
rfc2581.bis.  E.g., think of something like limited transmit or larger
initial window.  In the long run, these don't need their own documents
because they are such minor changes.  But, I like the longer document
that really distills the thinking behind it.  So, I think that you are
right on in some cases.

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

It seems that if we get the roadmap right and so we can hand someone
that and they can go off and look at other RFCs as appropriate then that
should be a decent path.  And, the roadmap seems light enough that it
could be updated frequently.  E.g., maybe a WG like this one could set a
goal of reving it every year or two for updates.

You say above that this proposed doc would be in addition to the
roadmap.  I'd like to hear why we'd need both?  It seems to me if we
have a mega-spec that would just obviate the need for a roadmap (i.e.,
the roadmap would be the table of contents).

Thanks!

allman
(chair hat off)