Re: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc2326bis-19.txt

[Rémi Denis-Courmont <rem at videolan.org>]

Le mardi 2 décembre 2008 11:01:55 Magnus Westerlund, vous avez écrit :
> > But is it doing anything useful?  HTTP proxies function perfectly well
> > without any equivalent.  The rules for RTSP pipelining are the same as
> > non-pipelined requests: that responses must be delivered in the same
> > order as requests, so there is nothing that the CSeq field adds.
> >
> > I think there is a strong case to be made that CSeq only ever made sense
> > for unreliable transports, and there is no value that it adds for
> > reliable transports.  While it does not do much harm, it really seems to
> > be unnecessary.
>
> I agree that the header is not necessary for the functioning of the
> protocol. I think the main argument for keeping it is debugging and
> handling error cases, like lost message boundaries requiring
> resynchronization of the message flow.

If message boundaries are "broken", only one of the fragment will contain 
CSeq, so it's hardly of any help.

> Please do remember that TCP is not guaranteed free from errors.

I don't understand this argument at all. If a TCP session suffers packet loss 
(whether it's recovered or not) or re-ordering, the applications layer will 
NOT see it, so CSeq does not help in any meaningful way. HTTP does not have 
CSeq, yet we have no problem debugging it.

As for packet captures, we have the TCP sequence number already. Wireshark has 
long since learnt how to re-assemble TCP.

-- 
Rémi Denis-Courmont
http://git.remlab.net/cgi-bin/gitweb.cgi?p=vlc-courmisch.git;a=summary
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic