Subject: [Tsvwg] draft-ietf-tsvwg-quickstart-00: Some questions about the current rev.

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 17 Aug 2005 09:09:12 +0100

Dear authors & tsvwg'ers,

I recently read the above draft, and have some questions concerning the
current text. Can you help me?

Best wishes,
Gorry
(please cc: [email-masked] in any replies)

-----------------
Page 20: Section 4.4 para 2 from end of page 20.
"this addresses the problem  of a overly-large congestion window from an
overly-large measurement of the round trip time."
- I don't understand the statement, it may be true, but I am not sure what
it means.
-----------------
Page 22, section 4.6.2 - Path MTU Discovery
- The document says that setting the DF bit on a large number of overly
large packets is "not desirable".
- I really think the document should provide some guidance on the use of
PMTU, at least to say that the implementor must use an IETF-approved method
to determine the appropriate packet size. The default behaviour being the
use of the smallest guaranteed MTU
- The current text asks more questions than it seems to answer.
-----------------
Page 22: section 4.6.3 final para on page 22.
- The final paragraph recommends a change to the initial RTO setting for
TCP. I found this VERY disappointing, the sort of networks that I had wanted
to use this with have a round trip path delay that can vary and may be
greater than 1 second, which if I understand means that QS will make the
performance worse. I also have concerns that changing the TCP initial RTO
value to 1 can have some very bad effects on the remainder of the session,
in some styles of implementation (e.g. where the SYN timer is used to
initialise the RTO for the transfer phase).
- The statement here also seems at first thought to be in contradiction to
recommending use in GPRS networks (section 8.3).
- Is it absolutely necessary to do it this way?
-----------------
Page 26: section 6.2, point "multiple paths"
- I can't decide if this is true or not, I suspect that the QS method can
inject much more data than would typically be found using Slow-Start (even
with many sessions). What do others think?
-----------------
Page 29: Section 6.4
"routers should be discouraged"
- This seems rather weird to me, or unclear. I believe that dropping excess
low-priority traffic is exactly what you would wish a DS or CBQ router to
do? If the DS SLA, for instance, said it was lower priority...then  it
dropping may be an appropriate treatment. What does this section really
mean?
-----------------
Page 35: 
"GRPS round-trip times are typically up to one second"
- This is possibly so, but it is not necessarily always so, as the paragraph
later suggests, the total end-to-end delay includes queuing delay and the
non-GPRS segment of the Path. Delay can therefore increase above 1 sec.
Since total delay is what matters, the assertion of this paragraph is
perhaps confusing!
-----------------
See separate emails on NONCE and author's document NiTs.
========

Finally, I find the organisation of the text still rather mixed-up.  I think
the document could be improved by a small amount of reorganisation to make
this a useful Experimental RFC. Some parts read as more informative, others
as normative. Maybe it is critical to say this about a -00 WG draft, I'm
sorry. 

* There does not yet seem to be a consistent use of standards language in
those sections which are normative, describing the actual protocol spec.

* It is not immediately clear which sections MUST be read to implement
correctly, which must be read to deploy it or develop router support and
which are informative about the method/design - I would much rather have
seen a section (or sections) with a spec, and some later sections which give
informative guidance. 

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