[Iccrg] Meeting agenda

[John Leslie]

Michael Welzl <michael.welzl at uibk.ac.at> wrote:
> 
> 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.

   In the first, you will need to stress the network by retransmitting.
At a minimum, you need to debit the retransmission against the allowable
transmission rate, ane I'd argue for an additional decrement in the
allowable transmission rate -- perhaps subtracting what would be added
for a successful packet.

   In the second, Lachlan would argue for decreasing the transmission
rate, based on the assumption that there must be some higher-utility
potential use. I am unconvinced, so far.

>>>> It may be the right thing to reduce the rate by less than
>>>> in the normal congestion case, but by how much...?
>>>
>>>  Wrong question!
>> 
>> No, it is the right question.  The well-developed theory of Network
> 
> It was an imprecise question  :)

   Thank you.

>> An important question is whether all applications should be
>> arbitrarily assigned the same utility (as is implicitly done by all
>> TCP variants), or the utility should reflect the actual application's
>> benefit from getting a certain amount of data at a given level of
>> corruption.  Since different application gain vastly different amounts
> 
> Let's assume equal utilities for now, just to keep things
> simple. In principle, addressing applications which would
> also benefit from delivery of some corrupt data in addition
> to the above would also be interesting, but let's start
> simple for now.

   I'm not sure there's anything useful we _could_ do without assigning
different utilities...

--
John Leslie <john at jlc.net>