Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 6: Resend behavior

["Ali C. Begen (abegen)" <[e-mail]>]

> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]]
> Sent: Wednesday, January 19, 2011 9:27 AM
> To: Ali C. Begen (abegen)
> Cc: IETF AVT WG; [e-mail]
> Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 6: Resend behavior
> 
> Ali C. Begen (abegen) skrev 2011-01-18 14:10:
> >
> >
> >> -----Original Message-----
> >> From: Magnus Westerlund [mailto:[e-mail]]
> >> Sent: Monday, January 17, 2011 10:04 AM
> >> To: Ali C. Begen (abegen)
> >> Cc: IETF AVT WG; [e-mail]
> >> Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 6: Resend behavior
> >>
> >> Ali C. Begen (abegen) skrev 2011-01-17 14:24:
> >>> OK, I see your concern, however, should not we still follow 4585 as it is and once it gets updated, it will be reflected
> here?
> >> If the immediate mode is chosen, the NACK/RAMS could result in many more spurious transmissions whereas the token
> stuff
> >> only results in one such transmission. So putting some extra rules here for the tokens only will not get us much.
> >>>
> >>> Maybe, we can add some text to disallow the immediate mode?
> >>
> >> You seem to be punting on this issue. I think Immediate mode needs to be
> >
> > Did not even cross my mind :)
> >
> >> allowed, it makes all the sense for these type of applications in
> >> certain environments. However, what is needed is a separation of the
> >> "packet loss" / "failure for server to act on event" detection mechanism
> >> and the RTCP transmission rate limiting.
> >
> > Well said, but with RTCP one can do so much.
> 
> Ok, can we at least point out that this issue exist and that
> implementations needs to do something reasonable about detecting loss,
> and not soley rely on sane configuration values of the RTCP bandwidth.

OK, we will mention this and add a warning.
 
> >
> >> I think despite our discussion of these things in CCM (RFC 5104) we did
> >> fail to take all the AVPF cases into account. I have to say that 3.5.1.1
> >> do rely on repeating FIR messages until you get an result. It does fail
> >> to say in which mode and what type of transmission should be used for
> >> the repetitions. This as one in early mode, this is either classified as
> >> an event that are allowed to send early, or as a regular transmission.
> >>
> >> There need to be some sanity checking in this, and going forward being
> >> aware that what we specify can be seriously broken is not the best
> >> thing. In addition RAMS can be fixed. And the NACK still doesn't have a
> >> spec for this use case.
> >
> > OK, let me ask you this. Even if we come up with a miracle solution for the token stuff, that still does not fix the bigger issue
> that one might have with NACKs (I am omitting RAMS here since RAMS has some other natural limits, e.g., a client would not
> really have multiple outstanding RAMS requests unless it is attacking the system).
> >
> > So, maybe we should actually talk about fixing this in general for 4585?
> 
> I do agree that RFC 4585 should be updated to take this issue into
> consideration.

Cool. That will help us in the long term.
-acbegen
 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------