Subject: Re: Re: Performance requirements

From: Paal Engelstad <[email-masked]>
Date: Fri, 22 Feb 2002 1:22:14 +0100

Reinaldo,

> Hello Paal,
> 
> I totally agree we need this scoped out better.

Good.

I get a feeling that there is some rough consensus on the list that PANA will be a protocol designed for performance and "straightforward network access" (althought the charter does not say much about it).

We need to clarify this issue better, IMO.

> 
> But as I said on the last IETF meeting. Saying that a
> protocol needs to be "efficient" is the same thing as
> saying that you need to go from San Fracisco to Tokyo
> "fast" (it depends on how much money you have, if
> stopping in Hawaii to catch some waves has greater
> priority, if you are afraid of flying and prefer some
> CruiseLine, etc).

Agreed. Discussions on what is the most "efficient" will not be meaningful unless we agree on the context.

Perhaps we need to make some rough assumption about the context that the PANA protocol is going to be designed for, e.g. worst case processing power, maximum acceptable bandwidth overhead, type of media (e.g. interactive voice), etc...? Perhaps 3g-people have some clear requirements?

> 
> We need to find out the constraints that determine
> what this efficient means. Does it need congestion
> avoidance? Does it need retrasmission? Does it need
> hashing? Given these constraints we will find out what
> efficient means.

Latency and bandwidth constraints could be a good start...

I don't know exactly how to address it in the requirements document, though...

Any ideas?

Paal

> 
> Maybe some of the requirements right of the bat take
> some protocols/solutions out of the list.
> 
> regards,
> 
> Reinaldo
> 
> --- Paal Engelstad <[email-masked]> wrote:
> > Reqs team,
> > 
> > I have gone through the reqs document over again, I
> > wonder if also the Performance requirements need
> > some more detailing. 
> > 
> > It seems like a lot of people on the list require a
> > protocol that is "efficient", that allows "frequent
> > end node movement" without disruption, etc. I think
> > we should determine more quantitively what are the
> > performance requirements are before we start
> > designing the protocol. The sooner, the better.
> > 
> > Later we might get into a ICMP vs. UDP discussion,
> > or a secret-key vs. public-key discussion. With more
> > detailed performance requirements, it will be easier
> > to handle these discussions.
> > 
> > Paal
> > 
> > 
> > > At 12:18 08/02/2002, George Tsirtsis wrote:
> > > >Paal,
> > > >
> > > >You keep ignoring maybe the most important reason
> > we are here and that is
> > > >straight forward network access. You are 
> > 
> > <...>
> > 
> > try :-) you will realize that
> > > using
> > > >EAPoverUDP to get basic internet access is too
> > inefficient and it does not
> > 
> > <...>
> > 
> > > >shorts of scenarios, including wide are wireless
> > and potentially frequently
> > > >due to end node movement. For this kind of
> > fundamental function it is
> > > >prudent to go lower in the networking stack
> > > 
> > 
> > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Sports - Coverage of the 2002 Olympic Games
> http://sports.yahoo.com
>

---

From: George Tsirtsis <[email-masked]>
Date: Fri, 22 Feb 2002 05:03:07 -0500

Paal,

I think this is a big rat hole. Especially the performance part and the idea
of being explicit about it in the requirements. IETF is not really good at
dealing with this things because it can make no assumptions about the link
layers it is using and performance has a lot to do with that, as well as
with the processing and memory capabilities of boxes. 

One can not even design for the worst case scenario since, this is probably
a tiny sensor trying to communicate over a sonar (a few bits per second if
you are lucky) based adhoc and multihop network from a ship in the middle of
the pacific to an Australian base :-) For this reason designs are mostly
done for a "reasonable" case or range of cases.

Now, since we know the environments people might want to use PANA (very wide
from wired to wireless), we can do a good job without having to state number
of bandwidth and latency requirements for PANA. When actual proposals come
out we will have to take into account the relative signaling and
computational overhead in combination with the functional requirements of
the requirements document to compose a solution based on engineering
trade-offs.

My point is that in the context of IETF "performance" and "efficiency" must
be examined *qualitatively* rather than *quantitatively*.

Anyway, this is all a bit philosophical but still maybe important.

George
-----Original Message-----
From: Paal Engelstad [mailto:[email-masked]]
Sent: Friday, February 22, 2002 12:22 AM
To: Reinaldo Penno; George Tsirtsis
Cc: [email-masked]
Subject: Re: Re: Performance requirements

Reinaldo,

Good.

I get a feeling that there is some rough consensus on the list that PANA
will be a protocol designed for performance and "straightforward network
access" (althought the charter does not say much about it).

> priority, if you are afraid of flying and prefer some

Agreed. Discussions on what is the most "efficient" will not be meaningful
unless we agree on the context.

Perhaps we need to make some rough assumption about the context that the
PANA protocol is going to be designed for, e.g. worst case processing power,
maximum acceptable bandwidth overhead, type of media (e.g. interactive
voice), etc...? Perhaps 3g-people have some clear requirements?

I don't know exactly how to address it in the requirements document,
though...

Any ideas?

Paal

---

From: Paal Engelstad <[email-masked]>
Date: Fri, 22 Feb 2002 19:40:13 +0100

> Tema: RE: Re: Performance requirements
> 
> Paal,
> 
> I think this is a big rat hole. 

You are probably right...
Paal

> Especially the performance part and the idea

---

From: <[email-masked]>
Date: Fri, 22 Feb 2002 14:13:02 -0600

>Reqs team,

Please be aware that there is no longer a requirements team. The
requirements team has produced a draft and their work is done. All
subsequent requirements will be dealt with by the WG as a whole. Alper
will continue in his role as the editor of the document and make
changes as necessary (based on WG discussion and concensus).

>
>I have gone through the reqs document over again, I wonder if also the
>Performance requirements need some more detailing.  
>

Nope.

>It seems like a lot of people on the list require a protocol that is
>"efficient", that allows "frequent end node movement" without
>disruption, etc. 

PANA may be used in mobile networks and environments, but is not
designed to solve the mobility problem. So there is no reason as far
as I see to add mobility specific requirements into PANA.

>I think we should determine more quantitively what
>are the performance requirements are before we start designing the
>protocol. The sooner, the better. 
>

Hmmm.... I would suggest that we come up with a framework and develop
a solution that meets the requirements. Waiting for quantitative
results to be available will delay the WG progress.

>Later we might get into a ICMP vs. UDP discussion, or a secret-key
>vs. public-key discussion. With more detailed performance
>requirements, it will be easier to handle these discussions. 
>

Getting the solution right at this time which meets the requirements
is more important than tweaking the design for performance.

>Paal

-Basavaraj