Subject: RE: [tcpm] TCP consolidation doc

From: [email-masked]
Date: Sun, 29 Feb 2004 02:00:18 +0200

Hi Wes,

Tossing my 2 cents into the pot:

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

I agree - I think this would be a good thing.  Also, it would be useful
to mark
what is needed for interoperability and what is needed for 'modernity'
...

John

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

---

From: [email-masked]
Date: Sun, 29 Feb 2004 04:12:01 +0200

Pasi,

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

This sounds a bit like an applicability statement for the different features,
does it not?  Anyhow, there's probably a couple of things still wound-up in
all of this.  First off, there's the issue of what TCP implementations 
support (i.e. - what does the code support) and then what circumstances 
some of these features are useful.  You could imagine that servers may need
to be able to support 'wireless' features because they may talk to 'wireless'
nodes even if the server themselves are not wireless.

John