From: P729 (p729@xxxxxxx)
Date: Thu Aug 01 2002 - 13:27:56 GMT-3
I don't disagree. Maybe I'm over-analyzing this part of the statement: "MORE
lightly (sic) to be dropped than delayed."
Which is starting to make me think of CoS/ToS--signalling, marking, resource
reservation, etc. If the network can't meet the delay spec., don't start the
flow, or something like that.
Regards,
Mas Kato
https://ecardfile.com/id/mkato
----- Original Message -----
From: "Tom Larus" <tlarus@cox.net>
To: "P729" <p729@cox.net>; "Omer Ansari" <omer@ansari.com>
Cc: "Casey, Paul (6822)" <Paul.Casey@o2.com>; "ccielab"
<ccielab@groupstudy.com>
Sent: Thursday, August 01, 2002 6:09 AM
Subject: Re: Processing delay sensitive traffic.
But remember, it is not very likely at all that priority traffic handled by
LLQ will be delayed. That traffic is in the HOV lane, so to speak.
----- Original Message -----
From: "P729" <p729@cox.net>
To: "Omer Ansari" <omer@ansari.com>
Cc: "Casey, Paul (6822)" <Paul.Casey@o2.com>; "ccielab"
<ccielab@groupstudy.com>
Sent: Thursday, August 01, 2002 2:28 AM
Subject: Re: Processing delay sensitive traffic.
> "how would policing alone guarantee delay sensitivity?"
>
> It won't. I was targeting this part of the statement:
>
> "...will incur minimum processing delay and its packets are MORE lightly
to
> be dropped than delayed."
>
> I didn't read "guaranteed delay sensitivity" into it, but rather removing
> any queuing, weighted-fair or otherwise. On the other hand, PQ would make
it
> LESS likely for the traffic to be dropped.
>
> Hmmm, now you've got me thinking. "Guarantee" delay and drop if the
> guarantee can't be met...maybe they're talking about RSVP instead...
>
> Regards,
>
> Mas Kato
> https://ecardfile.com/id/mkato
> ----- Original Message -----
> From: "Omer Ansari" <omer@ansari.com>
> To: "P729" <p729@cox.net>
> Cc: "Casey, Paul (6822)" <Paul.Casey@o2.com>; "ccielab"
> <ccielab@groupstudy.com>
> Sent: Wednesday, July 31, 2002 4:47 PM
> Subject: Re: Processing delay sensitive traffic.
>
>
> Mas Kato,
>
> that does sound reasonable except for one thing; how would policing alone
> guarantee delay sensitivity?
>
> On Wed, 31 Jul 2002, P729 wrote:
>
> > You'll want to look at some form of policing, like policing to a given
> rate,
> > accommodating bursts in a fashion so that TCP will self-police to the
> > desired rate. Exceed the allowable burst and you're dropped (or marked
and
> > dropped further down the line).
> >
> > Shaping implies queuing which in turn implies delay.
> >
> > Regards,
> >
> > Mas Kato
> > https://ecardfile.com/id/mkato
> > ----- Original Message -----
> > From: "Casey, Paul (6822)" <Paul.Casey@o2.com>
> > To: "ccielab" <ccielab@groupstudy.com>
> > Sent: Wednesday, July 31, 2002 12:40 PM
> > Subject: Processing delay sensitive traffic.
> >
> >
> > Hello,
> >
> > Can some help me with this
> >
> > Users on the local ethernet segment of Area 33 ABR are running a
> > delay-sensitive application from a server
> > Configure appropriate routers such that the application which uses udp
> port
> > 4700 will incur minimum processing
> > delay and its packets are MORE lightly to be dropped than delayed.
> >
> >
> > How you would you go about doing something like this..
> >
> >
> >
> > Paul Casey
> > O2 Ireland
> > Core Network Eng'g Team
> > 76 Lower Baggot Street, Dublin 2.
> > > * Mobile : +353 86 8143310
> > E-mail: paul.casey@o2.com
> >
> > PLEASE NOTE THAT THE ABOVE CONFIDENTIAL INFORMATION I
> >
> > > See what you can do www.o2.ie
> > >
> >
> >
> >
>
****************************************************************************
> > ************
> >
> > This E-mail is from O2. The E-mail and any files
> > transmitted with it are confidential and may also be privileged and
> intended
> > solely for the use of the individual or entity to whom they are
addressed.
> > Any unauthorised direct or indirect dissemination, distribution or
copying
> > of this message and any attachments is strictly prohibited. If you have
> > received the E-mail in error please notify postmaster@O2.com or
> > telephone ++ 353 1 6095000.
> >
> >
>
****************************************************************************
> > *************
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:48:13 GMT-3