Re: [tcpm] alternate IW proposal

["Anantha Ramaiah (ananth)" <[e-mail]>]

Folks,

I am not sure my response to this may be construed as "hand waving".
Basically, I have some general process questions to begin with and later
some comments about the document :-

ONE REQUEST : Please read this short email in its entirety and provide
comments, sometimes the case being made is spread across multiple
points, so just please don't pick on one word or sentence and snip the
rest. The hope is, I don't want to create a big thread and start a fiery
discussion on this aspect (mostly process oriented )

- what is considered a minor change versus a major to TCP? Can the
charter be modified to explicitly clarify (best effort would do) this.

- IW change, some may feel that it is a fundamental change, but for some
it is a minor change or a "parameter change". Well, all of these can be
argued as hand waving, IMO.

- Just for the illustration lets divide TCP into multiple segments :-
The API interface, the protocol semantics, TCP options, TCP congestion
and flow control, TCP security, TCP integrity (like checksum etc.,) and
some more..  TCP is pervasive protocol and if you really look at each
and every aspect of this is equally important and fixing those would
generally benefit a lot of applications and hence the "internet". 

- IRTF versus IETF :- When IW=10 was brought up I assumed that it
sounded like IRTF work. Why should we keep asking such questions if the
charter clearly spells out : "what is construed as a minor change to
TCP"? 

Now there seems to be good interest in getting IW=10 adopted and move
on, when folks say, "isn't it aggressive" ? (maybe it is a repeat
question, causing annoyance, but see below), which is a fair question,
IMO, I am baffled to learn that it is construed as hand waving WHEREAS
changes that fall into other categories are generally met with stiff
resistance with some folks conveniently changing hats and proclaim "the
bar is very high for changing TCP". This is double standards, IMO. 

It would be expedient to analyze merits and de-merits and not "hand
wave"..  if there is need for more data, then let's call it out
explicitly. Once data is collected and the issues are resolved the next
revision of the document should acknowledge such a discussion took place
and the consensus was "so and so". This way any new entrant who has same
questions ( a new entrant is not necessarily new to TCP, it is just that
(s)he may not have been following that draft) Makes sense since, if such
issues are considered as roadblocks for forwarding momentum of the
document, then it is very beneficial to state such things in the
document. 

Some earlier documents used to have an appendix which listed the changes
from prior versions and the open issues and consensus of each of them.
Later on it was removed when published as an RFC, when the essence got
captured into the main document. In fact, in some cases multiple email
threads of each open item were started and later posted the resolutions
of each of the items. I think for the current document such a
methodology may be useful. In the current case, most of the questions
are met "we have collected data, go look for it". I clearly want to
state something here : I fully understand that Google has done a good
job on collecting the data, and that needs to be done since they are
proposing an important (for the lack of a better word in my thought
process) change. Isn't it fairly obvious that folks reviewing the
document may not have all the information gathered and can ask some
fundamental questions? Well, if this isn't the expectation, I am
surprised.

Well, when was the data collected? At different times of the day, peak
hours versus no-peak hours?, continents or topologies, how was the
burstiness controlled (the document does acknowledge something to this
effect), also can we get the traceroute of the paths being simulated?
(well, let's not pick on words here, I am not asking for such a thing,
but the data collection needs to list them). The document in its
existing form doesn't answer these questions, but the pointers provided
also don't discuss these stuff exhaustively. That said, I should point
out that for anyone who wants to do a better job in reviewing this
document, needs to study the data being collected and come up with
questions. 

FWIW, I not opposed to this document, I am just trying to question the
"extra protection" this document seems to enjoy, even though this seems
like a important change to TCP and needs more scrutiny. One thing for
sure, this document needs an applicability statement, i/e,. under what
circumstances this IW = 10 can be used, and which cases it may be risky,
in other words if definitely needs to be based on a configurable knob.

Just my few bits.. 

Thanks,
Anantha