Subject: [AVT] Faster Start after idle periods

From: Eddie Kohler <[email-masked]>
Date: Mon, 08 Dec 2003 18:10:27 -0800

[Replies to [email-masked] only please.]

Sally and I talked today about the slow-starting after an idle period.  We
have a potential solution that doesn't involve sending filler traffic to
keep the pipe open.

Say your app had a sending rate of K packets/RTT. Then you have an idle
period, possibly up to several minutes; and you want to start sending
again.
(1) Start sending with a window of 8 packets/RTT (not 4).
(2) Increase the window size by 4x after each lossless RTT (not 2x).

This is twice as fast as slow start.  But the multiplicative factor means
that if slow start reached a rate in N RTTs, faster start would reach the
same rate in sqrt(N) RTTs.  A window of 128 packets/RTT is reached after 2
lossless RTTs (for a large RTT of 100ms and maximum-size packets, this is
>14Mb/s after .2s).

The theoretical justification for this is that the connection recently
proved it could sustain rate K on this path.

Caveats:
(1) You must switch out of faster start (to slow start) once you reach the
    original rate K.
(2) You must switch out of faster start (to AI) after any congestion event.
(3) You can't use faster start if your last faster-start encountered
    congestion, and didn't achieve the original rate K.  (Slow start
    instead.)
(4) You probably can't use faster start if you didn't actually sustain rate
    K for long before.
(5) Possibly others.

It's not immediate-start.  It doesn't change the slow start that the
connection must go through initially.  It does greatly improve the dynamics
of DCCP connections that go idle (push-to-talk, interactive media), without
requiring filler traffic.

Details remain to be ironed out.  Help or simulations welcome.  Comments
welcome too.

Eddie

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Eddie Kohler <[email-masked]>
Date: Mon, 08 Dec 2003 18:16:26 -0800

> ...

I forgot to mention:
(4.5) You'll have to send "pings" -- one packet an RTT or so -- to verify
    that connectivity still exists.  In many cases the acks you send for
    the other endpoint's data will suffice.

---

From: "David R. Oran" <[email-masked]>
Date: Tue, 09 Dec 2003 11:16:58 -0500

Define "idle period".

If I'm on a conference call, announce the speaker, then listen for 2 hours 
of rambling, and then speak up to ask "any questions"? is that restart 
after idle?

It seems to me there are some very tricky time constants here.

how does this differ from HTTP tearing down a TCP connection to a web site 
and then putting up another one to the same site on the next click and 
claiming that it doesn't need to do slow start because the browser is "just 
coming back from an idle period".

If DCCP is allowed to keep congestion state across idle periods, then 
shouldn't TCP too?

We keep cycling around the core issue which is the claims by some in the 
community that realtime interactive media does not work acceptably well if 
it has to be congestion-responsive in its transmission rate, and the 
contention by others that some clever adaptive rate control can work well 
enough.

I think we need existence proofs of a system that does rate-adapt 
successfully before recommending the use of DCCP in preference to UDP.

What would be even MORE helpful would be practical policing/dropping 
algorithms on bottleneck links that dropped ALL packets of a subset of the 
flows rather than RED or WRED across all the flows. That way a 
measurement-based admission control scheme might have a chance of keeping a 
subset of the realtime flows going with acceptable loss/delay during 
congestion.

Dave.

--On Monday, December 8, 2003 6:10 PM -0800 Eddie Kohler <[email-masked]> 
wrote:

> (2) You must switch out of faster start (to AI) after any congestion
> event. (3) You can't use faster start if your last faster-start
> encountered     congestion, and didn't achieve the original rate K.
> (Slow start     instead.)
> (4) You probably can't use faster start if you didn't actually sustain
> rate     K for long before.
> (5) Possibly others.
>
> connection must go through initially.  It does greatly improve the
> dynamics of DCCP connections that go idle (push-to-talk, interactive
> media), without requiring filler traffic.
>

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 09 Dec 2003 21:11:57 -0600

......

> successfully before recommending the use of DCCP in preference to UDP.

Not only that, we need to also show that RTP/DCCP can outperform RTP/UDP in
whatever terms before the vendors and SPs can see any incentives to spend money
for the switch. This is not going to be easy considering what's been happening
for IPv6. There needs to be an IETF "official" list of incentives for adopting
DCCP composed eventually. Just telling the vendors and SPs that UDP is
unfriendly to TCP traffic won't cut it, IMO.

AVT probably should wait to see such an "incentive list" composed before diving
into migrating payload RFCs to DCCP.

regards,
-Qiaobing

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 10 Dec 2003 09:53:36 +0100

Hi Qiaobing,

I reacted to this:

> into migrating payload RFCs to DCCP.

There should be no reason to do any changes to the RTP payload formats 
due to that one transport RTP over DCCP instead of UDP. So far the 
discussion has not shown any need to do any changes to RTP at all.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Wed, 10 Dec 2003 09:19:35 +0000

[since this is now about payload formats, I'll limit the cc to avt - please
 try to avoid cc'ing both lists]

--> Magnus Westerlund <[email-masked]> writes:
> Qiaobing Xie wrote:
> > AVT probably should wait to see such an "incentive list" composed
> > before diving into migrating payload RFCs to DCCP.
> 

I can certainly imagine that some payload formats could use the improved
loss feedback that DCCP provides. We yet haven't identified any need for
changes to RTP payload formats, but I wouldn't necessarily rule them out.

Colin