For me in particular - this wg is special - my career started out of
this this..So thanks to my idol Sally Floyd, Gorry and all the
others..
Regards
Arjuna
On 26 November 2012 09:24, Pasi Sarolahti pasi.sarola...@iki.fi wrote:
Many thanks to everyone also on my behalf, and particular thanks to
Dear All,
Please find our latest paper entitled TCP-Friendly Rate Control
(TFRC) for bursty media flows @
http://www.sciencedirect.com/science/article/pii/S0140366411001551
Our paper presents an indepth analysis of RFC 5348 and Faster Restart
and also concludes that Faster Restart is not
Dear Pasi,
I have gone through this draft and I am happy to support this..
Regards
Arjuna
Original Message
Subject: [dccp] Fwd: WGLC for draft-ietf-dccp-tfrc-rtt-option
Date: Mon, 21 Feb 2011 12:04:42 +0200
From: Pasi Sarolahti pasi.sarola...@iki.fi
To: 'dccp' working
of these topics might be better for ICCRG, but the idea as I
understand it is for DCCP and ICCRG to work together on these sorts
of things.
Tom P.
From: dccp-boun...@ietf.org [mailto:dccp-boun...@ietf.org] On Behalf
Of Arjuna Sathiaseelan
Sent: Wednesday
Please see inline..
[Tom P.] Well, this isn't a very interesting case -- the app has
voluntarily switched to a lower rate?
Yes that's right -- I just gave an example on how a CCID-3 sender could grow
its sending rate..
The interesting case is when the
app has been forced to switch to the
Dear Bryan,
DCCP's CCID's do probe for capacity for e.g. CCID 3 (which follows TFRC)
would allow the sender to send upto twice the receiver rate or that allowed
by the throughput equation (which ever is small) and hence its upto the
application to decide whether to retract back to its
Dear Sally and All,
I support this document.
Some NiTs in the document:
The headings from page 10 are not aligned properly.
3.1 Relationship with TFRC and TFRC-SP
This document is based on CCID 3 [RFC4342], TFRC, and TFRC-SP. For TFRC,
RFC 3448 [RFC3448] has been obsoleted by RFC 4342
Dear Sally,
Thanks a lot for your feedback. We shall do the suggested changes. Thanks
once again.
Regards
Arjuna
-Original Message-
From: Sally Floyd [mailto:sallyfl...@mac.com]
Sent: 23 March 2009 01:33
To: Gorry Fairhurst; Arjuna Sathiaseelan; dccp group
Subject: feedback
I have read this new version of the draft and I support it.
Arjuna
-Original Message-
From: dccp-boun...@ietf.org [mailto:dccp-boun...@ietf.org] On Behalf Of
Gorry Fairhurst
Sent: 14 March 2009 08:10
To: 'dccp' working group
Cc: Eddie Kohler
Subject: [dccp] Please send comments
Dear Ingemar,
I recall that the RTT for satellite links is ~560ms, I would expect that
Wimax has a shorter RTT.
I am not sure about this - but I do remember from a presentation I attended
(by BT), that tests showed that Wimax had similar or even longer RTTs than
satellite links..
Do you
Dear Ingemar,
Please see inline..
1) What is the definition of large idle period
RFC3448-bis states that a long idle period is worth an RTO which means
4*RTTs.
2) How often is feedback sent? (sorry for a question that I should
probably answer myself by means of some RTFM) but if you could
McDonald [mailto:[EMAIL PROTECTED]
Sent: 25 July 2007 10:27
To: Sally Floyd
Cc: Eddie Kohler; dccp group; Arjuna Sathiaseelan
Subject: Re: [dccp] I-D ACTION:draft-ietf-dccp-tfrc-faster-restart-03.txt
On 7/24/07, Sally Floyd [EMAIL PROTECTED] wrote:
Have started work on implementing this for Linux
Dear Sally (CCing to the DCCP mailing list too),
Further to our offline conversations regarding calculating the receiver rate
after long idle periods, where the 3448bis clearly states that the receiver
rate is calculated only for R_m seconds where R_m is the receiver's estimate
of the RTT, I
Dear Tom,
I agree with you on this issue, and I guess we SHOULD have a new packet
type called DCCP-Alive packet, that could be used for DCCP level
keep-alives, rather than using zero bytes DCCP-Data packets.
Regards
Arjuna
-Original Message-
From: Phelan, Tom [mailto:[EMAIL
Regarding using zero bytes data packets, the FR draft
(http://www.ietf.org/internet-drafts/draft-ietf-dccp-tfrc-faster-restart-02.
txt) mentions:
To that end, this document modifies RFC 4340's behavior with respect to
zero-length application data area DCCP-Data and DCCP-DataAck packets. RFC
Dear Colin,
Thanks for your reply. I am happy with this change.
Are others happy with this change or any more suggestions regarding
keep-alives?
Arjuna
-Original Message-
From: Colin Perkins [mailto:[EMAIL PROTECTED]
Sent: 21 March 2007 13:20
To: Arjuna Sathiaseelan
Cc: 'DCCP mailing
Dear Colin,
As discussed during the meeting, I would like to remind you that the
following paragraph from Section 4.1
(http://www.ietf.org/internet-drafts/draft-ietf-dccp-rtp-04.txt) requires a
sentence or two stating that the probing mechanism described is under the
assumption that the
I still believe the Limited recv rate does not solve the problem. I shall
address this problem tomorrow in the meeting for Sally's view.
Arjuna
-Original Message-
From: Gerrit Renker [mailto:[EMAIL PROTECTED]
Sent: 19 March 2007 15:54
To: Sally Floyd
Cc: DCCP mailing list
Subject:
Dear Sally,
Thanks for your reply. Yes I agree with you :). The sending rate
will be rate limited upto the rate calculated by the throughput
equation. Hence this is not an issue :).
Regards
Arjuna
On 3/5/07, Sally Floyd [EMAIL PROTECTED] wrote:
Arjuna -
If the sender had been idle or
Hi Ian,
Some questions:
1)Do you drop the packets from the transmit buffer?
2)Is X_recv = 0, since the sender does not send any packets?
If 1) and 2) right - isnt this an idle period scenario?
Or are u dropping packets in the middle after the sender has sent it?
-Arjuna
On 2/15/07, Ian
After a long discussion with Gerrit, I would just like to point out
two things that needs to be fixed in TFRC/CCID3:
1) Make it explicit to use a consistent s throughout the drafts/RFCs.
- The reason why we see this as a problem is because of two things:
* The Initial rate
I would like to know what is the status of Tom Phelan's proposed Media
Friendly Rate Control. Is is the draft active?
-Arjuna
--
Dr.Arjuna Sathiaseelan
Electronics Research Group
University of Aberdeen
Aberdeen AB24 3UE
Web: www.erg.abdn.ac.uk/users/arjuna
Phone : +44-1224-272780
Fax :
at it -- and after feedback it's up to 8
packets/RTT.
Tom P.
-Original Message-
From: Arjuna Sathiaseelan [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 16, 2006 10:17 AM
To: Phelan, Tom
Cc: 'dccp' working group; Gorry Fairhurst
Subject: Re: [dccp] CCID 3 - Slow Starting with One
It appears that the first data packet sent after exiting the
idleness state will determine the receiver to respond with a feedback,
containing a quite low value of X_recv (the number of bytes received is
divided by the entire duration of the idleness period, or the duration
since the last
I would like to add something here..Its a doubt..
I am wondering what happens where there is an idle period during slow
start where the nofeedback timer has expired - with p = 0. Faster
restart wouldnt work with the given algorithm - since it doesnt make
any changes to the existing TFRC slow
Dear Tai,
I have not been working on CCID 2..So I am not sure about your
questions..But I am not sure whether DCCP would have better throughput
compared to SACK - since it depends on how u calculate ur
throughput..As throughput is the total no of bytes transmitted in unit
time, this includes the
- Tom: DCCP is in NS.
Is the ns-2 code for DCCP and its CCIDs available? If so, pointers please..
Arjuna
27 matches
Mail list logo
