[e2e] random early time-to-die

[Dorgham Sisalem]

Hello,

the fairness part could be helped by reducing the TTL not by a
fixed amount but in propotion to the TTL value. However, even then,
flows traversing a smaller number of hops and actually congesting one
or more of those hops will most probably manage to get through
with less drops than flows traversing more hops and possibly behaving
well. So this might lead us to take the TTL value and include it in
the feedback (acks) messages and have the sender adjust its
transmission rate in accordance with the value of the TTL value (not
a good idea as this automatically intoduces unfairness towards flows
with larger numbers of hops).

Dorgham Sisalem

Thursday, June 14, 2001, 4:09:58 PM, you wrote:



>> > here's an odd idea
>> >
>> > what if we decrement TTL by an amount proportional to the marking
>> > probability (instead of marking or dropping in RED)?
>> 
>> I don't think it's fair because it'll depend on the initial TTL value.

Murat Yuksel> It might be fair if we look at it from user's side. Each user will have a
Murat Yuksel> chance to express their incentives by giving different TTL values. If your
Murat Yuksel> traffic is so valuable, say, then give higher TTL values to your packets.
Murat Yuksel> But, then the biggest problem comes up.. How to control the users in such
Murat Yuksel> a case!??! 

Murat Yuksel> To achieve this control, charging might be used as Jonathan suggested,
Murat Yuksel> but other problems will raise at the provider's side. Should the provider
Murat Yuksel> charge the traffic coming from a user or going to a user or both? Isn't it
Murat Yuksel> too much of overhead to deal with charging every single packet? Also,
Murat Yuksel> how/when should the provider inform the user about the price, before the
Murat Yuksel> service (prior) or after the service (posterior)? etc..

Murat Yuksel> -Murat
>> 
>> Carlos Kamienski
>> 
>> >
>> > j.
>> >
>> 
>> 




-- 
Best regards,
 Dorgham                            mailto:sisalem at fokus.gmd.de