Re: TCP limitations (was Re: ISCSI: Urgent Flag requirement violates TCP.)

[julian_satran@il.ibm.com]

Interesting argument. How would you end up paying the extra copy but not
paying the extra memory?

Julo

Vern Paxson <vern@ee.lbl.gov> on 24/11/2000 10:45:11

Please respond to Vern Paxson <vern@ee.lbl.gov>

To:   Stephen Bailey <steph@cs.uchicago.edu>
cc:   ips@ece.cmu.edu
Subject:  Re: TCP limitations (was Re: ISCSI: Urgent Flag requirement
      violates TCP.)




> > But the Urgent pointer only helps when you happen to have a sequence
> > hole.  So how in practice can it be worth the effort?
>
> It will permit a high speed endpoint to deliver full pipe aggregate
> throughput across multiple streams.

Then I still have another question/concern.  What happens with
out-of-sequence
data that arrives that doesn't have an Urgent pointer within it, either due
to coalescence or because there just doesn't happen to be an ISCSI header
in the packet?

I would hope it's buffered even though the receiver doesn't know where it
should ultimately wind up.  Indeed, if it isn't buffered, then the TCP
exhibits the "Failure to retain above-sequence data" problem documented in
RFC 2525, and is not unconditionally complaint with the TCP standard.

But if there's sufficient buffer for this case, then there pretty much
needs to be sufficient buffer for the general case (all data in flight,
whether or not it contains an ISCSI header), and also a mechanism to copy
the data from its initial buffer to its final location.  In which case,
what the Urgent framing gains is some performance (avoiding a buffer copy),
but not a savings in memory.  However, you only get this performance gain
for a stream that is likely slowing down, so it still seems to be a corner
case and not a significant win.

          Vern