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 arguments for a larger timer include more tollerence to sudden changes in path characteristics (TCP uses a min RTO of 1 sec, RFC2988) e.g. mobility changes or routing changes, and lower load on processing, especially at higher bit rates.
Lets try to see what are the advantages and disadvantages using a 1sec min RTO for TFRC conforming to what TCP does.. Advantages: As Gorry says this gives a greater tolerance to sudden changes in path. Disadvantages: Assume the sending rate was 1Gbps when the application becomes silent..So if after a period of silence < 1 s, the TFRC sender will start sending 1Gbps sending rate (atleast till it receives the next feedback packet)!! I presume, this is how TCP would do as well..but we should also note that these packets would be rate-paced in TFRC whereas for TCP this will be sent as a burst..I wuld say TFRC is definitely fair in this type of a scenario as TCP does the same but in a more drastic manner..(Maybe we should rate-pace TCP packets too after a large silent period less than the min RTO?????) Ok now the question is do we need a min RTO..I am not looking into the implementation issue..I am seeing this from a typical protocol point of view.. Lets classify this into two cases: * Links with Small RTTs * Links with Large RTTs * For links with Small RTTs, having a min RTO of 1 s would be a problem..for the reasons as stated in "disadvantages"..Moreover, I really dont see why need a tolerance of 1 s min RTO since, if there was a nofeedback timer, the TFRC just cuts the rate by half and can rapidly slow-start back to the original sending rate! But if there are frequent nofeedback timeouts then I agree the sending rate could converge towards 0... *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?? IMHO - I dont see how we could converge towards a min RTO at this point of time..this problem has to be looked further..:).. Wish you all a very happy New Year.. Regards Arjuna -- Electronics Research Group University of Aberdeen Aberdeen AB24 3UE Web: www.erg.abdn.ac.uk/users/arjuna Phone : +44-1224-272780 Fax : +44-1224-272497
