Subject: RE: [Diffserv] Aggregated port arrays

From: Jay Wang <[email-masked]>
Date: Tue, 11 Jul 2000 14:05:52 -0700

Brian,

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]]
Sent: Tuesday, July 11, 2000 1:39 PM
To: Jay Wang
Cc: [email-masked]'; Kathleen Nichols;
[email-masked]; 'Andrew Smith'; [email-masked]
Subject: Re: [Diffserv] Aggregated port arrays

Jay Wang wrote:
> 
> Dave,
> 
> I think the fact that you use multiple physical interface
> for one single logical interface does not conflict with
> the current Diffserv architecture with respect to policing
> and shaping as you pointed out. Policing and shaping are
> enforced on a per flow basis and flows are logical entities
> defined by your classifier and ultimately SLAs.  Although
> you use multiple physical interfaces for load sharing,
> I speculate that you do not split one flow to multiple
> physical modules to avoid packet reording problem.
> Therefore, classification, metering, and marking do not
> seem to be any different in your case than the normal one.
> The problem is, however, for the egress queueing, on
> different physical interfaces you may have queues for the
> same PHB group (e.g., AF1x).  In this case, I think you
> need to make sure that the aggregated throughput from all
> queues in different physical interfaces adds up to what
> you expect for that particular PHB group (i.e., AF1x). 

That's a normal function of admission control and policing
at the router that merges the traffic from the various
interfaces. Absolutely 100% standard diffserv.

   Brian

I know this is part of normal admission control and policing.
But in the context what I meant by vendor specific is that if
one splits traffic from one logical interface into multiple 
physical modules for load sharing/balancing.  So potentially 
they might end up having multiple queues in different physical 
modules for the same PHB group. In this case, although logically 
not much difference, but the actual implementation to achieve 
full Diffserv would have a lot to do with their specific 
hardware architecture.  Such topics are not covered in the 
Diffserv model and my argument is that there is no need to 
change that either.

regards,

- Jay 

But
> I think this will be vendor specific and I do not believe
> that we need an ID to address this issue.  Also, since
> flows in the context of Diffserv is unidirectional, the
> asymmetric nature in your architecture does not appear to me
> to present any conflict with current Diffserv model either.
> 
> regards,
> 
> 
> - Jay Wang
> 
> -----Original Message-----
> From: Dave Hotlosz [mailto:[email-masked]]
> Sent: Monday, July 10, 2000 8:41 AM
> To: John Strassner
> Cc: Kathleen Nichols; [email-masked]; 'Andrew Smith';
> [email-masked]
> Subject: [Diffserv] Aggregated port arrays
> 
> Hi,
> This maybe beyond the scope of this WG but it is a real issue. Many
> venders now support multiple NICs on the same network using the  same ip
> address and same MAC addresses for each interface.This gives you  a much
> higher transmit rate than receive rate in the current implimentations.
> 
> Load and balancing determines which physical interface the data goes
> out. So the question is should the Shaping and ingress policing be done
> for the load balancing module or on the per physical interface?
> 
> Will the diffserve model take into account the case where a interface
> has a transmitt rate greater than 2 times the receive rate? Or as far as
> diffserve is concerned this is not a problem.
> 
> Excuse me if I'm way off base here I just wanted to express one concern
> I have in implimenting diffserve.
> 
> Also I'd prefer to see ingress and egress nodes defined in a seperate
> document as thier actions are clearly different from DS boundry and
> interior nodes.
> 
> Thanks,
>     Dave Hotlosz
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/