Re: IP Storage Framework document

[Vern Paxson <vern@ee.lbl.gov>]

> If we accept your arguments that TCP is
> the solution, why not do away with IP and create TCP flows through the
> network?

Because there's a wealth of applications that don't need strongly reliable,
in-order delivery.  But IP storage doesn't appear to be one of them.

> What if we identify features or requirements for IP storage that
> would benefit from capabilities that TCP does not provide, such as multicast?

Worth discussing, but if you want reliability, for multicast this gets
hairy very fast ...

> I just don?t know if everybody will buy argument that TCP is the single
> cure-all for all the network?s ills.  That slow start thing is a particular
> concern for me.

Not an issue if you keep the connection open and active.

> The additional cost to do MTU discovery (which everybody
> doesn?t do currently) is a concern to me -- why bother if it?s always
> 1500?

Likewise, not an issue if you keep the connection open.

> I can find an argument for TCP and one against TCP,
> which seems to say that we should be flexible in our thinking.

You need to be more detailed in these arguments.  This is old ground for
TCP folks, so it really does require specifics to convey why it might not
be appropriate.

> I hope UDP is not new fangled protocol,
> at any rate. :-)

It's not, but it does nothing other than graft port numbers and a weak
checksum on top of IP, so it's hardly a rich protocol.

> Some of the UDP-related problems that you are mentioning,
> we can clearly provide optional mechanisms to cure it for those who want
> to cure it.  Key word here is optional.  Those who do not want to use
> these options, they don?t -- and they still interoperate.

This fails for congestion control.  It also fails for strong reliability -
it's all too easy to do fairly weak reliability, and it works fine until
you start stressing things.

> It is probably not in the IETF?s interest to be dictating to vendors and
> customers on how they build their networks and storage systems.

Well, if this isn't something the IETF needs to standardize, fine, less
work for me (as Transport co-AD).  But if the IETF is going to standardize
it, then it will be held to the usual requirements of soundness.

All that said, it seems the #1 step is to get the requirements fully
described.

		Vern