[e2e] Reacting to corruption based loss

[Michael Welzl]

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