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

From: Sally Floyd <[email-masked]>
Date: Fri, 21 Apr 2006 11:20:18 -0700

Gorry -

Many thanks for the feedback.  We have been editing the draft,
and hope to have a version ready for Working Group Last Call
next week.

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

The revised version says this:

    If the checks of the TTL Diff and the Rate Request are successful,
    and the TCP host is going to use the Quick-Start Request, it MUST
    start using it within one round-trip time of receiving the Quick-
    Start Response. 

We could revise this to say within one RTT or within three seconds,
whichever is smaller.

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

Yep.  Though the assumption about relatively stable paths matters because
we want the Quick-Start data packets to follow the same path as
the Quick-Start request the previous RTT.  The revised version
of the draft says this, and hopefully is more clear:

    Assumptions:
...
    * The path between the two endpoints is relatively stable, such that
    the path used by the Quick-Start request is generally the same path
    used by the Quick-Start packets one round-trip time later.  [ZDPS01]
    shows this assumption should be generally valid.  However, [RFC3819]
    discusses a range of Bandwidth on Demand subnets that could cause
    the characteristics of the path to change over time.

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

Section A.1.1 on ICMP says the following:

    The ICMP Quick-Start Request would  
    have to pass by the routers on the path to the receiver, possibly   
    using the IP Router Alert option [RFC2113].

My assumption is that QS with the IP opion does not require
Router Alert.  I will add that.

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

Well, there already exist non-Quick-Start-capable routers that
won't be able to zero anything in the QS request, but will
implicitly deny the request by not decrementing the QS TTL counter.

And we already say that the router should protect itself from
QS-request-floods by rate-limiting the number of QS requests that
it considers (and implicitly denying the others by not decrementing
the QS TTL counter.  I think it is necessary to leave that in.
And that requires allowing Quick-Start-capable routers to deny
requests just by ignoring them.

Yes?

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

I will change it to 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.

Will do.  (Packet loss could also be an indication of corruption on
the return path.)

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

I am not sure what you want.  You want the text to make it more
explicit that the entity dropping the packet with the QS request could
be a router?  That would be fine by me.

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

Will do.  We also have added a section about MPLS...  

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

I will send you the revised version, even though it is not
yet submitted, so that you can read the most recent version.

Many thanks.
- Sally
http://www.icir.org/floyd/

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 22 Apr 2006 09:29:42 +0100

> and hope to have a version ready for Working Group Last Call
Look forward to this - and will postpone my final set of comments until this
rev is issued...

> We could revise this to say within one RTT or within three seconds,
The rule is fine from the perspective of a host that knows the PRTT (e.g.
from TCP). Routers on the other hand know nothing of the PRTT of individual
flows, and therefore do not know how to behave. If they do take different
stances, then the hosts are less able to know what will happen.

What do others think about a recommended upper limit to the time (3 secs)? -
Or put another way: Can we agree a reasonable limit?

>     the characteristics of the path to change over time.
Fine with me.

> Router Alert.  I will add that.
OK - I thought that was meant.
> implicitly deny the request by not decrementing the QS TTL counter.
True.

> requests just by ignoring them.
OK - I see that logic.
>> "then the router may decide to deny future Quick-Start Requests"
OK.
> Will do.  (Packet loss could also be an indication of corruption on
Indeed!
> be a router?  That would be fine by me.
One sentence that indicated that the filtering could be a simply policy
decision in a router would be nice at the beginning. In other documents, I
sometimes skip "modbox" considerations if I'm just thinking of routers and
end-hosts, in this case EVERYONE needs to read this section.

> Will do.  We also have added a section about MPLS...
Good.
> http://www.icir.org/floyd/

Best wishes,

Gorry