headers
Brian E Carpenter | 1 Jul 2002 15:04
Picon
Favicon

Re: diffserv for wireless

Semra YILMAZ wrote:
> 
> Hello,
> I am very new in this working group. I want ask a question, that is; does
> the diffserv work for wireless networks?

It works for any network. There are some special issues for wireless,
for example see draft-westberg-rmd-cellular-issues-01.txt.

Please discuss this on the diffserv-interest list since it is
not in the scope of the WG charter.

Regards
   Brian Carpenter
   diffserv co-chair

_______________________________________________
diffserv mailing list
diffserv <at> ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html
Permalink | Reply | 0 comments |
headers
Brian E Carpenter | 1 Jul 2002 15:13
Picon
Favicon

Re: Modeling of Policing component.

ravikumarb wrote:
> 
> Hi,
> 
> I have a question on the difference between "policing" and "shaping".
> 
> According to my understanding following is the difference between them:
> 
> [1] Policing: Process of checking whether a packet is in-profile or out-of-profile. If it is
out-of-profile, it will be dropped.
> [2] Shaping: Process of conditioning the traffic stream so that it stays in-profile.
> 
> But acording to RFC 3290 in section 3.3, it says that policing can be modeled as a concatenation of an
Algorithmic Dropper with a Scheduler. But I guess this should be the model for shaping rather than for policing.
> 
> Am I missing something here?

Please read the text more carefully:

   ...Policing is
   modeled as either a concatenation of a Meter with an Absolute Dropper
   or as a concatenation of an Algorithmic Dropper with a Scheduler.

and (in 7.1.3)

   An Algorithmic Dropper is an element which selectively discards
   packets that arrive at its input, based on a discarding algorithm.

I don't really see a problem here. The scheduler is not part of the policer,
so maybe it should have been mentioned in brackets, but in real life
(Continue reading)

Permalink | Reply | 0 comments |
headers
ravikumarb | 1 Jul 2002 15:49
Favicon

RE: Modeling of Policing component.

> 
> But acording to RFC 3290 in section 3.3, it says that policing can be modeled as a concatenation of an
Algorithmic Dropper with a Scheduler. But I guess this should be the model for shaping rather than for policing.
> 
> Am I missing something here?

Please read the text more carefully:

   ...Policing is
   modeled as either a concatenation of a Meter with an Absolute Dropper
   or as a concatenation of an Algorithmic Dropper with a Scheduler.

and (in 7.1.3)

   An Algorithmic Dropper is an element which selectively discards
   packets that arrive at its input, based on a discarding algorithm.

I don't really see a problem here. The scheduler is not part of the policer,
so maybe it should have been mentioned in brackets, but in real life
it will always be there. This is an *informal* model.

>>

We can have an Algorithmic Dropper as part of Policer, but not a Scheduler. The moment we have a Scheduler,
what we are doing is Shaping not policing.

Regards,

- Ravi
(Continue reading)

Permalink | Reply | 2 comments |
headers
Brian E Carpenter | 1 Jul 2002 17:41
Picon
Favicon

Re: Modeling of Policing component.

ravikumarb wrote:
> 
> >
> > But acording to RFC 3290 in section 3.3, it says that policing can be modeled as a concatenation of an
Algorithmic Dropper with a Scheduler. But I guess this should be the model for shaping rather than for policing.
> >
> > Am I missing something here?
> 
> Please read the text more carefully:
> 
>    ...Policing is
>    modeled as either a concatenation of a Meter with an Absolute Dropper
>    or as a concatenation of an Algorithmic Dropper with a Scheduler.
> 
> and (in 7.1.3)
> 
>    An Algorithmic Dropper is an element which selectively discards
>    packets that arrive at its input, based on a discarding algorithm.
> 
> I don't really see a problem here. The scheduler is not part of the policer,
> so maybe it should have been mentioned in brackets, but in real life
> it will always be there. This is an *informal* model.
> 
> >>
> 
> We can have an Algorithmic Dropper as part of Policer, but not a Scheduler. The moment we have a Scheduler,
what we are doing is Shaping not policing.

As I said, this is an *informal* model.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Smith | 1 Jul 2002 18:28
Picon
Favicon

RE: Modeling of Policing component.

I disagree: if you follow an Algorithmic Dropper by a Scheduler (there's
an implied Queue in there somewhere), when the Queue starts to get full
due to "excess" traffic (arrival - departure > 0 over appropriate time
intervals), the Dropper will kick in. That is "policing" (it's doing
shaping at the same time of course). 

Meter->AbsoluteDropper is the more conventional way to think about
policing, I agree, but AlgorithmicDropper->Scheduler is also valid.

Andrew Smith

-----Original Message-----
From: diffserv-admin <at> ietf.org [mailto:diffserv-admin <at> ietf.org] On Behalf
Of ravikumarb
Sent: Monday, July 01, 2002 6:49 AM
To: Brian E Carpenter
Cc: diffserv <at> ietf.org
Subject: RE: [Diffserv] Modeling of Policing component.
...
We can have an Algorithmic Dropper as part of Policer, but not a
Scheduler. The moment we have a Scheduler, what we are doing is Shaping
not policing.

_______________________________________________
diffserv mailing list
diffserv <at> ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tom Scott | 2 Jul 2002 22:17

RE: Modeling of Policing component.

