[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI: Framing Steps

    > Its true that the current day IP networks are capable of handling packet
    > drops .... But it is high time to have a mechanism to handle this
    > more efficiently, keeping in view the importance of SANs and their
    > intended use.
    The combination of IP+transport (TCP/IP) is precisely designed to
    deliver data efficiently and scalably (as a function of network size).
    It is the transport layer's role to maximize `goodput'.  Dropping
    packets in the network as a result of congestion and having the
    transport adjust to this is what results in IP's scalability as
    compared to system area (flow controlled) network technologies.  In
    other words, it's a feature, not a bug.  It's a large part of what
    made IP the dominant networking technology, and it's never going away.
    It is not the case that the designers of TCP said `heck, we've got
    these miserable, lossy networks, I guess we'll just suck it up and do
    the best we can, even though it'd work a lot better if we had some
    other characteristics.'
    TCP does have some warts in providing the best possible goodput, but
    those are problems for TCP (or other transport) to fix.  Anyway, that
    doesn't seem to be what you're referring to.
    The RFC 1122 SHOULD says TCP endpoints should cling tightly to each
    correctly received byte.  If an implementation is discarding portions
    or entire flights of data because a packet is lost that's certainly
    NOT TCP's problem, and not what FIM is intended to fix.  FIM's (or any
    framing technique's) ONLY goal is to reduce the COST (which may equate
    with `tractability' if the cost is otherwise prohibitive) of an
    efficient implementation.  It does not improve the data transport
    efficiency itself at all.


Last updated: Tue Jan 29 14:17:56 2002
8542 messages in chronological order