Re: [tcpm] WGLC: NCR draft-ietf-tcpm-tcp-dcr-06.txt ENDS 27 Jan 2006

Awesome footwork, Mark!

I've been out of the loop for a while, so can someone
please refresh me on the requirement for fairness.

I understand the requirement to prevent the next
Internet meltdown, but not a requirement for fairness.

Mark Allman wrote:
> 
>>If there's a DCR flow and a non-DCR flow sharing a path that reorders
>>packets a bit, wouldn't the reordering tolerance of the DCR flow cause
>>it to steal bandwidth from the non-DCR flow?
> 
> 
> This is not clear to me.  In fact, it's not clear to me exactly how
> fairness comes into this.  If there were 2 flows over some path and no
> reordering then we'd expect them to see about the same performance
> (about half the bandwidth).  Now, if there was reordering and neither
> did NCR then they would each get less than half the bandwidth -- say
> they each got 1/4 the bandwidth, just to put some numbers on things.
> So, now the reordering is causing a 50% slowdown in the flows and less
> than full utilization.  Now, if one of the flows were to use NCR and it
> were to get more than 1/4 the bandwidth that would seem fine to me.
> And, in fact, the NCR flow could get up to 3/4 of the capacity and I
> wouldn't think that was unfair at all --- even though the rates are
> quite different.  I.e., the NCR flow is using what is available.  Now,
> if the NCR flow ended up with 7/8 of the capacity and drove the non-NCR
> flow to 1/8 of the capacity ... well, then there is a question.  In some
> sense, the NCR flow is stealing from the non-NCR flow, for sure.  Will
> this happen?  I am not sure.  Is there a way to minimize it?  I don't
> know.  Is this a natural part of trying to make progress and an
> incentive for stacks to combat reordering?  Perhaps.  This could all be
> part of the experiment. 
> 
> 
>>The paper says "it is to be noted that the reason for TCP-DCR
>>realizing better throughputs (when packets are reordered) is not due
>>to unfairness, but due to correctly recovering from the reordering
>>events." Maybe I'm dense, but I don't see the experimental data to
>>back this up. Is the throughput for SACK shown in Figure 4 identical
>>when competing only against other SACK flows? Is the dynamic behavior
>>roughly the same?
> 
> 
> Where is this from?
> 
> Thanks again!
> 
> allman

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm