[email protected]
[Top] [All Lists]

Re: composite link - candidate for respin, maybe

Subject: Re: composite link - candidate for respin, maybe
From: Curtis Villamizar
Date: Tue, 30 Mar 2010 01:36:09 -0400
In message <[email protected]>
John E Drake writes:
> Tony,
> I was looking at this situation as a special case of placing
> different flows on different component links.  So, you are correct in
> saying that flows may be re-ordered which is business as usual, but
> within the flows the packets are not mis-ordered. 
> I.e., packets within a given flow would be placed on either the new
> component link or the old component link.  After some period of time,
> packets of all flows would be placed on the new component link and the
> one hop LSP on the old component link would be torn. 
> Thanks,
> John 


When nothing is being moved nothing is reordered.  If a flow or many
flows is moved from a link with longer delay to one with shorter
delay, unless the flow is stopped and bufferered for at least the
delay difference and then drained, then reordering will occur.

So I agree with Tony.  It is not practical to avoid reordering when
traffic is moved.  It is therefore minimally disruptive.  The products
of your new employer do the same thing.


> > -----Original Message-----
> > From: Tony Li [mailto:[email protected]]
> > Sent: Monday, March 29, 2010 1:37 PM
> > To: John E Drake; Mcdysan, David E
> > Cc: [email protected]
> > Subject: Re: composite link - candidate for respin, maybe
> > 
> > 
> > 
> > Hi John,
> > 
> > > The e-mail to which I was replying stated that there might be packet
> > > re-ordering, and I was just pointing out that a reasonable
> > > implementation can avoid either packet re-ordering or loss.
> > 
> > I have to respectfully disagree.
> > 
> > The case that Dave points out is exactly right: if a router is
> > transitioning
> > to a link of lower delay, then has no choice but to risk mis-ordering
> > packets.  The only other implementation alternative is to actually buffer
> > them, which has some horrible side-effects for congestion control.
> > 
> > Alternatively, if you have some magic that you're willing to share with us
> > wherein you can get some packets to move faster than others, we'd love to
> > know about it.  ;-)
> > 
> > Tony
rtgwg mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>