"sqreeek" (that's the sound of the opening of a can of worms): Would
you consider evolving the informal model of RFC 3290 into a more
formal calculus, where such issues as Meter -> AbsoluteDropper and
AlgorithmicDropper -> Scheduler might be derived from first
principles? FSMs are already used in RFCs, so maybe it wouldn't be
such a jump to ASMs? You've already established four categories of
basic functions and indicated a rule for constructing arbitrarily
complex TCBs from the elements. Why drop the analysis at that point?

-- TT

-------- Original Message --------
Subject: RE: [Diffserv] Modeling of Policing component.
Date: Mon, 1 Jul 2002 09:28:29 -0700
From: "Andrew Smith" <ah_smith <at> acm.org>
To: "'ravikumarb'" <ravikumarb <at> infosys.com>
CC: <diffserv <at> ietf.org>

I disagree: if you follow an Algorithmic Dropper by a Scheduler (there's
an implied Queue in there somewhere), when the Queue starts to get full
due to "excess" traffic (arrival - departure > 0 over appropriate time
intervals), the Dropper will kick in. That is "policing" (it's doing
shaping at the same time of course).

Meter->AbsoluteDropper is the more conventional way to think about
policing, I agree, but AlgorithmicDropper->Scheduler is also valid.

Andrew Smith

-----Original Message-----
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brian E Carpenter | 3 Jul 2002 17:51
Picon
Favicon

Re: Modeling of Policing component.


Tom Scott wrote:
> 
> "sqreeek" (that's the sound of the opening of a can of worms): Would
> you consider evolving the informal model of RFC 3290 into a more
> formal calculus, 

No. Never. That is an academic topic (no insult intended), not
something that the IETF should do. 

   Brian

where such issues as Meter -> AbsoluteDropper and
> AlgorithmicDropper -> Scheduler might be derived from first
> principles? FSMs are already used in RFCs, so maybe it wouldn't be
> such a jump to ASMs? You've already established four categories of
> basic functions and indicated a rule for constructing arbitrarily
> complex TCBs from the elements. Why drop the analysis at that point?
> 
> -- TT
> 
> -------- Original Message --------
> Subject: RE: [Diffserv] Modeling of Policing component.
> Date: Mon, 1 Jul 2002 09:28:29 -0700
> From: "Andrew Smith" <ah_smith <at> acm.org>
> To: "'ravikumarb'" <ravikumarb <at> infosys.com>
> CC: <diffserv <at> ietf.org>
> 
> I disagree: if you follow an Algorithmic Dropper by a Scheduler (there's
> an implied Queue in there somewhere), when the Queue starts to get full
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bennett Jon-MGIA0444 | 3 Jul 2002 19:12

RE: Modeling of Policing component.


>> "sqreeek" (that's the sound of the opening of a can of worms): Would
>> you consider evolving the informal model of RFC 3290 into a more
>> formal calculus, 
>
>No. Never. That is an academic topic (no insult intended), not
>something that the IETF should do. 
>
>   Brian

Yeah surprisingly I have to agree with Brian on this one, the last 
thing we want is a model which is formally grounded enough that you 
could actually use it to verify that your equipment was correctly 
implemented. Much better that we don't ever do that sort of thing in 
the IETF, that way we have well defined areas of doubt and uncertainty.

Wait what was I thinking.... oh its the heat...
(our air-conditioning failed and its 95 degrees in my office.... really)
Let me try that again...

Yeah not surprisingly I have to disagree with Brian on this one.....

jon

Jon C. R. Bennett
Chief Engineer
Motorola Broadband Communications Sector
3 Highwood Drive
Tewksbury, MA  01876
978.858.2300/2361 (direct)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Semra YILMAZ | 3 Jul 2002 20:43
Picon

RE: diffserv for wireless

Thanks for your reply Brian. But i have tried diffserv in wireless but it
does not work even it works in wired network. What can the reason be?
Semra Yilmaz
-----Original Message-----
From: Brian E Carpenter
To: Semra YILMAZ
Cc: 'diffserv <at> ietf.org'
Sent: 01.07.2002 16:04
Subject: Re: [Diffserv] diffserv for wireless

Semra YILMAZ wrote:
> 
> Hello,
> I am very new in this working group. I want ask a question, that is;
does
> the diffserv work for wireless networks?

It works for any network. There are some special issues for wireless,
for example see draft-westberg-rmd-cellular-issues-01.txt.

Please discuss this on the diffserv-interest list since it is
not in the scope of the WG charter.

Regards
   Brian Carpenter
   diffserv co-chair

_______________________________________________
diffserv mailing list
diffserv <at> ietf.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
amoakoh | 5 Jul 2002 08:44
Picon
Picon
Favicon

Re: diffserv for wireless (Semra YILMAZ)

....yeah!,  but, did the original IETF DiffServ architecture ever
considered wireless issues at all?

Amoakoh

>  2. RE: diffserv for wireless (Semra YILMAZ)
> From: Semra YILMAZ <SYilmaz <at> hc.aselsan.com.tr>
> To: "'Brian E Carpenter '" <brian <at> hursley.ibm.com>,
> Subject: RE: [Diffserv] diffserv for wireless
> Date: Wed, 3 Jul 2002 21:43:07 +0300

> Thanks for your reply Brian. But i have tried diffserv in wireless but
> it does not work even it works in wired network. What can the reason
> be? Semra Yilmaz

_______________________________________________
diffserv mailing list
diffserv <at> ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html
Permalink | Reply | 0 comments |

Gmane