Subject: RE: Regarding the Options headers

From: "Thomas Eklund" <[email-masked]>
Date: Thu, 16 Nov 2000 15:55:31 +0100

Hi Francis,

> Then there are two different points:
>  - does the issue remain if edge routers are closed enough to hosts:
>    * an interface only (for direct connections)
>    * line speed limited at least by available stock hardware
>    * low or at least reasonable number of flows?

In many cases yes.

>   I believe the issue doesn't remain just because for many reasons
>   stock hardware had, has and will have poor I/O performances
>  - is it possible to put edge routers closed enough:

what I trying to say here is that people can build there network in
different way... as you know 99,99 % of the isp's still use IPv4 for
instance  eventhough v6 is better and haver a nicer cleaner arhitechure..

>   * technical constraints: I can't see one?

you will have to buy more memory which is very expensive since you must have
a recursive loop in the packet to find the offset where the transport header
sits - this is doable but much worse than ipv4 where you have the header
length and can dfind the offset immediatly for the transport header...

>   * price constraints: with ASICs we are supposed to do it cheaply?

like I said it will be more expensier to build the hardware and in the end
it might have an impact on the rollout of ipv6...

>   * policy constraints: I am sorry to have to say that but it
> is the job
>     of a ISP to look at inside packets of its customers. It is why
>     I said ESP will save us. Of course this should be the point where
>     we have a very different opinion, in the past my current
> ISP decided
>     the Web was mainly pornography and tried to limit the bandwidth
>     for a particular TCP port...

And as I said I agree with your reasoning here from a pricipal clean IP
arhitechure but there are many service providers that wants to use this
feature.

> I have talked about firewalls because:
>  - they shared the same issue but they have to do something a
> bit harder
>    (BTW I think a solution which works for routers and not
> for firewalls
>     will have a problem in the future: there are (too) many ISPs which
>     put firewalls to protect (against) customers)

In other words we agree.

Like I said before layer 4 classification is not nescessarily tied to qos
classification it can be packet filtering as well and in both cases we have
the same problem.

>  - they (will?) use ASICs when high performances are needed
not nescesseary asic it could be np's as well.

>  - they share the management issue, security policies are even more
>    critical than QoS policies (a mistake for instance has
> worse consequences).

I agree. But I think that the UML base QoS policy model for managing Qos
related policies is a very good start and hopefully we will have a security
base policy model as well...

Regards
 thomas

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Thu, 16 Nov 2000 17:44:17 +0100

you will have to buy more memory which is very expensive since you must have
   a recursive loop in the packet to find the offset where the transport header
   sits - this is doable but much worse than ipv4 where you have the header
   length and can find the offset immediatly for the transport header...

=> I don't understand the memory problem: you still need enough memory
to handle the packet... Perhaps you'd like to cache the first bytes in
another (fast and more expensive) memory and in this case the offset
won't help. You should have a particular design in the mind (and of
course you don't want to give all the details in an open list).
   
   > is the job of a ISP to look at inside packets of its
   > customers. It is why I said ESP will save us. Of course this should be
   > the point where we have a very different opinion, in the past my
   > current ISP decided the Web was mainly pornography and tried to limit
   > the bandwidth for a particular TCP port...
   
   And as I said I agree with your reasoning here from a principal clean IP
   architecture but there are many service providers that want to use this
   feature.
   
=> then your issue is you can't say just no as I can?

Regards

[email-masked]