Transport protocols and bulk file transfer

[Yunhong Gu <>]

Stas,

I think here you made an implicit assumption that the protocol will
respond to every single loss event, which may not be the case in real
world. In fact, if you want the protocol to be robust to non-congestive
loss, certain packet loss has to be ignored (e.g., by a heuristic
approach).

Gu


On Thu, 24 Feb 2005, stanislav shalunov wrote:

> "Lawrence D. Dunn" 
> <>
>  writes:
>
> >    (This was one of my action items from last time.
> >    Stas, Steven and I did go over most of this at I2 joint-techs
> >    meeting. But I had scribbled this stuff on paper, and promised
> >    Stas I'd type it up).
>
> Larry,
>
> Thank you very much for doing this.
>
> >   1. Is the information metric correct? We discuss the error rate
> >   "p", but what about the information contained in the ACK's. Since
> >   the algorithm takes action on each ACK reception, it is deriving
> >   some > information per-packet from the received ACKs.
>
> Yes, and that's accounted for in Shannon's formula (the (1-p)log(1-p)
> part reflects the information in the delivered packets).
>
> >     Also, are we correctly characterizing "p" for both congestive
> > and non-congestive loss?  It's pretty easy to think about small "p"
> > for non-congestive loss.  But if there is congestion then the number
> > of dup-ACKs will go up until the sender backs off.  So during that
> > time, the experienced "p" would be possibly higher, and the
> > backoff-signals more frequent.  I'm not sure that behavior is
> > modelled in the Shannon formula.  (i.e. "p" is time-varying around
> > the loss event, etc)
>
> The model assumes a response function that maps a loss probability to
> throughput.  There might be situations outside the domain of
> applicability, but this doesn't appear to be one: on this case, p
> simply needs to reflect the averaged loss probability.
>
> > 2. alpha ("a") <1 or >1? text has examples of <1 (.5, .82), but
> > formalization slips in a>1 as basic assumption.  If you're trying to
> > make a point that a>1 is the key factor that makes things degrade,
> > and therefore cannot be used, should highlight that assertion.  As
> > written, there's no hint to believe that a>1 is any more/less
> > important than c>0.  They seem like they're just boundary-condition
> > constants, rather than critical "I'm about to show that for a>1
> > things fall apart" components.
>
> Right, the claim in the appendix is in essence ``if alpha>1, then
> things look bad.''
>
> > 3. Does p^(a-1) / log2 (p) --> infinity? Seems like maybe not.
>
> That's a showstopper.  I overlooked the sign of the exponent somehow.
> Thank you for not letting this get out in the final document.
>
> In fact, what we have here is an increasing information transfer rate
> for alpha>1.  It's the alpha<1 case (e.g., standard TCP), that this
> whole argument would apply to.  This might make it more interesting,
> but it doesn't serve to support the stated goal.
>
> >      (other side issue- lost a "-" sign on first page).
>
> Transcription error (the minus sign reappears in the next formula).
>
> > 4. meta-issue: Does it matter if precision degrades with low-loss?
> >   (It may be that some constant-number of bits of accuracy is sufficient).
>
> With a fixed information transfer rate and a fixed convergence time,
> you get a fixed *relative* precision, which might be good enough.
> However, for alpha<1, you don't even get that (the transfer rate,
> roughly -p^{1-alpha}log2 p, goes to zero as p -> 0, so even relative
> precision -- or time of convergence -- deteriorates).
>
> > 4.1 What *should* rate be with zero congestive loss (i.e. all loss
> > is non-congestive)?  Compare examples when Tx interface is less_than
> > or greater_than bottleneck rate.
>
> The response function model doesn't distinguish between kinds of
> losses.  If p=0, rate goes to (``is'') infinity.  If the sender blocks
> on full buffer, extra information is transmitted to the sender
> (besides just a loss pattern), and the congestion control is no longer
> loss-based; it's delay-based, with target delay equal to the local
> buffer size divided by capacity.
>
> > 5. "Bottleneck router needs to communicate...". Really? If it's
> > non-congestive loss, then routers never signal anything.  There is a
> > confusing mix of discussion the centers on congestive loss, versus
> > other parts of the text where non-congestive loss seems to be the
> > focus.  So is the discussion about congestive, or non-congestive
> > loss?  Or both equally, etc.
>
> Both equally.  I would have changed ``bottleneck router'' to ``the
> network'' had I not removed the appendix.
>
> Will send a new version out shortly.
>
> --
> Stanislav Shalunov            http://www.internet2.edu/~shalunov/
>
> This message is designed to be viewed at room temperature.
>
>