[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Errormodel



>
> From:  Ingela Anderton <[email protected]>
> To:    Kevin Fall <[email protected]>
> cc:    [email protected]
> Subject: Re: Errormodel
> Date:  Thu, 14 May 1998 12:15:30 +0200
>
> 
> Kevin Fall wrote:
> 
> > It's probably caused by fact that you are using flow id #1 for
> > some flow, but you have not set up an error model for that flow number.
> Okej I see, you are right. Now it works much better :) 
> 
> Is there some other classifer that can make a link lossy independent 
> of the flow? Where can I find out what options there are. This dosen't seem
> to be documented in the current documentation. 

Actually, you can plug any classifier you want to into an ErrorModule,
although the "init" procedure for ErrorModule currently allocates a
classifier of type "Classifier/Hash/$cltype", meaning you can
specify which type of hash classifier you want.
There are, for example, has classifiers that look at src/dst addresses,
src/dst addresses + flow id, just flow id, etc.

One thing I recently added [so you will only find it in the snapshot for now]
is that an ErrorModule may have a "default", so that anything not matched
directly by the classifier goes to the default.... so that may be what you want.
The Otcl header is:

	ErrorModel instproc default errmodel {

Thus, you install the error model you want as the default for the module.
In addition, you can specify the string "pass", in which case defaulted
packets are unaffected.

Another thing that might interest people...  The error models in the snapshot version of ns
now contains a capability to mark ECN in pkts instead of dropping them.
(most [all?] of the snapshot TCP's now also react to ECN properly if enabled).
To have an error model mark ecn instead of drop, just do:

	$em set markecn_ true

BTW, you're right, the current documentation doesn't have details on some of this,
given that it's quite new...

- K