/
Coupling Discrete Time Events to Continuous Time in RMCAT Coupling Discrete Time Events to Continuous Time in RMCAT

Coupling Discrete Time Events to Continuous Time in RMCAT - PowerPoint Presentation

sherrill-nordquist
sherrill-nordquist . @sherrill-nordquist
Follow
424 views
Uploaded On 2016-07-18

Coupling Discrete Time Events to Continuous Time in RMCAT - PPT Presentation

aka The Anatomy of a RMCAT RTT and Reasonable Bounds on the Time Rate of Change in Available Capacity November 5 2014 Talk Outline Motivation Prior Work On Test Plan Capacity Change Design ID: 410252

rmcat rtt time queue rtt rmcat queue time delay rate capacity change tcp case ack rtcp receiver flow max

Share:

Link:

Embed:

Download Presentation from below link

Download Presentation The PPT/PDF document "Coupling Discrete Time Events to Continu..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.


Presentation Transcript

Slide1

Coupling Discrete Time Events to Continuous Time in RMCAT

(a.k.a. The Anatomy of a RMCAT RTT)

and Reasonable Bounds on the Time Rate

of Change in Available Capacity

November 5, 2014Slide2

Talk Outline

Motivation (Prior Work On Test Plan Capacity Change Design)

RMCAT Discrete Time RTT Formalized

Fluid-flow (continuous-time) model and rigorous RMCAT RTT definition.

Infinitely Fast Capacity Change Downward

Unavoidable delay spike caused by infinitely fast capacity change

How Quickly ANY RMCAT Design Can Track Capacity Changes

R

esult is independent of algorithm type (“self-clocked” or “rate-based”).

Reasonable Assumptions on Time-Rate-of-Change of Capacity

Worse-case RTT defines “tracking responsiveness” (w/o predictive component).

Squelching mechanisms required (self-clocked schemes do this automatically).

TCP Dynamics as a function of their RTT.

A reasonable bound on RTCP feed back intervals.

Implications for Adaptation with Wireless (WiFi/LTE/etc).Slide3

Motivation (Discussion at IETF 90)

Colin Perkins (Last Call on

rmcat-cc-requirements):

However, as

I noted at IETF 90, I think the draft should alsoinclude a secondary requirement to keep delay variation (jitter)down, where possible, since larger delay variation needs largerreceiver-side buffers to compensate, increasing overall latency.

NADAv2

Large

Delay

Spikes

Colin (and others) believed these

might be artifacts of the algorithmsSlide4

A RMCAT Lab Discrete Time RTT (for Seq. No. = Z)

Note: Per-packet Feedback (no RTCP yet)

Gig 0/0.11

192.168.11.2

Router After

Bottleneck

Bottleneck Link

Router Before

Bottleneck

RMCAT

Source

RMCAT

Receiver

=

Z

Receive Timestamp

Step 2:

Receiver Records

Reception of

Z

= ACK Z Receive Timestamp

Step 4:

Records Reception of ACK of Z

Step 1:

Source Sends

Z

= Z Send Timestamp

Bottleneck Direction

= ACK Z Send Timestamp

Step 3:

ACK of Z

sent

t

n-2

t

n-1

t

n

t

k-2

t

k

-1

t

k

time

time

Earliest

Possible

Feedback

Direction of Feedback/ACKs

d

f1

=

Forward

Propagation Delay

Prior

to

Bottleneck

d

f2

= Forward

Propagation Delay

After

Bottleneck

d

r

= Reverse Propagation Delay

d(t) = Queue

Delay at

Continuous

Time t

Modelled

z

ero

receiver

processing

delay

d

proc

= 0Slide5

RMCAT LAB: Measurement Framework

(Seq. No. = Z)

t

n-2

t

n-1

t

n

t

k-2tk-1

tk

time

S

equence number Z sent.

S

equence number Z received (forward delay calculated here).

t

ack,Z

is the earliest time that the queue measurement is available at source (new rate change can occur here).

The time the queue was actually sampled is t

queue,Z

= (t

n

+d

f1

).

t

ack,Z

S

equence number Z-1 sent.

d

f1

d

f1

Let’s define

continuous time t

for fluid-flow modelling of the

rate adaption component. That is, let (t-t

OFFSET

)

represent

times offset from time t.

The

effect

of the rate change on the queue occurs d

f1

after

the sourcemade the rate change (a full RTT after the queue was sampled)!Slide6

RMCAT: Continuous Time Modeling for Control Loop

RMCAT Sender:

Generates

New Rate, r(t)

Queue

RMCAT

Receiver

RMCAT Sender:

Receiver

d

f1

d

f2

d(

t

)

(≈ d

0

at equilibrium)

d

r

d

send_proc

=0

d

pcv_proc

=0

(no RTCP)

r

send

(

t

)

q(t) =

max

[ q( t - ) + (r

at_queue

(t) – C) ,

0

]

For small ;

Queue increases/decreases as difference in rates

