Re: [tcpm] rfc2581bis-01 and RFC 2861

> > > Yes.  One could argue that the faster increase (the traditional
> > > approach) is inappropriate, but it is a pretty small effect (and, it
> > > can cut both ways---sometimes being beneficial and sometimes not).
> >
> > Can you elaborate how it may not be beneficial?
>
> If you increase too fast you may cause (more) congestion.

Perhaps, it should not have a large (or perhaps even a small) effect on
congestion because the application is CBR over TCP i.e. the application
is rate-limited. For voice, the max rate is 32 kb/s (one way) or less.

> In congestion avoidance which way you increase things really doesn't
> matter as much because the increase is linear and while ACKing every
> byte still might help, it is probably not going to cause a big problem.

In the ACK counting case for increasing cwnd, the question is whether
ACKing every byte will increase the cwnd quickly enough to minimize the
sender incurred delay due to cwnd limitation for a CBR over TCP flow.

> Fairness depends on what you are competing with.  Christian's example is
> a fine example of inequity.  But, how does an endhost tell the
> difference between his scenario and a scenario whereby a zillion flows
> are all sending at 10 packets/second and therefore when there is loss
> the flow in question ought to be throttled?  No amount of counting of
> bytes or using CWV of cwnd vs. FlightSize is going to give the flow the
> information to make the right decision.

True. An endhost cannot tell the difference between the scenarios you
mentioned.

I think an interesting question is how two flows, one FTP and one CBR
over TCP originating from the same host and destined for the same host
(src!=dest) compete for bandwidth. My guess is that eventually, FTP flow
will eat into the bandwidth of CBR over TCP flow. I can probably check
that for a FTP flow competing with a Skype voice over TCP flow in a
controlled environment.

Generalizing further, how large FTP-like TCP flows have an impact on small
application bandwidth/rate limited TCP flows. I have not completely
scanned the literature to comment if anyone has already analyzed it.

Regards,
Salman

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