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 wrote:
> Many thanks to everyone also on my behalf, and particular thanks to Gorry and
> Colin wh
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 need
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
> To: 'dccp' working group
>
> Reminde
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 t
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, July 29, 200
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 orig
I have looked at the changes and I am happy with them.
Arjuna
> -Original Message-
> From: dccp-boun...@ietf.org [mailto:dccp-boun...@ietf.org] On Behalf Of
> Sally Floyd
> Sent: 10 May 2009 20:48
> To: go...@erg.abdn.ac.uk
> Cc: Eddie Kohler; 'dccp' working group
> Subject: Re: [dccp] Co
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 [RF
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
> Su
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 comm
There were no technical issues found. If anyone has any other issues such as
scheduling, or identifying data-limited intervals - then it would be good to
know.
Some NITs are listed below:
---
General changes:
Isn't -> is not
Don't -> do not
Dear Sally,
Just to avoid ambiguity, in 3448-bis, would it be better to change
data-limited to application-limited? This would conforms to RFC2861.
Regards
Arjuna
---
Dr.Arjuna Sathiaseelan
Electronics Research Group
University of Aberdeen
Aberdeen AB24 3U
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 h
Dear Emmanuel,
That's interesting to know. What was the target application?
I would be interested to see the results.
Regards
Arjuna
> -Original Message-
> From: Emmanuel Lochin [mailto:[EMAIL PROTECTED]
> Sent: 16 August 2007 22:31
> To: Arjuna Sathiaseelan
> Cc:
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 cou
Dear Ingemar,
Let me try to answer you using my novice "simulation" experience with VoIP
over DCCP :).
As of now we have three main CCID's:
1) CCID-2: TCP like
2) CCID-3: TFRC like
3) CCID-3 TFRC-SP like
Then we have extensions which could become "experimental" standards such as
Faster Restart
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 implement
>From the simulation point of view, we have been constantly revising the code
to accommodate the latest revisions of the draft. We at UoA havent
implemented the FR algorithm yet.
Arjuna
-Original Message-
From: Ian McDonald [mailto:[EMAIL PROTECTED]
Sent: 16 July 2007 05:32
To: Arj
Some thoughts on improving the Faster Restart draft
(http://www.ietf.org/internet-drafts/draft-ietf-dccp-tfrc-faster-restart-02.
txt) :
1) I have two thoughts about using the receiver rate adjustment algorithms:
* I believe that we may not need the receiver rate adjustment
alg
I am happy with the changes made and I have no other issues pertaining to
this draft :)
Arjuna
--
Colin Perkins
http://csperkins.org/
FYI
-Original Message-
From: Dah Ming Chiu [mailto:[EMAIL PROTECTED]
Sent: 27 March 2007 10:35
To: Arjuna Sathiaseelan; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; dccp@ietf.org
Subject: Re: [e2e] Small packets - Definition needed..
A natural reason for discussing "small"
Dear Tom,
>OK, so at least two of us agree that DCCP SHOULD NOT generate DCCP-Data
>packets on its own (zero length or otherwise) :-).
:)
>Therefore it seems to me that applications MAY use zero-length packets
>as they see fit. The question left is "is RTP an application?" To me,
>RTP has ma
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
434
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 PROTECTED]
I have some doubts.
The question is Who has control over Who? Does the application layer control
the transport protocol, or do transport protocols have their own autonomy?
So if the application does'nt send any data, should the transport protocol
send keep alives by its own judgement or should t
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 no
payload is a good place to start.
Joe
-------
From: David P. Reed [mailto:[EMAIL PROTECTED]
Sent: 23 March 2007 14:20
To: Arjuna Sathiaseelan
Cc: [EMAIL PROTECTED]
Subject: Re: [e2e] Small packets - Definition needed..
576 is a lovely number of octets. I first encounte
Very good job by Aaron :). Thanks a lot.
- Arjuna
-Original Message-
From: Gorry Fairhurst [mailto:[EMAIL PROTECTED]
Sent: 26 March 2007 11:22
To: [EMAIL PROTECTED]; dccp@ietf.org
Subject: [dccp] WG notes from IETF-68 for DCCP WG
Copies of the slides and notes of the meeting are now av
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 ma
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 underlyin
Dear Sally,
Thanks for your prompt reply :)
>The previous draft (draft-ietf-dccp-rfc3448bis-01.txt) didn't ignore the
>feedback packet in this case. But it didn't get it right for this case
>either.
I guess I need to make sure I get my wordings right :). I meant the draft
submitted to the las
ack packet is NOT ignored.
I guess this would solve the problem of the sending after an idle period.
Regards
Arjuna
-Original Message-
From: Sally Floyd [mailto:[EMAIL PROTECTED]
Sent: 19 March 2007 19:16
To: Arjuna Sathiaseelan
Cc: 'DCCP mailing list'; 'Gerrit Renker&#x
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: [dccp]
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 data
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 McDo
AIL PROTECTED]> wrote:
Arjuna:
Arjuna Sathiaseelan wrote:
> Dear Eddie,
> Thanks for your reply..Ok - the way I saw this problem was like this:
>
> Say the sender is idle for 1.5 RTTs and then sends 2 packets, then
> when the feedback is received, then the following part of
he straightforward "X_recv /= 2" common
when the sender is sending. Can you tell us where you got the calculation you
listed below?
Eddie
Arjuna Sathiaseelan wrote:
> If the sender had been idle or datalimited, then the minrate is
> calculated as:
>
> If (sender has been idle o
If the sender had been idle or datalimited, then the minrate is calculated as:
If (sender has been idle or data-limited)
min_rate = max(2*X_recv, W_init/R);
Else
min_rate = 2*X_recv;
But I guess we have overlooked the possibility that loss event rate p
I came across this mail - which may be useful for this discussion:
http://www.postel.org/pipermail/end2end-interest/2004-November/004402.html
Regds
Arjuna
On 1/1/07, Arjuna Sathiaseelan <[EMAIL PROTECTED]> wrote:
> *For links with large RTTs, then having a min RTO may give better
&g
*For links with large RTTs, then having a min RTO may give better
tolerance levels for bursty applications and the application designers
would luv it! :)..
I dont understand how we could have a min RTO of 100 ms for links with
large delays..is this for default or for all cases??
Ok - I think I g
2) Should TFRC define a MINIMUM value for the timer?
- Some arguments for a small timer value include faster congestion
responses to loss, lower cost (if processing can be co-incident with
other protocol activity - but Mark suggested we only need to check in
the send-code anyway?)
- Some argument
This also sounds good to me if VoIP applications use CCID2 instead of CCID 3.
-Arjuna
On 11/6/06, Sally Floyd <[EMAIL PROTECTED]> wrote:
Another possible variant for CCID 2, in addition to allowing
slowly-responding AIMD
parameters, would be to specify a variant of CCID 2 for small-packet
flow
I think this would be a good idea to add this as an option. This
option could be an alternative to interactive applications that use
CCID 3.
-Arjuna
On 11/6/06, Sally Floyd <[EMAIL PROTECTED]> wrote:
It would be a simple change to add an option to CCID 2 to have the
sender use
different AIMD pa
That sounds perfect to me :). Also I hope Sally would note this in her
draft RFC3448-bis too. Thanks Eddie was considering my suggestions :).
Regards
Arjuna
On 10/4/06, Eddie Kohler <[EMAIL PROTECTED]> wrote:
>> - X_inst is always calculated using MSS, as the spec says.
>> - t_ipi is calculated
Dear Eddie,
Thanks for your reply :). Please see inline:
Hello; we may have finally got to the root of the confusion.
Yes :)
HOWEVER, the implementation MUST apply its choice consistently. For
example, the application MUST NOT use average packet size to calculate
X_calc, and simultaneou
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 calcul
that.
If you're interested in pursuing this somehow, let me know and we'll see
what we can do...
Tom P.
> -Original Message-
> From: Arjuna Sathiaseelan [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 03, 2006 9:10 AM
> To: 'dccp' working group
>
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 : +44-1
Dear Vlad and Eddie,
The problem is that voice packets are much smaller than the typical maximal
segment size used by TCP (either determined by Path MTU or set to some
arbitrary value by the vendor). A TCP implementation that disables Nagle's
algorithm can therefore send packets totaling 4380 b
Dear Eddie,
Thanks for your prompt thought provoking reply :). Please see inline:
Re: receive rate adjustment: I wouldn't mind helping Sally include these
algorithms in rfc3448bis, although I don't think it's _necessary_ that they go
there.
I concur. Because rfc3448-bis provides adequate faci
Dear Sally,
Perfect and Thanks for your reply :). You were kind enough to
consider my suggestion seriously and do the necessary changes in ns-2.
Thanks once again :).
Regards
Arjuna
On 9/26/06, Sally Floyd <[EMAIL PROTECTED]> wrote:
Arjuna -
> Thanks for your email..I am sending you a simple
Dear All,
I have been reading the FR draft, Vlad's thesis and his paper, did
some simulation tests and I would like to summarise and also try to
propose certain suggestions from what I have perceived.
1) Minimum Sending Rate:
Vlad's thesis/paper proposes TFRC-SP+FR+MD which sorts out the problem
Dear Eddie,
Thanks for your reply :).
The FIRST feedback packet should not report a particularly low rate since it
is not over very much time.
Hmmm, I dont think so. Say the sender starts with a initial sending
rate of 4 packets per RTT, I guess when the first packet arrives at
the receiver,
and stupid :)
-Arjuna
On 9/24/06, Arjuna Sathiaseelan <[EMAIL PROTECTED]> wrote:
Dear Eddie,
Thanks for your reply :).
> I think you have got it wrong. FR is used whenever a feedback packet is
> received -- the nofeedback timer is not relevant. I would personally approve
> o
Let me be more clear: the first feedback packet after an idle period.
I guess we ignore it?
-Arjuna
On 9/24/06, Arjuna Sathiaseelan <[EMAIL PROTECTED]> wrote:
Dear Eddie,
Thanks for your reply. No, the first feedback is sent with a very
low receiver rate. Do we ignore that feedback
Dear Eddie,
Thanks for your reply :).
I think you have got it wrong. FR is used whenever a feedback packet is
received -- the nofeedback timer is not relevant. I would personally approve
of the use of FR you describe. And I think the draft totally encourages it.
That sounds good to me :)
ing no estimate of receiver rate? Because it's sent in response to
only one packet?
Eddie
Arjuna Sathiaseelan wrote:
> Dear All,
>
> I am in the process of updating the DCCP CCID3 ns-2 code, and would
> like to know what do we do with the FIRST feedback packet. Do we
> ignor
Dear all,
I am quite happy to see that the DCCP mailing list is currently
being active with lots of interesting discussions. So its
time for me to raise an issue on Faster Restart draft
(draft-ietf-dccp-tfrc-faster-restart-01).
We at University of Aberdeen, have been looking at this solution for
Dear All,
I am in the process of updating the DCCP CCID3 ns-2 code, and would
like to know what do we do with the FIRST feedback packet. Do we
ignore it or do we increase the sending rate X by 2*X without
considering the receiver rate X_recv? Increasing it by 2*X seems to
give an aggressive behav
Dear All,
Was going throught the draft rfc-3448-bis-00. I was wondering how
does the sender increase the rate after the first feedback packet
after a nofeedback timer based on the following algorithm?
"If (sender has been idle or data-limited)
min_rate = max(2*X_recv, W_init/R);
Ok I guess its the first feedback packet caused by the first packet
sent after the nofeedback timer. Looks fine :)..
-Arjuna
On 8/18/06, Arjuna Sathiaseelan <[EMAIL PROTECTED]> wrote:
Dear All,
Was going throught the draft rfc-3448-bis-00. I was wondering how
does the sender increase th
look 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:
depending on the packet size (up to 4380 bytes in the initial
burst of three or four packets).
Tom P.
> -Original Message-----
> From: Arjuna Sathiaseelan [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 16, 2006 5:27 AM
> To: 'dccp' working group
> Cc: Gorry
Dear All,
I presume that CCID 3 is still following RFC 3448's slow start
behaviour of 1 packet per second during the start of the connection,
and when the ACK is received for that packet, the INITIAL ALLOWED
SENDING RATE is set to 2 packets to 4 packets per RTT appropriately.
Now my question is
Dear Lars,
Thanks for your reply :)..
> If you hadnt used dummy packets during
> the initial slowstart, then I guess you would have got a large packet
> loss rate! :)..
Sorry, I don't understand - there were no dummy packets.
Ok what I meant was that during the initial slowstart, the sender
Dear Lars,
The paper is very good :)..I just had a few questions:
1)Does the packet loss rate consider the loss of packets due to the
improper synchronization of the application encoding rate and
TFRC-SP's sending rate after silence periods or is it due to loss of
packets due to congestion only?
I have the same concerns here!! :)
-Arjuna
On 7/20/06, Burak Gorkemli <[EMAIL PROTECTED]> wrote:
Hi,
I am currently working on simulating congestion controlled video
streaming on ns2 and I am willing to use DCCP. Hence, I modified ns2
version 2.29 using the patch contributed by Sébastien Linc
Any idea on how comfort noise packets could be used instead of ping
packets to solve this problem?
-Arjuna
On 6/26/06, Eddie Kohler <[EMAIL PROTECTED]> wrote:
Hi all,
Thanks for your very helpful feedback on faster restart. I've submitted a new
version of the draft, it should appear eventuall
Kohler <[EMAIL PROTECTED]> wrote:
Hi Arjuna,
I would LOVE LOVE LOVE LOVE to see your faster restart ns-2 implementation!!
Can you send a link to the list?
Arjuna Sathiaseelan wrote:
> Hi Tom,
> That's exactly what I found out when I implemented faster restart in
> ns-2 and did
I have got another question :).Quite a fundamental one too - related to my previous posts on what happens during a nofeedback timer expiry during slowstart:
" RFC 3448 states,
1) If (X_calc > 2*X_recv)
X_recv = max(X_recv/2, s/(2*t_mbi));
Else
X_recv
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 feedbac
pect the nofeedback timer to cause the
connection to leave slow start, but I'm not sure what the resulting max
transmit rate would be. Normally it'd be half the rate in the last RTT,
but that was zero in this case, since the app went idle. Sounds worth
investigating...
Tom P.
>
Also would like to add - I used TFRC-SP for my simulations.
-Arjuna
On 5/5/06, Arjuna Sathiaseelan <[EMAIL PROTECTED]> wrote:
Hi Tom,
That's exactly what I found out when I implemented faster restart in
ns-2 and did some tests :)..With a CBR source modelling a G.711 codec
sending 5
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 star
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
this up, if they have
less than 8 samples."
Regds,
Arjuna
On 4/20/06, Phelan, Tom <[EMAIL PROTECTED]> wrote:
> Hi Arjuna,
>
> See inline...
>
> Tom P.
>
> > -----Original Message-
> > From: Arjuna Sathiaseelan [mailto:[EMAIL PROTECTED]
> > Se
ns-2 code needs to reflect the change..My
few cents - do correct me if I am wrong :)
-A
On 4/20/06, Arjuna Sathiaseelan <[EMAIL PROTECTED]> wrote:
> Dear Jeroen,
> I concur with your views - I guess this question was raised in the
> recent IETF
> meeting. Maybe someone can sh
Dear Jeroen,
I concur with your views - I guess this question was raised in the
recent IETF
meeting. Maybe someone can shed proper light on this :).
Regds,
Arjuna
On 4/20/06, Jeroen Van Velthoven <[EMAIL PROTECTED]> wrote:
> Dear all,
>
> I am performing some experiments with DCCP/TFRC. Theref
>- Tom: DCCP is in NS.
>
Is the ns-2 code for DCCP and its CCIDs available? If so, pointers please..
Arjuna
79 matches
Mail list logo
