Subject: RE: your mail

From: "Gray, Eric" <[email-masked]>
Date: Tue, 2 Jul 2002 16:38:15 -0400

Eric,

	It is in the fact that we have to be sure -
just as you suggest.  The cost of being sure, however, 
is that you have to be prepared to deal with occasions 
when the check fails.  What do you do when the higher
layer is not UDP or TCP - throw these packets in to a 
common bucket?  What is the expected impact if this 
traffic might occasionally be significant?

Eric W. Gray

-----Original Message-----
From: Eric Osborne [mailto:[email-masked]] 
Sent: Tuesday, July 02, 2002 4:24 PM
To: Gray, Eric
Cc: 'Eric Osborne'; 'MPLS Mailing list'
Subject: Re: your mail

On Tue, Jul 02, 2002 at 03:36:52PM -0400, Gray, Eric wrote:
> Eric,
> 
> 	To answer your final two questions, yes it probably
> is stealing.  The fact that you can get away with a crime
> does not make it any less a crime.  Who knows, some vendors 
> may not check that the protocol over the top of IP is either 
> UDP or TCP before using the port numbers.  

If a vendor checks the offset where the port numbers should be without
checking for the correct protocol type, this is a cruddy
implementation and shouldn't exist.  My question was really along the
lines of "what if we use the values that we *know* are UDP/TCP port
numbers"?  From what you say above, it seems like that might be OK, as
long as we only do this when we're sure?  Or is there some inherent
architectual layer violation thing that you're objecting to?

eric

> I think you can 
> easily imagine what that might lead to if a set of packets 
> carry a higher level protocol where the corresponding fields 
> may vary from packet to packet in a single micro-flow.  The
> real question is how common is this?
> 
> Eric W. Gray
> Systems Architect
> Celox Networks, Inc.
> [email-masked]
> 508 305 7214
> 
> 
> -----Original Message-----
> From: Eric Osborne [mailto:[email-masked]] 
> Sent: Tuesday, July 02, 2002 1:32 PM
> To: Hummel Heinrich
> Cc: [email-masked]'; Shahram Davari; 'Eric Osborne'; George Sheng;
> [email-masked]; [email-masked]
> Subject: Re: your mail
> 
> On Tue, Jul 02, 2002 at 04:25:37PM +0200, Hummel Heinrich wrote:
> > It  gets weirder  and weirder: The MPLS WG invents a label stack, but
does
> not care at all that any of the
> > deeper nested labels may ever be signalled/carried by means of a
> Label-TLV/object (no public comments to my
> > Hierarchical LSPs, draft-hummel-mpls-hierarchical-lsp-01.txt).
> > 
> > However it is ok, to "steal" the deepest nested label and call it
> "VC-label" for indexing
> > some VRF at some remote PE. 
> 
> This is not theft; it's using the labels as they were designed.  How
> is using the bottommost label as a VC-labe/VPN label/whatever
> "stealing"?  You seem to be attacking the very idea of label stacking,
> which is a pretty useful concept.
> 
> > Furthermore it is ok, to "steal" the very same label for hashing.
> > 
> 
> What about IP router vendors that do load-balancing based on L4/L5
> information like protocol type and port numbers?  Is that stealing?
> 
> 
> 
> 
> eric
> 
> > Independent from what is clean and what is quick&dirty, I cannot detect
> any sense in giving a hash-meaning to the bottom label at all.
> > 
> > 
> > 
> > Heinrich Hummel
> > Siemens
> > 
> > -----Ursprüngliche Nachricht-----
> > Von: Eric Rosen [mailto:[email-masked]]
> > Gesendet: Dienstag, 2. Juli 2002 16:06
> > An: Shahram Davari
> > Cc: 'Eric Osborne'; George Sheng; [email-masked]; [email-masked]
> > Betreff: Re: your mail 
> > 
> > 
> > Shahram> To do ECMP, you need to  assign hashed values to egress ports.
> This
> > Shahram> assignment is the hash state that I said you need.  
> > 
> > A hash is  a function that maps  some sequence of octets into  a
sequence
> of
> > integers.  If you want to split  traffic over six paths, while ensuring
> that
> > all packets  with the  same bottom label  travel the  same path, you
need
> a
> > function that maps  a 20 bit quantity  into a number from 1-6.   There
is
> no
> > need to maintain state of any kind.

---

From: Eric Osborne <[email-masked]>
Date: Tue, 2 Jul 2002 18:31:25 -0400

> traffic might occasionally be significant?

Then you need a better load-balancing algorithm.  Either IP SA/DA and
some randomness, or random sampling from the packet, or (heaven
forbid) some sort of flow-based scheme.  I'm even dubious about the
efficacy of using TCP/UDP ports to hash, given that most traffic is
either src or dst TCP port 80, which really only gives you the port in
the other direction to play with.  But that's not really my problem,
as the implementation I'm familiar with doesn't do anything with
TCP/UDP ports (although I'm sure that *somewhere* in cisco we make a
device that does; I just don't deal with it/them).

also, don't forget that this hypothetical algorithm takes into acount
IP SA/DA and TCP/UDP SP/DP.  So if you have too many collisions, you
probably have very few flows/conversations/whatnot anyways, and either
need to move to something like per-packet (ick) or just larger pipes.

eric