The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <C0E157CF34C85A4A80A5AC405E561C74038FB793@OCCLUST01EVS1.ugd.att.com>
, "GOODE, B (Bur), ALABS" writes:
> We (AT&T) and Raymond (Infonet) clearly stated that we were talking
> about G.729 at 8 Kb/s.  Curtis responds with an example of G.711 using
> 64 Kb/s.  We cannot afford more than 30 ms packetization delay in our
> delay budget.  20ms would be preferable References to 200-300 byte
> packets is just absurd.
> 
> Bur


Bur,

Thanks for the clarification.  btw- Even G.722 is 24 to 32 kbit/s.

All of these encoding seem to sample at 20 msec.  At least doubling up
to 40 msec would be reasonable and very simple.  I can understand if
you don't want to do that.  Please read on.

AFAIK G.729 is used for cell phone only and there are good reasons to
send very low bandwidths and small packets over the airways.  Even if
you did G.729 end to end, you're not going to do RSVP/TE signaling
from cell phone to cell phone or cell phone to POTS handset.  (Please
correct me if I'm wrong about that).  If you are doing G.729 end to
end, and really want 20-30 msec, then I suppose you really do have to
either 1) mux at the gateway or 2) increase the delay a bit, 3) live
with tiny payloads.

[Aside: If the RTT on a cellular link is as high as 100-200 msec (each
end of a call), fussing over another 20-50 msec in the core does not
seem to me like it should be such a big deal, but that's also not my
decision.]

Even if you are going to go G.729 end to end (voice gateway to voice
gateway), you certainly won't be doing per call RSVP/TE signaling
(correct me if I'm wrong).  It will be at most one RSVP/TE tunnel
gateway to gateway.  If so, you can keep the small delay budget and
mux except in the rare case of one call per gateway pair.  If there
are that many gateways that one call per gateway pair is common, it is
extremely unlikely E2E RSVP/TE signaling is going to scale.  If the
number of gateways is much smaller, then multiplexing becomes feasible
in principle and can even reduce the delay down to 10-20 msec while
keeping payloads large.

This leads to the question - if multiplexing is feasible in principle
is it practical.  RTP itself doesn't supports multiplexing except by
means of channels.  The number of channels and mapping of channels
could be mapped using SDP and a new SDP "a=" attribute.  If you don't
like SDP or would prefer not to use it, you'd need some other protocol
to maintain the mapping of channels to calls.  I'm sure this is
different from your current encapsulation but so is VO/MPLS with
header compression and it might be something that Infonet might be a
lot better off doing than trying to create end2end RSVP/TE sessions.

If you are really are going to pursue this sort of design, then it
would be helpful to know how scalable RSVP/TE would need to be and how
you plan to maintain scalable RSVP/TE signaling.  Hierarchical will
only get you so far.

You might want to consider just compressing the RTP/UDP headers,
yeilding as little as 24 byte overhead (IP+4) instead of 40
(IP+UDP_RTP).  This would eliminate the reliance on E2E RSVP/TE.

btw- I sincerely thank you for replying.  Too many SPs are too silent
publicly about what they want to do, making IETF work harder.

Regards,

Curtis

ps - [aside: any thoughts on AMR and AMR-WB rather than G.729?
23kbit/s for AMR-WB except during congestion.  Larger packet sizes
might actually releive some of the cell site congestion and the
100-200 msec delays though I understand rfc3095 can address this to a
large extent.]