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

Lars-

Thanks for the comments.  I'll fix up the nits, thanks!

> Given that the text repeatedly states that the impact of this on the
> general Internet is not really known, I assume this is going for the
> "experimental in the sense that we want to experiment with it"-flavor
> of Experimental? 

Yes.

In fact, the really experimental part of it to me is that using
Aggressive Limited Transmit delays the congestion response by an RTT.

(To a lesser degree even the Careful variant of Limited Transmit removes
the standard idle period between detecting "congestion" and resuming
transmission.  But, this seems sort of minor to me.)

> If so, stating prominently in the abstract and maybe introduction that
> this is not ready for production use may be a good idea.

Good call.  I'll add a note.

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

> 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