[Iccrg] Meeting agenda

michael.welzl@uibk.ac.at (Michael Welzl) Wed, 13 September 2006 18:08 UTC

From: michael.welzl@uibk.ac.at
Date: Wed, 13 Sep 2006 18:08:16 +0000
Subject: [Iccrg] Meeting agenda
In-Reply-To: <20060912172140.GO96464@verdi>
References: <1157563149.3217.285.camel@lap10-c703.uibk.ac.at> <20060908173802.GI21317@grc.nasa.gov> <1157737559.3243.168.camel@lap10-c703.uibk.ac.at> <20060909143410.GI96464@verdi> <aa7d2c6d0609091107h219a5761if80d690c004a3de9@mail.gmail.com> <1158041095.4771.16.camel@lap10-c703.uibk.ac.at> <20060912172140.GO96464@verdi>
Message-ID: <1158161120.4770.286.camel@lap10-c703.uibk.ac.at>
X-Date: Wed Sep 13 18:08:16 2006

> > So, to put it more precisely: my question was about the
> > correct response of a transport endpoint that would be
> > notified about corruption when the receiver cannot use
> > corrupt data.
> > 
> > This can be done with the DCCP Data Checksum option, and
> > also the mechanism described in this draft:
> > http://www.ietf.org/internet-drafts/draft-stewart-sctp-pktdrprep-05.txt
> > 
> > In this case, increasing redundancy is no option.
> > 
> > So, under these circumstances, what is the right response
> > for the transport sender?
> 
>    There are still two cases:
> 
> 1. The data will need to be retransmitted;
> 2. The data would no longer be useful after a retransmission delay.

I don't see any difference between these two cases. After all,
the goal is to transfer as much data as possible without "harming"
the network. This intention is there, no matter if we retransmit
or not.

Cheers,
Michael