W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

Re: HTTP over SCTP without chunked encoding

From: Fred Baker <fred@cisco.com>
Date: Thu, 25 Jun 2009 17:37:37 -0700
Cc: leighton@mail.eecis.udel.edu, Mark Nottingham <mnot@mnot.net>, ietf-http-wg@w3.org, amer@cis.udel.edu, prenatar@cisco.com
Message-Id: <DB1DEAEE-FCC8-4CBD-B001-534512255579@cisco.com>
To: Henrik Nordstrom <henrik@henriknordstrom.net>
I would first ask how often this is an issue - I certainly stop http  
downloads from time to time, but it's not a primary behavior.

It also seems to me that the problem is self-correcting. If I have N  
potential streams and have opened M file downloads, of which I want to  
stop one, I can redirect the errant stream to /dev/null until the  
other downloads complete. At that point, it is either done or not  
done. If it completed in the meantime, I lost 1/M of my available rate  
during the event but nothing permanent happened. If it is not  
complete, I can kill the session and open a new one. And btw, since I  
will change the cookie, I could even reopen it using the same port  
number.

On Jun 25, 2009, at 5:18 PM, Henrik Nordstrom wrote:

> tor 2009-06-25 klockan 16:53 -0400 skrev leighton@mail.eecis.udel.edu:
>
>> Can you elaborate on your comment about trying to map multiple  
>> pipelined
>> TCP connections to a single SCTP association not working out well?
>> Thanks.
>
> Sorry, should have said multiple TCP connections vs a single SCTP
> association. It's not related to pipelining but the differences in
> transport level (in HTTP terms) signaling between multiple TCP
> connections and a single SCTP association.
>
> The main problem there is selective stream cancellation by the client.
>
> If all pending requests is to be canceled together then this is not an
> big issue, just tear down the SCTP association and be done with it.   
> But
> if you need to more selectively cancel requests (i.e. a big download  
> you
> accidently started) without breaking the other concurrent pending
> requests then things get a little trickier..
>
> In the TCP case (non-pipelined) the client just closes that TCP
> connection which terminates that requests with no impact on the other
> requests.
>
> Regards
> Henrik
>
Received on Friday, 26 June 2009 00:38:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:04 GMT