[e2e] Reacting to corruption based loss

[Jonathan M. Smith]

I would hypothesize that there is in fact no ideal reaction to corruption,
because the proper response is deeply dependent on the cause. There are,
however, potential inferences one could draw about causes from data
available from cross-layer analyses, such as link layer checksums, FECs,
and the like.
							Best,
							-JMS

-------------------------------------------------------------------------
Jonathan M. Smith
Olga and Alberico Pompa Professor of Engineering and Applied Science
Professor of Computer and Information Science, University of Pennsylvania
Levine Hall, 3330 Walnut Street, Philadelphia, PA 19104

On Tue, 7 Jun 2005, Michael Welzl wrote:

> Dear all,
>
> I changed the subject because it's drifting away from the
> original topic...
>
>
> Sally Floyd wrote:
>
> > Addendum:
> > I am personally very interested in the potential benefits (and
> > complications) of more explicit communication between link layers
> > and transport protocols, and in particular I like the idea of
> > explicit communication from lower layers to transport saying "the
> > packet with this packet header was dropped due to corruption".  It
> > is not clear to me yet exactly what the response of the transport
> > protocol should be to reports of packet corruption, however -
> > continuing to send at a high rate in the face of a high rate of
> > packet corruption doesn't sound too appealing.  And there are
>
> This point has been raised several times: how exactly should
> a sender react to corruption? I fully agree that continuing
> to send at a high rate isn't a good idea.
>
> Now, given that we're talking about a transport endpoint which
> is informed about corruption, there probably isn't any knowledge
> regarding the origin of corruption available - we don't know
> what type of link layer caused it or why exactly it happened
> (too many sources sending at the same time? user passed a wall?).
> However, there seems to be some consensus that the reaction
> to corruption should be less severe than the reaction to congestion.
>
> Also, it has been noted several times (and in several places) that
> AIMD would work just as well if beta (the multiplicative decrease
> factor) was, say, 7/8 instead of 1/2. For a historical reason (I
> think it was the DECbit scheme), 7/8 seems to be a number
> that survived in people's minds.
>
> So, why don't we just decide for a pragmatic approach instead
> of waiting endlessly for a research solution that we can't come
> up with? Why don't we simply state that the reaction to corruption
> has to be: "reduce the rate by multiplying it with 7/8"?
>
> Much like the TCP reduction by half, it may not be the perfect
> solution (Jacobson actually mentions that the reduction by half
> is "almost certainly too large" in his congavoid paper), but
> it could be a way to get us forward.
>
> ...or is there a reasonable research method that can help us
> determine the ideal reaction to corruption, irrespective of
> the cause?
>
>
> > complications with other forms of explicit communication between
> > link layers and transport protocols as well, e.g., as discussed in
> > the IAB internet-draft on "Architectural Implications of Link
> > Indications", at
> > "http://www.iab.org/documents/drafts/draft-iab-link-indications-01.txt".
> >
> > It might be that it is time also for a research group on Explicit
> > Communication between Transport Protocols and Lower Layers, but
> > someone else will have to start it.  (I believe that there is already
> > a proposal in the works for a new research group on new congestion
> > control mechanisms, which includes one class of proposed new forms
> > of explicit communication between transport protocols and routers.)
>
> I agree that this would be good to have. There have been many
> proposals, and none of them appeared to work well enough
> (*ouch*, I just hurt myself  :-)  ). Inter-layer communication
> is a tricky issue, regardless of the direction in the stack.
> Heck, we don't even have a reasonable way to signal "UDP-Lite
> packet coming through" to a link layer!
>
> Cheers,
> Michael
>