Re: [arch-d] HTTP 2.0 + Performance improvement Idea

I am not sure if an NFS client can accept blocks out of order from a
server.I need to check on that. If it does then NFS over HTTP sounds good.
The way i see it is any File service protocol such as NFS, SMB (Large
MTU's), HTTP, FTP should have a way which would help the server achieve
true parallelism in reading a file and not worry about sending data/blocks
in-order.

Rakshith

On Wed, Mar 26, 2014 at 2:47 AM, Joe Touch <touch@isi.edu> wrote:

> You sound like you're looking for NFS; maybe you should propose an "NSF
> over HTTP" variant where responses can be issued out of order?
>
> Joe
>
>
> On 3/25/2014 4:56 AM, Rakshith Venkatesh wrote:
>
>> Hi,
>>
>> I was going through SPDY draft or the HTTP 2.0 initial draft. I had an
>> idea which I think would require a change in the architecture of the
>> same and so I am dropping this mail. Here is the idea:
>>
>> A Http client expects the server to send data in-order. (NOTE: When I
>> say a server, I am referring to an appliance to which disks are attached
>> and the file resides on the disk.). If there is a file let's say 10GB
>> and if the client asks for this file from the server, the data has to be
>> given in-order from the 1^st byte till the last byte. Now let's say I
>>
>> implement an engine at the server side to do a parallel read on this
>> huge file to fetch data at various offsets within the file, I will be
>> able to fetch the data faster for sure but, I will not be able to send
>> across the data immediately as and when I fetch it. I am expected to
>> finish doing all parallel reads on the file till I read all the bytes,
>> then send across the wire to the client.
>>
>> Now if we can have some tag or header which can be introduced as part of
>> HTTP 2.0 which actually can help re-order the byte stream at the session
>> layer or at a layer in between the application and session layer, we
>> could potentially improve the performance for File reads using HTTP by
>> making sure that the new module looks at this new tag and jumbles around
>> the data based on this tag and eventually presents the data to HTTP to
>> make it look all seamless.
>>
>> So the server can just do parallel reads on the same file at various
>> offsets without worrying about ordering and send across the read chunks
>> and this new module sitting at the client side can intervene and look at
>> some form of tag/header to make sure it swaps the data accordingly and
>> waits till all data is received and then present it to the Application
>> protocol.
>>
>> NOTE: I am not referring to packet-reordering at TCP.
>>
>> By having this, servers can attain true parallelism in reading the file
>> and can effectively improve file transfer rates.
>>
>>
>> Thanks,
>>
>> Rakshith
>>
>>
>>
>> _______________________________________________
>> Architecture-discuss mailing list
>> Architecture-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/architecture-discuss
>>
>>