Also note:

r

at_queue

(t) = r

send

( t – d

f1

)

d

(t) = q(t)/C

When queue not emptied

, it

integrates the difference

inrates (1/s in Laplace Domain).Slide7

Control Loop: Laplace Domain (linearize about equilibriu

m

)

RMCAT Sender

Queue

RMCAT

Receiver

RMCAT Receiver

e-

s(df2)

P

Q

(s) = Queue Prediction Part

X

R

(s) = Rate Mechanics Part

e-

s(dr)

e-

s(df1)

e-

s(0)

=1

(could

model

a RTCP

mean

delay

of

100ms)

1

e-

s(0)

=1

R(s) = X

R

(s)P

Q

(s)

1/[sC]

Key Control Loop Observations

At Equilibrium:

LTI System => Doesn’t matter where prediction or rate control is (sender or receiver).Wherever it is, it WILL take a minimum of a RTT

1 to make a difference at the queue

.1 – If the RTCP reporting interval is >> (df1+d

f2+dr), it will dominate. If not, it will look like delay noise to individual delay samples.Slide8

So …

W

hat is the

Discrete-Time

RMCAT RTT Definition?RMCAT Sender:

GeneratesNew Rate, r(t)

Queue

RMCAT

Receiver

RMCAT Sender:

Receiver

d

f1

d

f2

d(

t

)

(≈ d

0

at equilibrium)

d

r

d

send_proc

=0

d

pcv_proc

=0

Forward Delay = d

f1

+ { d(t)| } + d

f2

t = t

SAMP

RMCAT RTT (t

i

) | = d

f1

+ { d(t)| }+ d

f2

+ d

r

t = t

SAMP (seq no z)

t

i

= t

ACK

for seq Z received

RMCAT RTT ( t

i

) | = df1 + df2 + dr

+ d(t – [dx + df2 + d

r] ) ,ti

= tACK for seq z received

where d

x = d(t)|

t = tSAMP (seq no z)Slide9

Queue Delay Variation During Downward Capacity Change

Fastest Possible Rate Adaptation Example (imprudently quick)

C

i

C

(i+1)

Assume r(t) = C

i

before t0

t

0Assume rate

control estimates C (i+1) via the

queue sample immediately after t0 and thensends at C(i+1)

(or less) as soon as possible.

t

0

+ RTT

Minimum response time

to affect queue.

Minimum possible

d

elay

spike is caused by

(C

(i+1)

- C

i

) * RTT

too many bits on queue.

Example in IETF RMCAT Test Plan:

Capacity: 2500 kbps -> 600kbps

Assume RTT: 0.200 seconds (100 ms one-way)Minimum ADDITIONAL bits on queue beforewe can do anything about it 380000 bits.

Queue must empty at 600 kbps rate.

Thus minimum delay spike is 633 ms!Note: If we assumed one-way delay of 50 ms, 316

ms is minimum.Slide10

Queue Delay Variation During Downward Capacity Change

Fastest Possible Rate Adaptation Example (imprudently quick)

C

i

C

(i+1)

r(t) = C

i

(queue at equilibrium,

delay at equilibrium is d0)

t0t

0 + RTT

Delay

at

Queue,

d(t)

d

0

[C

i

- C

(i+1)

]

C

(i+1)

d

acc

=

m

1

d

min_spike

= (d

acc

+ d

0

)

Different

Candidate

Responses

integration at queue

To lower

d

min_spike

,

decrease

rate of

change

to new

rate

Minimum delay spike NOT caused by candidates!

* RTT

Accumulated bits delaySlide11

Talk Outline

Motivation (Prior Work On Test Plan Capacity Change Design)

RMCAT Discrete Time RTT Formalized

Fluid-flow (continuous-time) model and rigorous RMCAT RTT definition.

Infinitely Fast Capacity Change Downward

Unavoidable delay spike caused by infinitely fast capacity change.How to avoid the delay spike (proposal could be presented to IETF).

How Quickly ANY RMCAT Design Can Track Capacity ChangesResult is independent of algorithm type (“self-clocked” or “rate-based”).

Reasonable Assumptions on Time-Rate-of-Change of Capacity

Worse-case RTT defines “tracking responsiveness” (w/o predictive component).Squelching mechanisms required (self-clocked schemes do this automatically).TCP Dynamics as a function of their RTT.

A reasonable bound on RTCP feed back intervals.Implications for Adaptation with Wireless (WiFi/LTE/etc).Slide12

C

i

C

(i+1)

t

0

t

0

+ RTT

How Quickly Can RMCAT Track Available Capacity Changes?Answer: It Depends on the RTT, Duh!

The quickest time a RMCAT flow can possibly “measure” (and “react to”)

changes in capacity is bounded by ITS round-trip time.Thus the quickest time it can influence it’s contribution to the queue after

a change in capacity is thus bounded by ITS round-trip time.Corollary: RMCAT flows with different RTTs can react to changes on differenttime scales (which correspond to their individual RTTs). Just like TCP!A reasonable ASSUMPTION for the

