Subject: [rddp] Re: [Tsvwg] Another Possible Argument for IFT over MPA

From: Joe Touch <[email-masked]>
Date: Thu, 31 Oct 2002 09:40:07 -0800

Williams, Jim wrote:
> I did not include this argument in the 
> draft because I am unsure of its validity.
> I would hope, though, to get some feedback
> from this group as to whether this makes
> sense or not.
> 
> The argument is based on how best to deal
> with out of order received packets.  The
> primary reason for out of order received
> packets is that often packets are dropped
> due to congestion and must be retransmitted.

A secondary reason is that IP does not guarantee in-order delivery.

> The receiver will see a gap in the received
> stream of data, which will be filled in
> later when the dropped packet is retransmitted.

> MPA proposes to address this problem by
> providing a more efficient mechanism for 
> dealing with these out of order packets.
> It does so by adding complexity at the
> application layer (above the transport),
> and requiring implementations wishing
> to exploit this feature to merge the
> TCP, MPA, and DDP layers.

TCP is required to fix out-of-order; this cannot be left to the 
application, or any layer that is descernably separate from whatever is 
called "TCP". The TCP API is "in-order, reliable, byte stream". Anything 
that doesn't provide that API isn't TCP.

> What I am not clear on is what is the rate
> of adoption of ECN within the internet
> switching infrastructure, and to what
> extent can we realistically expect this
> to drive down the packet drop rate for
> endpoints that support ECN.

Down != 0. Even ECN drops packets.

Joe

_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Nivedita Singhvi <[email-masked]>
Date: Thu, 31 Oct 2002 10:19:09 -0800

> later when the dropped packet is retransmitted.

Just for the record, other reasons for out of order
packets can be SMP issues - on a large system like
an 8, 16 or 32 way box, we see a lot of out of order
packets simply because interrupts get fed to different
CPU's and some interrupts get up the stack faster, 
resulting in the TCP engine seeing packets out of
order although they came in over the wire in order.
ECN and other external mechanisms cannot help in
this case..

thanks,
Nivedita