Re: suggestion.

[Danial Thom <danial_thom@xxxxxxxxx>]

--- Joshua Coombs <jcoombs@xxxxxxx> wrote:
> > 3) MPPP has an archaic requirement that
> packets
> > arrive in order. This requires front end
> queues
> > similar to fragment processing, that is a
> waste
> > of memory, cpu cycles and results in slowed
> > connections, since all modern TCP stacks can
> > handle out of sequence packets.
> > 3) MPPP was designed for slow, dial-up lines
> (and
> > ISDN). Per packet load balancing gives better
> > performance in the real world, with lower CPU
> > usage.
> 
> Actually, as a network engineer, there are
> times that guaranteed 
> packet delivery order, across multiple 'bonded'
> links is a 
> requirement.  While base TCP may tolerate out
> of order delivery, there 
> are apps that ride ontop of it that cannot,
> such as VoIP.  MGCP 
> sessions using G7.11 compression basically
> treat out of order packets 
> as dropped packets.
> 
> Per Packet it good, but its not always the
> right tool for the job.

As a "network engineer", you should know that the
internet in general doesn't guarantee in-order
packet delivery. So any application that doesn't
handle it is simply unreliable on the internet.
If an application requires in-order delivery, you
can direct the traffic to use a single link. But 
you can't guarantee what happens once its out of
your network. So without a transport layer your
application is just a crapshoot. 

You have all sorts of load-balancing going on
throughout the internet, and almost none of it
guarantees in-order delivery. So if you sabotage
your own link thinking that you're going to make
something work, then you just don't understand
the big picture.

Danial


		
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html