Re: [RAM] The mapping problem: rendezvous points?

[Ted Hardie <[e-mail]>]

At 11:07 AM -0700 5/9/07, David Conrad wrote:
>Ted,
>
>On May 9, 2007, at 10:47 AM, Ted Hardie wrote:
>>Sorry, but I misunderstood you to be asking for what class of applications have
>>this problem, and my reply was intended to answer that:  those which do codec
>>negotiation based on observed rate.
>
>And how do those codec negotiations/ICE behave in the face of network congestion today?

For the codec negotiations, they downgrade or, as Marshall pointed out, they
may fail if only a single rate was supported.  For ICE, it will pick the flow
which returns successfully first.  I believe that this means that whether or
not a lookup is in cache will have a significant impact on which flow end points
are chosen in ICE.

For how do they work now, I think the key thing here is that they preusme congested
links will likely stay congested (or, depending on whether TCP's sawtoothing is
involved) may go from congested to uncongested and back during the
course of a flow.  In those conditions, a media stream using a UDP-based flow
*should* use a low-rate rate codec and should negotiate upward only
cautiously.  Otherwise its lack of congestion awareness is going to
be unfriendly to other flows.   Having a lookup delay at the start of the flow mimics
that congestion and produces sub-optimal results. 

I think the problem here may be that the lookup sounds like it is incurred
within the period of time that the application considers the flow to be
active and which it is using to gauge bitrate.  If the delay were entirely before the
flow were active (as it is for DNS lookups mapping the fqdn to a target
IP), then the clock would not have started ticking, so to speak, and this
delay would not have follow-on effects (it might add to existing frustration
at slow starts, but that is a different problem).  There may well be a way to
design that in at this point, but I think that works well only if the lookup
is at the host.  I may be missing something, of course.

>>Are you looking for something that has source code available, so you can see
>>what changes it would take to adjust the paradigm, or ubiquity, or what?
>
>Pointers to source code would be nice.

pjsip has opensource stun, turn, and ICE; TIL has opensource ICE:

http://www.pjsip.org/download.htm
http://sourceforge.net/projects/til

The codec negotiation bits are a bit harder to point to, since
the rate adaptation code tends to be buried in a larger piece of
codec development.  Marshall may have a better suggestion, but
the videolan work, in particular on x264, may be useful.  That's
at:

http://www.videolan.org/developers/x264.html


>I guess where I'm seeing a disconnect is in the fact that the Internet today is best effort, has congestion events, asymmetric routing and non-deterministic performance patterns.  If an application works today, I'm having trouble understanding how the introduction of additional O(10-100ms) latencies in the event of a cache miss (which will likely only occur at the first packet in a packet train) is going to have significant impact.  In those odd cases that there is an impact, how much work would it be to modify the application operation to be more tolerant of network delays?

I believe that there are changes which could be made to overcome this.  One
obvious one is to have bitrate negotiation for codecs delayed until the impact
of this on the flow was no longer important ( easy enough if it is only the first packet
in the packet train), or allow for a single fast renegotiation, contrary to the usual
slow renegotiation.  So the amount of work is "some". 

But the bigger issue is that there is a class of applications which *wants* to know
about the network conditions and topology, so that they can modify their behavior
to handle it.  I don't think that is going away.  To me, that argues for including
the hosts in the set of network elements which at least MAY if not MUST participate
in understanding the locator/id split semantics and mechanics.  Or, to put it another
way, to participate in the routing system.

>Clearly, some believe that pull simply won't work.  I'm trying to understand why.  To be honest, it feels a bit like arguments I used to hear from Bellheads explaining why real production data communications could never work on datagram based networks...
>Rgds,
>-drc

			regards,
				Ted

_______________________________________________
RAM mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ram