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

[Magnus Westerlund <[e-mail]>]

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.

>  
>> 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.

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]
----------------------------------------------------------------------