[e2e] TEAR.

Injong Rhee rhee at eos.ncsu.edu
Tue Mar 6 09:01:50 PST 2001


Hi,

I can't help overhearing, and want to drop a few lines. The RTT calculation
can be done by the sender through receiving the receiver report about the
rate. The receiver sends back the time stamp of the last packet received to
the sender with the sequence number which will be used by the sender to
compute the RTT. This is one way to do it, and there are  many other ways.
For instance, you can use the same way that RTP does or use GPS to
synchronize the clocks and measure the one-way time. Then use the one-way
trip time in place of RTT -- I know in this case that TCP-friendliness may
suffer, but it can at least give some bounded fairness. In fact this removes
back-channel concerns completely from flow control scuh as losses and delays
in the back channels.

Some of nice things about TEAR are that (1) it does not use back channels
much so sutiable for wireless comm; (2) rate control is very smooth; (3)
TCP-friendly over various ranges of bandwidth --- TFRC has some prblems
under very low bandwidth cases.

We have improved TEAR quite bit from the initial work and  TEAR is
incorporated into an MPEG-4 stream player and stream server, and it seems to
give pretty good performance over other existing streaming solutions. Other
areas of exploration are multicast and wireless communication. Sorry I have
not kept you guys up to date about the progress. I got tired of writing
papers and have been digging into writing codes.....Maybe its time to come
out and see the light :-)

Injong


> -----Original Message-----
> From: end2end-interest-admin at postel.org
> [mailto:end2end-interest-admin at postel.org]On Behalf Of Tianbo kuang
> Sent: Saturday, March 03, 2001 6:55 PM
> To: foo
> Cc: end2end-interest at ISI.EDU; tcp-impl at lerc.nasa.gov;
> end2end-interest at postel.org
> Subject: Re: [e2e] TEAR.
>
>
> Hi,
>
> I was just about to ask a question about TEAR. It seems unclear to me how
> TEAR calculates RTT in the technical report (TEAR: TCP emulation at
> receivers - flow control for multimedia streaming). Does the sender
> calculate it and send it to the receiver, or does the receiver calculate
> it (and how?)? In section 3.5, it does mention under the title _timeout_
> that, "this information is embedded in the packet header by the sender".
> What does "this information" refer to?
>
> Cheers,
>
> --Tianbo
>
> ------------------------------------------------------
>   Kuang Tianbo
>   TRlabs
>   111-116 Research Drive
>   Saskatoon, Saskatchewan S7N 3R3
>   Tel: (306) 668-9325(office) (306) 343-9747 (home)
>
>   kuang at sask.trlabs.ca
> ------------------------------------------------------
> On Mon, 5 Mar 2001, foo wrote:
>
> > Date: Mon, 5 Mar 2001 19:42:52 -0600
> > From: foo <foo at eek.org>
> > To: end2end-interest at ISI.EDU, tcp-impl at lerc.nasa.gov
> > Subject: [e2e] TEAR.
> > Resent-Date: Mon, 5 Mar 2001 19:48:05 -0600
> > Resent-From: foo at eek.org
> > Resent-To: end2end-interest at postel.org
> >
> > Does anyone have any experience with or thoughts about TEAR
> (TCP Emulation
> > at Receivers) developed by Injong Rhee at NCSU?
> >
> > http://www.csc.ncsu.edu/faculty/rhee/export/tear_page/
> >
> > -Brian
> >
>
>




More information about the end2end-interest mailing list