Subject: [Tsvwg] Re: Comments on rev-03: Quick-Start for TCP & IP

From: Mark Allman <[email-masked]>
Date: Wed, 07 Jun 2006 23:12:14 -0400

Gorry-

Thanks for the comments.  I just inhaled this thread (yeah, I am *that*
far behind...alas...).

> Table 1/Appendix B:  Lowest permitted encoded QS request?
> 
> When I thought about the encoding method for QS requests, 80kbps
> seemed logical for TCP, given initial windows and current
> TCP. Thinking more about the mapping and trying to envisage its use
> with NON-TCP flows, I wonder whether the lowest rate of 80 kbps is a
> factor of two too high?
> - I can see cases where UDP/TFRC, DCCP, etc flows could utilise QS
> to raise a congestion window for the same reasons as TCP, but where
> the target rate was much less than 80 kbps. This isn't the same as
> the request for finer resolution (or additional semantics as in DS),
> it's just a check that the set of rates is appropriate to other
> transports after that question was raised.

My hit here is that the 80kbps value is actually fine.  The host that
wants 40kbps can request 80kpbs.  If it would get 40 and not 80 then I
am not quite sure if I care too much.  I.e., the network must be pretty
close to the edge.

Further, the request granularity is pretty gross (each rate request
being twice the previous rate).  So, if actual rates that end hosts
wanted were evenly distributed and the network gave them precisely what
they asked for then we could assume that on average 25% of the
allocation is going to go unused (assume that the host overrequests
instead of underrequesting).  I.e., the actual rate needed will fall (on
average) right between two of the gross points in the request space.
Therefore, we're off by a factor of 2 at the bottom then we'll waste 50%
rather than 25%.

Finally, that extra wastage is *small* in absolute terms.  I guess it's
just not clear to me that it matters that these amounts of softly
"allocated" bandwidth are "tied up".  (In fact, the problem seems worse
when we'd be wasting Mbps when requesting faster rates, IMO.)

I think that we can disagree on what the bottom number ought to be.
But, I would hope we can agree that the impact is really quite small at
the rates we're talking about.

Thoughts?

allman

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 08 Jun 2006 16:37:11 +0100

> am not quite sure if I care too much.  I.e., the network must be pretty
I think "how close" you feel to the edge, depends on the ingress/egress 
capacity you expect to see in your router. If the capacity were a few 
100's kbps, rather than Mbps or Gbps, then you'd maybe care.

So, why not 10 kbps, 20 kbps, 40 kbps, 80 kbps..?

I'd argue 10, and 20 are too small - even simple multimedia apps 
generate 10 kbps, video codecs may be reasonably expected to need more, 
a link capacity of the order of even many tens of kbps is not the target 
of this I-D, since SHARING between multiple flows will be challenging.

I suggest the choice seems to be between 40 and 80 kbps as the bottom 
point, and if you had links of 128 kbps, 256 kbps, 384 kbps then 80 kbps 
is a big part of that.

> Therefore, we're off by a factor of 2 at the bottom then we'll waste 50%
Seems reasonable.

> when we'd be wasting Mbps when requesting faster rates, IMO.)
I'm not sure how you compare these, I think it needs to be considered as 
a fraction of the total link capacity.

> the rates we're talking about.

That's the argument, think, discuss (if need), and then decide,

Gorry

---

From: Mark Allman <[email-masked]>
Date: Tue, 13 Jun 2006 09:22:03 -0400

Gorry-

> > My hit here is that the 80kbps value is actually fine.  The host
> > that wants 40kbps can request 80kpbs.  If it would get 40 and not 80
> > then I am not quite sure if I care too much.  I.e., the network must
> > be pretty close to the edge.
> >
> I think "how close" you feel to the edge, depends on the
> ingress/egress capacity you expect to see in your router. If the
> capacity were a few 100's kbps, rather than Mbps or Gbps, then you'd
> maybe care.

Point taken.

Let me try a couple of numbers and a virtual envelope ... The standard
initial window will get >= 40kbps for RTTs that are <= 855msec.  That's
a long RTT.  I know there are networks with longer RTTs.  Not only do
you need to have such a long network, but you also have to have an app
that wants to send between 1 and 40kbps and no more.  For me, this is a
very small corner case.  But, that is just me.

allman

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 15 Jun 2006 14:55:48 +0100

So I'm thinking about non-TCP applications, such as media streams:
To me, VoIP traffic of the order of 20-40 kbps doesn't perhaps appear 
that odd.

Gorry

---

From: Mark Allman <[email-masked]>
Date: Thu, 15 Jun 2006 10:15:47 -0400

> So I'm thinking about non-TCP applications, such as media streams: To
> me, VoIP traffic of the order of 20-40 kbps doesn't perhaps appear
> that odd.

Even for things like TFRC and DCCP we have mapped TCP's initial sending
rate onto them, right?  And, that standard initial rate is >= 40kbps
until the RTT gets longer than 855msec (or >= 20kbps until the RTT is
longer than 1.7sec).  

Or, to go the other way to even be worthwhile to request the current
lowest rate of 80kbps the RTT needs to be at least 427msec.  (I.e., if
the RTT is lower then the standard initial sending rate will be faster.)

These RTTs seem to me to make these things very much corner cases.

I think we're going to have to agree to disagree here.  If others have
an opinion, please jump in.

allman