Subject: Re: [ledbat] clock drift compensation

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 8 Jul 2010 18:06:11 +0200

Hi,

On Friday 11 June 2010 16:40:02 Murari Sridharan wrote:
> I haven't read your paper and the framing itself is out of scope for the
> congestion control document. However one thing that concerns me in your
> findings is that it may take up to 10 minutes to measure base delay. Can
> you explain this better why is there such a bias? If this were true then
> the problem of intra-protocol fairness may be significant. So unless it's a
> fairly long lived flow this bias will be significant and throughput for
> different flows may not converge. Right?
If there is an algorithm describing how to handle the clock drift I think this 
can be part of the congestion control document.
Right now the documents says:

"The expiration of base delay
   related to route changes mostly takes care of clock skew.  A
   technique to specifically compute and cancel it is trivially possible
   and involves tracking base delay skew over a number of minutes and
   then correcting for it, but usually isn't necessary, unless the
   target is unusually low, the skew is unusually high, or the base
   interval is unusually long.  It is not further described in this
   document."

If this is not true (if this case is not unusually), we have to care about.

Mirja

---

From: [email-masked]
Date: Thu, 08 Jul 2010 19:02:45 +0200

> If this is not true (if this case is not unusually), we have to care about.

In my experience, this assumption is at best optimistic. I don't have any real
measurements to show (and I'm not sure I can commit to provide any anytime
soon).

However, the tests that I ran (but failed to properly document) was on a
relatively slow DSL link, where there would be more than 5 minutes of fully
saturated upload between minimum delay packets coming through. My other test was
on a local network where one machine was running quite hot, where the clock skew
was significant (about 15 ms in 8 minutes). It's especially significant with a
target delay of 25 ms. It might be significant that one of the machines were
running hot as well (literally) since that might have affected its clock rate.

Let's consider this data anecdotal.

-- 
Arvid Norberg

---

From: "Rolf Winter" <[email-masked]>
Date: Fri, 9 Jul 2010 11:36:51 +0200

Hi,

I not sure this is anecdotal. It is however a rather limited data set you have there. Do the BitTorrent folks have more data on this? What is the clock skew you see in the wild?

Best,

	Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Donnerstag, 8. Juli 2010 19:03
> To: Mirja Kuehlewind
> Cc: [email-masked]
> Subject: Re: [ledbat] clock drift compensation
> 
> > > the problem of intra-protocol fairness may be significant. So
> unless it's
> > a
> > If there is an algorithm describing how to handle the clock drift I
> think
> > this
> _______________________________________________
> ledbat mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ledbat