[asterisk-dev] extend IAX2 IE proposal

[Tilghman Lesher]

On Monday 11 December 2006 20:15, Derek Smithies wrote:
> On Mon, 11 Dec 2006, Russell Bryant wrote:
> > I was thinking of this exact same idea.  Another reason for
> > choosing this over the previous proposal is that we only take up a
> > single IE identifier, as opposed to 16.  This method takes up an
> > extra byte to store the segment number, but given that you had to
> > segment the IE in the first place, you're already sending a
> > significant enough amount of information where the extra byte does
> > not make much of a difference.
> >
> > Unless there is any opposition, this proposal gets my vote.
>
> Well no..
> I am not happy with this. Yes yes, it will work to a size of 4096
> bytes or some such size. But what happens if someone wants 20K bytes?
> Should we not, at this time, think about future requirements? I am
> thinking of when iax2 is used as an alternative to MSN, and people
> are doing file transfers over iax2. Or other such large transfers.

Why would you do those in full frames instead of mini-frames?  Full
frames are used for small bits of information that are encoded together
into a single packet.  Mini-frames are used to transmit packets of a
much larger stream.

> The proposal above is, in my view flawed - it does not go large
> enough. Worse, there has been no discussion on how it will go on a
> moderately lossy link. The calculation I put forward a while ago was
> based on 100 K bytes, and 0.1% loss. Now, on a 1 % lossy link, what
> happens? audio quality is poor, and they send out a large packet. The
> packet does not make it through, and all full frames are held up,
> waiting for this super large packet to go out. Does that mean the
> link is frozen in an up state, and one cannot send the hangup
> message?

As others have pointed out, sending a 100K packet is impossible.
Period.  64k is possible, though with MTU set much lower, transmitting
anything beyond 1500 bytes, beyond anything but a LAN, is a pipe dream.

If we want to do anything along these lines, we have to concede that
we need to send 1500 (or slightly less, depending upon the media) byte
packets and find an alternative method for ack'ing the packets.  Holding
up delivery of must-deliver packets because we sent something larger
than the MTU (and the fragments aren't all getting through) is a
ridiculous proposition.

We have a few options:
1) create a third type of frame, which is ack'ed, not for realtime
media, but also does not hold up the control frames, or
2) use the existing mini-frames, but depending upon the frame type,
ack and/or request retransmits, or
3) use TCP for non-realtime transfers.

-- 
Tilghman