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

[Lars Eggert <[e-mail]>]

Hi,

On Jan 20, 2006, at 21:17, Mark Allman wrote:
>> One question regarding fairness:
>
> I am confused about what you're reading here.  I.e., the draft has no
> figures, the quote below isn't from the draft and I don't think we  
> even
> discuss fairness in the i-d.

oops, I meant to add that I got this from [BR04] before I hit  
"send." (I started thinking about the fairness stuff when reading the  
draft and then dug through the refs to find an evaluation.)

>> 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).

Yup.

>   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.

Yup.

> 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.

Right - iff the other flow still got its 1/4. I'm wondering if this  
will always (or at least usually) be the case. What if we had a long,  
fat path where the non-DCR flow would need a long time to get back to  
1/2 - could the DCR flow actually delay that even more? Maybe not or  
not by much, but I'd still feel better if there was some sort of  
experimental results.

>   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.

Right, that was sort of what popped up in my head when reading this.

>> 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?

Sumitha's Networking 2004 paper [BR04], but I just saw in Section 4  
that the mechanism may have changed since then - that pub was about DCR.

Also, note that I don't think this question is a showstopper for  
going forward with the draft as Experimental. It's one more question  
that should be looked at when experimenting with this.

Lars
--
Lars Eggert                                     NEC Network Laboratories

_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm