RE: CCID 3 - Slow Starting with One packet per second..

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Arjuna,

By my reading of RFC 4342, it seems to be talking about the *initial*
sending rate -- that would be before you know what the RTT is.

Is this confusion over initial sending rate of 1 packet/second instead
of 1 packet/RTT?  They're functionally equivalent -- as soon as you get
feedback from the receiver you're next rate is 2 packets/RTT (per
RFC3448).  For CCID 3, the initial rate is up to 4 packets per second or
RTT -- however you wish to look at it -- and after feedback it's up to 8
packets/RTT.

Tom P.

> -----Original Message-----
> From: Arjuna Sathiaseelan [mailto:arjuna.sathiaseelan@xxxxxxxxx]
> Sent: Wednesday, August 16, 2006 10:17 AM
> To: Phelan, Tom
> Cc: 'dccp' working group; Gorry Fairhurst
> Subject: Re:  CCID 3 - Slow Starting with One packet per
second..
> 
> Hi Tom,
>   Thanks for your reply :). Yes it does, but I thought it was only
> after it has got a RTT sample (which is got by setting the rate to one
> packet per SECOND, sending that packet and when the feedback is
> received) and then setting to 2 or 4 packets per RTT? RFC 4342 says:
> 
> "[RFC3448], Section 4, specifies an initial sending rate of one packet
>    per round-trip time (RTT) as follows: The sender initializes the
>    allowed sending rate to one packet per second.  As soon as a
feedback
>    packet is received from the receiver, the sender has a measurement
of
>    the round-trip time and then sets the initial allowed sending rate
to
>    one packet per RTT.  However, while the initial TCP window used to
be
>    one segment, [RFC2581] allows an initial TCP window of two
segments,
>    and [RFC3390] allows an initial TCP window of three or four
segments
>    (up to 4380 bytes).  [RFC3390] gives an upper bound on the initial
>    window of min(4*MSS, max(2*MSS, 4380 bytes)).
> 
>    Therefore, in contrast to [RFC3448], the initial CCID 3 sending
rate
>    is allowed to be at least two packets per RTT, and at most four
>    packets per RTT, depending on the packet size.  The initial rate is
>    only allowed to be three or four packets per RTT when, in terms of
>    segment size, that translates to at most 4380 bytes per RTT."
> 
> Am I confused? :)
> 
> Regds
> Arjuna
> 
> On 8/16/06, Phelan, Tom <tphelan@xxxxxxxxxxxx> wrote:
> > Hi Arjuna,
> >
> > CCID3 allows an initial sending rate of at least two and up to four
> > packets 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:arjuna.sathiaseelan@xxxxxxxxx]
> > > Sent: Wednesday, August 16, 2006 5:27 AM
> > > To: 'dccp' working group
> > > Cc: Gorry Fairhurst
> > > Subject:  CCID 3 - Slow Starting with One packet per
second..
> > >
> > > 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 do we still need to follow TFRC's way of
starting
> > > with one packet per second to determine the RTT estimate? Since,
DCCP
> > > has its initial three way handshake similar to TCP, can CCID3  use
the
> > > handshake to determine the RTT and start with an initial allowed
> > > sending rate set to 3 or 4 packets accordingly?
> > >
> > > Based on this paper, using the SYN/ACK, RTT could be accurately
> > measured.
> > > http://www.acm.org/sigs/sigcomm/ccr/archive/2002/jul02/ccr-2002-3-
> > > jiang.pdf
> > >
> > > I guess starting with one packet per second ,  induces an
additional
> > > RTT's worth of delay which may not be good for certain
applications
> > > such as VoIP running over a satellite network..
> > >
> > > Correct me if I am wrong..thanks
> > >
> > > --
> > > Regards,
> > > Arjuna
> > >
> > > Postdoctoral Researcher
> > > Engineering Research Lab,
> > > Department of Engineering,
> > > University of Aberdeen
> >
> >
> 
> 
> --
> Regards,
> Arjuna
> 
> Postdoctoral Researcher
> Engineering Research Lab,
> Department of Engineering,
> University of Aberdeen



[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux