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

From: "Williams, Jim" <[email-masked]>
Date: Thu, 31 Oct 2002 12:15:55 -0500

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.
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.

ECN addresses the same problem in a very
different way.  It allows routers to control
congestion without the need to drop packets.
Theoretically, if ECN is widely deployed
and used, dropped packets could become
sufficiently rare that it would not be
important for end points to handle them
efficiently.

ECN seems like a much
simpler, cleaner, and preferable way
to address this problem.  Given the choice,
it would make sense that this is the
direction in which the internet architecture
should be driven.

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.

Feedback from anyone knowledgeable about
ECN and about internet architectural
direction in general would be quite
valuable.

Thanks, Jim Williams

Drafts under discussion:

  http://www.ietf.org/internet-drafts/draft-williams-iwarp-ift-00.txt

  http://www.ietf.org/internet-drafts/draft-culley-iwarp-mpa-00.txt

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

---

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

> due to congestion and must be retransmitted.

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

> 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.

> endpoints that support ECN.

Down != 0. Even ECN drops packets.

Joe

---

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