[AVT] Re: [Tsvwg] Re: Last Call: The UDP Lite Protocol to ProposedStandard

[Michael Welzl <[e-mail]>]

Folks,

I'm gonna try and answer two separate mails at once.


Following with my last comment (as a reply to Phillip) about
signalling the BER with an IP option, Randall wrote:

> The minute you put in IP-Options most routers will pull this
> OUT of the fast path and dump it up to software. Think SLOW SLOW
> SLOW.. so IP-Options may help in someways but they surely will
> NOT help with your delay.. they will increase it..

I know, but don't care   :)
I really don't think that these options should be used with
EVERY UDP Lite payload packet - this should just be used
sporadically. Like a network layer service that can be
requested by the transport layer: "give me a reasonable
BER estimate". The problem is that you get at least one
payload packet that will arrive much later ... but there's
really nothing we could do about that, I suppse.


In a response to Keith, Michael (Ramalho, not met  :)  ) wrote:

> Are you proposing a UDP-lite protocol that can piggyback link
> performance
> information on the payload (an interesting research topic BTW)? 

That was my original proposal, more or less ... additional fields
in the UDP Lite header. Phillip disagreed with this method because
it has routers recompute the UDP Lite checksum and thus loose
end-to-end data integrity, and he's certainly right.

I am pretty sure that _IF_ we need such signalling, an IP option
would be the way to do it. This way, the information could also
be used by other protocols, although it's hard to imagine which
kind of protocol might use this information. MAYBE some new
congestion control mechanism ... but that would bring about several
complex issues.

Another reason for an IP option: there's no reason for routers
to add the information to EVERY packet. If you add special fields
to UDP Lite, you either request the information all the time or
you're wasting space.


But:

> Rather than continuing this discussion ... please propose a metric (or
> guidance) you want to use that is generic enough for most/all links.

> Warning: an average error-rate metric is probably of little value ...
> there
> are sharp knees in S/N vs. BER curves. I only wish we could mandate
> good/clean/predictable wireless/IR links for the "reasonable
> assurances"
> you desire above for some of these links... but I can't.
> Cellular phones
> prove that otherwise unacceptable audio performance is tolerated in
> exchange
> for another benefit (mobility). There is no reason to believe that
> wireless IP
> links would be significantly different.

That sounds reasonable to me. I don't think we should create an
IP option (or any other kind of link layer information signalling)
unless somebody can come up with a good metric (e.g.,
a degree of how correlated bit errors are?) and probably
some proof that this metric is actually useful for the application.
I'm cc'ing AVT...

Cheers,
Michael



_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt