Subject: TEAR.

From: foo <[email-masked]>
Date: Mon, 5 Mar 2001 19:42:52 -0600

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

---

From: Min Sik Kim <[email-masked]>
Date: Mon, 5 Mar 2001 22:19:54 -0600

> http://www.csc.ncsu.edu/faculty/rhee/export/tear_page/

TEAR is one of the four protocols whose transient behaviors we studied in
our infocom 2001 paper.

    Yang, Kim, and Lam, Transient behaviors of TCP-friendly congestion
    control protocols, in Proc. of INFOCOM 2001.
    http://infocom.ucsd.edu/papers/529-3648348157.pdf

-- 
 Min Sik Kim
 http://www.cs.utexas.edu/users/minskim/

---

From: Tianbo kuang <[email-masked]>
Date: Sat, 3 Mar 2001 17:55:01 -0600 (CST)

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)                                  
  [email-masked]                                 
------------------------------------------------------
On Mon, 5 Mar 2001, foo wrote:

> Date: Mon, 5 Mar 2001 19:42:52 -0600
> From: foo <[email-masked]>
> To: [email-masked], [email-masked]
> Subject: [e2e] TEAR.
> Resent-Date: Mon, 5 Mar 2001 19:48:05 -0600
> Resent-From: [email-masked]
> Resent-To: [email-masked]
>

---

From: "Injong Rhee" <[email-masked]>
Date: Tue, 6 Mar 2001 12:01:50 -0500

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: [email-masked]
> [mailto:[email-masked]]On Behalf Of Tianbo kuang
> Sent: Saturday, March 03, 2001 6:55 PM
> To: foo
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [e2e] TEAR.
>
>
> Hi,
>