Subject: RE: MSRP: Are REPORTs per-chunk or per-message? (was Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - Byte Ranges in REPORTs )

From: Eric Burger <[email-masked]>
Date: Wed, 10 Nov 2004 21:01:11 -0500

Even though I would be thrilled if this stuff came out, because the
value/pain ratio is really low, I had a bizarre thought for a 4/1/2005 RFC
that relies on chunking, byte ranges, and retransmission of missing chunks.

More news after I finish my comprehensive exam :)

> -----Original Message-----
> From: David R Oran [mailto:[email-masked]]
> Sent: Friday, October 08, 2004 10:01 AM
> To: Ben Campbell
> Cc: Cullen Jennings; Rohan Mahy; Adam Roach; Aki Niemi; Paul Kyzivat;
> Simple WG
> Subject: Re: MSRP: Are REPORTs per-chunk or per-message? (was Re:
> [Simple] Review of draft-ietf-simple-message-sessions-08 - Byte Ranges
> in REPORTs)
> 
> 
> Based on this exchange, I suggest we rename the protocol to 
> MHRFTPWCBYFIM.
> 
> (Multi hop recoverable file transfer protocol which could be used for 
> instant messaging).
> 
> I am getting creeping featurism vibes here, guys...
> 
> Dave.
> 
> On Oct 7, 2004, at 11:07 PM, Ben Campbell wrote:
> 
> >
> > On Oct 5, 2004, at 3:58 PM, Paul Kyzivat wrote:
> >
> >>
> >>
> >> Ben Campbell wrote:
> >>> On Oct 5, 2004, at 7:09 AM, Aki Niemi wrote:
> >>>> On Sat, 2004-10-02 at 01:16, ext Ben Campbell wrote:
> >>>>
> >>>>> Oops, I just realized I missed one of Paul's comments.
> >>>>>
> >>>>> Paul suggests there is no value saying what part of a message 
> >>>>> fails,
> >>>>> only that the whole message fails. I disagree. If a 
> sender learns 
> >>>>> that
> >>>>> a particular byte-range failed, it may be able to send 
> a new chunk
> >>>>> containing that byte range.
> >>>>
> >>>>
> >>>> I don't get this. We have a protocol that runs on top of a TCP
> >>>> connection, or a chain of TCP connections. The only way 
> a chunk can 
> >>>> ever
> >>>> get lost without anyone noticing it hop-by-hop is if 
> someone's input
> >>>> buffer or output buffer is seriously leaking bits. Do we really 
> >>>> need to
> >>>> design around that hypothetical condition?
> >>> On reflection, I think I am mostly convinced that you are 
> right. The 
> >>> only case I can think of  is when you successfully send a 
> bunch of 
> >>> chunks, the session fails, you signal a new session, and 
> attempt to 
> >>> resend the content. One could be saved the task of 
> sending all the 
> >>> parts that had already been delivered. But I think I 
> agree that this 
> >>> benefit is not worth the additional complexity and statefulness 
> >>> necessary to make it work.
> >>
> >> The significant case now occurs to me:
> >>
> >> - we are sending that 7gb Lord of the Rings as one message,
> >>   and part way through the tcp connection fails somewhere
> >>   along the way. (Maybe a relay crashed.)
> >>
> >> - it would be good not to have to retransmit the part that
> >>   got there. Would prefer to establish a replacement
> >>   session and just send the part we aren't sure was received.
> >>
> >> To make this work, the sender needs to have received 
> success reports 
> >> for fragments. Maybe this is worth supporting them.
> >>
> >> Of course the recipient is still free to just send a 
> single success 
> >> report at the end, or it can periodically send reports for 
> arbitrary 
> >> byte ranges that it has received ok. These wouldn't have to 
> >> correspond to the actual chunking of the message. One 
> could simple be 
> >> sent every so often, reflecting what has been received to date.
> >>
> >> So I think I have talked myself back into liking this for success 
> >> reports.
> >>
> >> I'm still not convinced about the value in failure reports, but if 
> >> the range can be there for one then why not the other?
> >>
> >
> > I had a conversation with Cullen, where he expressed the 
> same opinion 
> > for failure reports. Imagine, in your LoTR example, you 
> were using a 
> > relay, and it has a transport failure between itself and 
> the next hop. 
> > It sends you one or more failure reports for the chunks for 
> which it 
> > could not confirm delivery. You establish a new session, 
> and continue; 
> > resending the failed chunks.
> >
> > I'd like to close on this quickly, so I offer the following 
> questions 
> > to anyone who cares. I would appreciate opinions asap, so I can get 
> > this into the next revision.
> >
> > 1) Should failure reports be sent per chunk or per complete 
> message? 
> > (I think it is per chunk.)
> >
> > 2) Should success reports be sent per chunk or per complete 
> message? 
> > Note that, if we send them per-chunk, then the sender must 
> accumulate 
> > 1 or more reports covering all the bytes in the message 
> before it can 
> > consider the message successful. These reports may or may not 
> > correspond one-to-one with the chunks it sent, as a relay may 
> > re-chunk.
> >
> > (Again, I vote per-chunk.)
> >
> > 3) Do we need to say anything about how long the _receiver_ 
> holds onto 
> > the chunks of an incomplete message in hopes any remaining chunks 
> > arrive? In particular, do we need to talk about this for holding 
> > chunks after a session fails, in case the sender establishes a new 
> > session and sends the remaining chunks?
> >
> > (I vote that we say no more than we already did in 08 concerning 
> > re-sending chunks on new sessions.)
> >
> > 4) Do we need to enable the receiver to send a failure report about 
> > _missing_ chunks? This does not make sense with success reports 
> > requested, but might make sense when only failure reports are 
> > requested.
> >
> > (I vote no, as I think that, if failure reports are requested, any 
> > such failure will be discovered and reported by some 
> up-stream device 
> > except in the most rare of corner cases. The exception is when the 
> > sender does not actually send all the chunks; but if that 
> happens it 
> > doesn not need to be told about it by another device.)
> >
> >
> >> 	Paul
> >
> >
> > _______________________________________________
> > Simple mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/simple
> >
> David R. Oran
> Cisco Fellow
> Cisco Systems
> 7 Ladyslipper Lane
> Acton, MA 01720 USA
> Tel: +1 978 264 2048
> Email: [email-masked]
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple