Jim,
Nice rant :-)
Could you elaborate on the pseudo-random nature of the flow label. It seems
to me that if it did not need to be pseudo-random, people could go on
"signaling off-line" about the flow label values (in SLAs, this seems to be
what Alex & Brian want). I see no harm in allowing such practice, but it
would be best if there is only one format for the flow label, as it would be
faster to decode.
Jarno
> -----Original Message-----
> From: ext Jim Bound [mailto:[EMAIL PROTECTED]]
> Sent: 21. elokuuta 2001 15:58
> To: Thomas Eklund
> Cc: 'Alex Conta'; Thomas Narten; Brian E Carpenter; Bob Hinden; ipng
> Subject: RE: Higher level question about flow label
>
>
> thomas,
>
> that is why if we can treat the flowlabel as part of tuple with src
> address and identify a connection which identifies the forwarding path
> the challenge is reduced. there is nothing needed but the
> header for the
> look up and forward. I believe this can be made to work.
>
> the traffic class will provide diff serv metric and the flow
> identifies
> the E2E connection with the src addr.
>
> The src addr MUST be a global address.
>
> Site-Local can be done too but don't want to get into that right now.
>
> One can ask if the Ipv6 address is global why have the flow for per
> connection as above. This is a good question and needs discussion.
>
> First the flow assists with the lookup in a binary tree,
> queue type, or
> archaic hash. Its the hint to the next leaf, bucket, or queue entry.
> duplicat highorder bits would cause a branch. This could speed up the
> search before even getting to the global address.
>
> The src + flow could also be used as label for MPLS and its
> in the IPv6
> header.
>
> The business reason could also be that end users would create SLAs for
> their flow labels in addition the bits set for the traffic
> class. This is
> how QOS Int Serv could be realized. And I guess conjunct
> with diff serv
> but that would need to be specified too.
>
> This also benefits client and server boxes too (gateways
> too). We can now
> potentially keep one protocol control block for user connections. tcp,
> sctp, and dcp per connection data structures would not have to be kept
> above the internet per connection datastructures (e.g. bsd
> inpcb would be
> enough). This is a performance win for clients and servers
> for IPv6 not
> just routers or switches or gateways.
>
> If we put a length in the flow yes it can be made to work but
> not without
> being verified by the router as the packet is parsed or
> "policed" then we
> have just put new processing far worse than the IP checksum which we
> removed from the IPv6 router. And opens up opportunity for
> bugs at that
> code point we don't have today.
>
> I also don't support the field being mutable as it transits
> the network
> path to the end destination.
>
> The reason is that we should make IPv6 E2E perform in the
> network as fas
> as possible. If you look at all the work to do VPN, L2TP,
> NAT, Virtual
> Routing, et al that is emerging pervasive for IPv4 the root
> reasons are
> lack of IPv4 address space, the desire to do fast layer 2
> switching, and
> security inspection (e.g. firewalls).
>
> The later two above are the only valid visions. We need to
> eliminate in
> our thinking the mind set developed because of lack of IPv4
> address space.
> I could argue that what is happening to IPv4 is pure professional
> irresponsibility on our part as Internet engineers. The
> Internet should
> remain E2E. This is not a politcal comment or even social
> comment. Its a
> comment stating my assumptions about how the Internet should operate.
>
> I think we need to discuss our assumptions for the
> requirements with the
> solutions we define.
>
> ADSL box providers actually market that NAT helps you because
> you don't
> have to worry about address space. This is absurd and professionally
> irresponsible in the market. We should stop this with IPv6.
>
> The way to do that is give routers the means to forward packets E2E by
> only looking at the header of IPv6. That is what Brian's "b" solution
> does. Plus it benefits all nodes besides routes for IPv6 as I state
> above.
>
> As far as IPv6 extensions. The payload length gives the
> router the entire
> length of the packet. If the flowlabel can be used to
> identify forwarding
> the packet in addition to the address and other parts as I state above
> then there is no challenge for ASIC vendors for strict
> forwarding of IPv6
> packets.
>
> If those vendors want to add more value by digging past the
> header then
> that is their option to add value but I don't believe it is
> required for
> fast forwarding of IPv6 packets.
>
> Steve's design works and I believe can be extended with the
> flowlabell and
> we can get rid of the mess IPv4 is making of the Internet
> because of the
> band-aids being applied.
>
> I believe the End System (and that could be a router in some
> cases or a
> broker router) should set the flowlabel at the access exit before the
> edge. But thats another discussion.
>
> Another discussion is how do we pick good random numbers for
> the flowlabel
> at the access exit end system or even a client.
>
> regards,
> /jim
>
>
> On Tue, 21 Aug 2001, Thomas Eklund wrote:
>
> > I agree alex.
> >
> > It gets worse for people that are doing ASIC which is not
> programmable, then
> > they need to spin a new version their ASIC when the
> protocols changes. For
> > people that are doing programmable ASIC (network processors
> etc) this is not
> > a problem.
> >
> > But common for both approaches is that the header format is
> really challenge
> > for the ASIC engineers
> >
> > -- thomas
> >
> > >-----Original Message-----
> > >From: Alex Conta [mailto:[EMAIL PROTECTED]]
> > >Sent: den 20 augusti 2001 22:15
> > >To: Thomas Narten
> > >Cc: Brian E Carpenter; Bob Hinden; ipng
> > >Subject: Re: Higher level question about flow label
> > >
> > >
> > >
> > >
> > >Thomas Narten wrote:
> > >>
> > >> [...] When someone can make a compelling argument for why
> > >> the bits need to be defined in a certain way (i.e.,
> there is a real
> > >> application for which using the bits provides
> significant benefits,
> > >> and those benefits do not appear achievable through
> other means) that
> > >> is the time to define the bits. What I do sense with many of the
> > >> recent discussions surrounding the Flow Label is that
> there are many
> > >> folks (i.e., folks putting IPv6 into hardware) that want
> to know what
> > >> they should implement w.r.t. the Flow Label. While it would
> > >be nice to
> > >> be able tell them what to do, we shouldn't standardize
> something just
> > >> for the sake of having a definition.
> > >>
> > >> Thomas
> > >
> > >10Gb/sec time wise means 100 psec/bit, or 0.8 nsec per byte, or 3.2
> > >instructions of a hypothetical
> > >1Ghz processor which can execute one instruction per
> cycle. That's a
> > >hell of a requirement.
> > >
> > >As consumers, we all enjoy the very cost-effective availability of
> > >100Mb/sec line speed packet processing in almost every
> > >Notebook, or PC.
> > >
> > >IP and QoS Engines implemented in silicon, on a chip or a
> few chips, by
> > >IBM, INTEL, and many, many others, is one of the reasons of the low
> > >costs, along with the ability to optimizing the hardware
> > >in so many more and different ways than the software (for instance
> > >parallel header, or parallel header field processing).
> > >
> > >1Gb/sec IPv4 packet forwarding is a reality, 10Gb/sec is just
> > >around the
> > >corner, with 40Gb/sec following not long after.
> > >
> > >With such drastic "timing" requirements, implementing engines in
> > >silicon, and inventing *clever* mechanisms to handle the sequential
> > >processing of headers alone, will not be sufficient to
> implement very
> > >cost-effective IPv6 forwarding and QoS solutions, and IPv6 is at a
> > >disadvantage relative to IPv4.
> > >
> > >We need all the help we can get from the protocol, that is
> headers, and
> > >their fields, for forwarding and QoS processing, and by that I
> > >mean both
> > >Intserv, and Diffserv.
> > >
> > >Regards,
> > >Alex
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >>
> --------------------------------------------------------------------
> > >> 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 PROTECTED]
> > >>
> --------------------------------------------------------------------
> > >
> > --------------------------------------------------------------------
> > 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 PROTECTED]
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> 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 PROTECTED]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
