Subject: [Tsvwg] Comments on draft-ietf-tsvwg-quickstart-02.txt

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 21 Apr 2006 14:01:39 +0100

Sally, authors, list. I started a detailed read of the latest rev of the 
QS draft this week, and have a few comments. Alas I ran short of time 
and shall be away on another job next week - so rather than postpone 
this, I am sending now, with the intention of the sending the final 
comments after next week.

Best wishes,

Gorry

1) Quick Start Interval
- This isn't a new point, but I think there should be a maximum time 
limit for a QS approval. I have the notion that a QS rate should be 
soft-state (or no-state) in the router. If it is soft-state (implies 
some accounting of requests for a period of time), I'd much rather see 
the time bounded.

This has some implications as well on the relationship betwen RTT and 
sending rate: I can't see a problem with saying the state MUST expire 
after (say) 3 seconds. This is a LONG time compared to most RTT's and 
RTTs that are actually greater than this can perhaps rate-pace their use 
of the window over the 3 second interval.

Fixing an upper limit could also help to get "predictable" performance 
in challenging envirobments - e.g. when BoD (e.g. an ISDN 
circuit/Wireless infrastructure) requires a time to setup a flow - but 
that additional setup time does not appear as a increase in subsequent 
RTT measurements.

2) Page 11: On relatively stable paths
"shows the assumption should generally be valid, although [RFC3819] 
discusses a range of Bandwidth on Demand subnets."
- This is not clear, I don't think the issue is necessarily the 
stability of the PATH (in terms of the set of routers involved).
- To me, the point concerning BoD subnets is that the capacity they 
offer (and RTT they exhibit) can be difficult to characterise at the 
transport layer, and may be a function of the overall traffic carried by 
the subnet.

3) Section 3.1
- The document seems not to mention Router-Alert. This is probably an 
oversight, in that at least this should be mentioned - if QS does not 
require Router-Alert, then we should say so.

4) Page 19 Section 3.3 para 2 - Non-approval.
"A router that wishes to terminate a Quick-Start Request SHOULD delete 
the Quick-Start Request from the IP Header... but.. then the router 
SHOULD zero the QS TTL, QS Nonce, and Rate Request Fields."
- I don't like this. The first SHOULD is ok. The second one leaves too 
much undefined. Can we consider mandating at least one of these actions 
if the request is not approved and the option has not been removed. I 
suggest:
"then the router MUST zero the Rate Request Fields and SHOULD zero the 
QS TTL, and QS Nonce."

5) Page 21, section 3.4 final para.
"then the router may decide to deny future Quick-Start Requests"
                  ^^^
- may or MAY?

6) Page 27, section 4.2, final para.
"Packet loss is an indication of congestion"
              ^^^^^^^^^^^^^^^^
- I'd argue that it is an indication of potential congestion. TCP needs 
to be conservative, it's not stupid, it makes this decision because 
there may be a problem and it can not know otherwise.

7) Section 4.6.2 I don't necessarily think of a simple ACL rule being a 
midbox function.
- Clearly the issues with more sophisticated midboxes are explained. 
However, this speaks of midboxes in a generalised way, and that's fine - 
but I would not generally have relate this discussion with router ACLS - 
which in my net is actually the place were decisions on options are 
made. I wonder if the wording could be clearer here.

8) Section 6 talks abourt IP-Tunnels.

- The opening text however only mentions IPsec and IP-in-IP. As far as I 
can see this text also relates to GRE and other tunnel encapsulations. 
Since we are frequenctly requested to consider GRE by the IESG, can we 
have more  comprehensive first sentence please?

Issues for my next mail:

Appendices (still to be read)
Approval - various issues in the motivation, security and coding, 
although I think I like the principle.

--------------------------------------------------------------

Editorial NiTs:

---
At various places single and double quotes do not use the RFC-Ed characters.

---
Page 2:
"is designed to allow connections to use higher sending rates"
                       ^                  ^                  ^
I'd have prefered:
"is designed to allow a connection to use a higher sending rate"
---
Page 13: Section 2.1
"The transport receiver returns the rate and information about the TTL"
- And the NONCE also :-)
---
Page 18, section 3.2:
"Hop Limit field in order to calculate"
                  ^^^^^^^^
Say simply
"Hop Limit field to calculate"
- The use of "in order" confused me here, since there is no implied 
ordering. I suggest you avoid the use of this phrase except when it 
implies that something else follows?

---
Page 19, Section 3.3:
"This saves resources as downstream routers"
                       ^^
Better to say:
"This saves resources because downstream routers"
---
Page 24, Section 4:
"The sender sends a Report of Approved Rate."
                              ^
- Insert "the" after "of"
---
Pge 29, Section 4.5
Quotes in first para seem odd (and may be unecessary?)
---
Page 32 top para:
"Is more likely to be blocked due to IP Options than due.."
- Poor wording, it's more likely to be dropped because of filtering 
policies that discard packets that carry IP Options (or packets with 
unrecognised IP Options).
---

---

From: Mark Allman <[email-masked]>
Date: Fri, 21 Apr 2006 11:10:57 -0400

Gorry-

Thanks for the note.  I happened to be hacking the draft when your note
arrived.  I fixed the nits you outlined, but do not have time to process
your larger comments right now.  However, they all look to be useful and
we will get them addressed.

Thanks!

allman