Re: [RFC][PATCH] tfrc: Correct 2nd Loss Interval Handling

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

 



Gerrit,

>>
>> [1] http://www.sjero.net/software/dccp/images/dccp_ccid3_2nd_loss_interval_bug.png
>>
> Thank you for the patch and the detailed explanation. Are there before/after test results
> relative to [1] which indicate that the sharp bend in the diagram is now gone, or any other
> notable improvements with this fix?

An example of this same test with this fix applied is at [2]. Of course for this bug to show
up as dramatically as in [1] we need to get a single loss while the connection is sending
very slowly and then not receive another loss until much later.

It's much more instructive to look at the Loss Event Rate Options the DCCP receiver sends. 
(DCCP loss event rate options are sent as 1/loss_rate so a loss rate option of 33 represents
a loss rate of 1/33---1 packet out of every 33 sent)

In the buggy case we see Feedback packets with these options (each line is a feedback packet)
        CCID3 Loss Event Rate: 0 (or max)
        CCID3 Loss Event Rate: 0 (or max)
        CCID3 Loss Event Rate: 33
        CCID3 Loss Event Rate: 33
 	CCID3 Loss Event Rate: 33
 	CCID3 Loss Event Rate: 33
 	CCID3 Loss Event Rate: 33
	....
	CCID3 Loss Event Rate: 33
        CCID3 Loss Event Rate: 33
        CCID3 Loss Event Rate: 18191
        CCID3 Loss Event Rate: 18191

While with my fix, we see this:
	CCID3 Loss Event Rate: 0 (or max)
        CCID3 Loss Event Rate: 0 (or max)
        CCID3 Loss Event Rate: 0 (or max)
        CCID3 Loss Event Rate: 434
        CCID3 Loss Event Rate: 434
	...
        CCID3 Loss Event Rate: 434
        CCID3 Loss Event Rate: 434
        CCID3 Loss Event Rate: 442
        CCID3 Loss Event Rate: 467
        CCID3 Loss Event Rate: 491
        CCID3 Loss Event Rate: 517
        CCID3 Loss Event Rate: 545
        CCID3 Loss Event Rate: 572
        CCID3 Loss Event Rate: 603
        CCID3 Loss Event Rate: 637

You'll notice that with this fix, the loss event rate option starts increasing (i.e. the loss event
RATE decreases) after a while. This means that the 2nd loss interval has become large enough to 
start effecting the loss event rate. In the buggy case, we have to wait until that 2nd loss interval
is closed by the 2nd loss before it can effect the rate, resulting in the large jump seen above.

[2] http://www.sjero.net/software/dccp/images/dccp_ccid3_2nd_loss_interval_fixed.png


Samuel Jero
Masters Student
Computer Science
Internetworking Research Group
Ohio University
sj323707@xxxxxxxx

Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [Linux Kernel]     [IETF DCCP]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]

  Powered by Linux