[e2e] Reacting to corruption based loss

[Cannara]

Good, but corruption isn't just wireless related, which has to do with all
manner of propagation complexities.  It is as simple as a failing chip in an
interface on a router, or in a service provider's line termination.  In such
cases, it makes no sense to slow down, and it would be better to send more
pkts, if there's no congestion.  This is just one reason why it's so important
to let the network layer know whether congestion or error is causing loss at
any link in a path.  That info can then be used to manage all the flows on the
path, not just TCP.  And, for Jon, this has not to do with x.25, but may have
lots to do with other protcool families, used for years by serious networking
folks.

Alex

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