fastest

time-rate-of-change in available

capacity is one which could be tracked (i.e., measured and reacted to) by

a

RMCAT flow with

an assumed worst-case RTT

and

RTCP interval

.Slide13

A reasonable assumption bound for RMCAT

time rate of change in available capacity

t

?

t? + RTT

C(t)

C

Local_Max

C

Max_Change

C

Local_Min

Assume worst-case RMCAT RTT of ~250 ms (¼ sec).

Highest capacity change “frequency” that is actionable is f

MAX

≈ 4 Hz.

Capacity changes faster than this CANNOT be “seen/sensed/measured” and then

“actionable” by a RMCAT flow with the “worst-case RTT”.

1

Ditto for ACK-based, “self-clocked”, protocols like TCP, SCReAM too!

TCP can’t know to stop within this time either; as they only stop after their ACKs stop.

TCP thus “pounds the queue” causing gross overflow events on long RTT connections too!

Corollary: “Fast Response” is a matter of the

worst-case capacity

change

assumption

- not a fundamental property of “self-clocked” protocols.

2

2

- Rebuttal to: http://conferences.sigcomm.org/sigcomm/2014/doc/slides/150.pdf

1 – If other information was known (e.g., form), predictive components could react quicker.Slide14

1 TCP, Delay seen by Voice Packets

Near 100% Link Utilization (delay

3

0 ~ 80 ms)

Queue emptied only 4 times*

-Serialization delay for TCP packet ~ 11 ms

Voice Only

RTT Estimate ~ 50ms,

fast reaction per unit time

TCP Dynamics as a Function of the RTT

1 TCP: Voice Delay,

50 ms

BE Queue

Loss-Based Rate Control Overfills Queues

and

CAUSES

substantial loss Slide15

100% Link Utilization (delay 100 ~ 500 ms)

Queue

Never

Emptied

1 TCP, Delay seen by Voice Packets

W

e have loss

with

much larger persistent delays!

Rate dynamics clearly a function of RTT (including queue delay).If capacity downward occurred quickly within RTT near queue overflow, theTCP (control loop) would have behaved similarly to our RMCAT Candidates.

RTT Estimate now

includes queuing delay ...

subsequent rate increase

reaction times are slowed.

TCP Dynamics as a Function of the RTT

1 TCP: Voice Delay,

500 ms

BE QueueSlide16

ACK-Gated RMCAT

Proposals (a la Ericsson) t

0

t

0 + RTT

C(t)

C

Local_Max

C

Max_Change

C

Local_Min

On long-RTT connections, ACK-gated protocols will also hit the queue too

hard and build up excess delay. They will “stop” quickly – but that is a

matter

of degree (by comparison to how rate-based designs) – not

because of some more beneficial property of ACK-gated protocols.

*

Once a worst-case RTT assumption has been made, it imposes a theoretical

constraint on how quickly

ANY RMCAT FLOW

can adapt to it.

Thus imposing a “hidden assumption” on the time-rate-of-change of capacity ANY

RMCAT DESIGN on

the worst-case RTT can adapt to

.

This, in turn, imposes a minimum RTCP spacing constraint:

For 250 ms RTT, <

π

/2 spacing (@4 Hz

)

implies T

RTCP

≤ ~ 62.5 ms. Slide17

Implications for WiFi/LTE/Wireless Adaptation

t0

t

0

+ RTT

C(t)

C

Local_Max

C

Max_Change

C

Local_Min

On long-RTT connections, ACK-gated protocols will also hit the queue too hard and

build up excess delay. They will “stop” quickly – but that is a matter of degree

(by comparison to rate-based approaches) – not because of some more

beneficial property of “self-clocked” protocols over rate-controlled protocols.

Repeated/paraphrased from last slide:

Summary:

We will need to develop better “squelching conditions” in future enhancements to our present RMCAT designs (i.e., when feedback stops and/or becomes irregular).

Complete squelch

is only prudent when there is

no impairment in feedback path

.

Wireless challenges now become

a known second-order problem

; unless we want

to limit RTT (not possible) or go to per-packet feedback (non RTCP approaches).Slide18

Summary

RMCAT Discrete Time RTT Formalized

Fluid-flow (continuous-time) model and rigorous RMCAT RTT definition.

How Quick Can ANY RMCAT Design Can Track Capacity Changes

Result is independent of algorithm type (“self-clocked” or “rate-based”).

Reasonable Assumptions on Time-Rate-of-Change of CapacityWorse-case RTT defines “tracking responsiveness” (w/o predictive component).

Like TCP, dynamics of RMCAT solution will be a function of their RTT.The feedback intervals and flow RTT will determine capacity tracking ability.

Bounding feedback intervals and worst-case RTT effectively bounds best-case tracking.

Implications for Adaptation with Wireless (WiFi/LTE/etc).Squelching mechanisms required (self-clocked schemes do this automatically).