The IP over ATM Mailing List Archive by date

[Curtis Villamizar <curtis@ans.net>]

In message <9510202106.AA16214@ra.npr.legent.com>, Pat Medved writes:
> 
> 
> I was reading some studies which indicate up to 70 % of TCP/IP
> packets are < 10 bytes.  For ATM that means 2 cells per packet.
> If we were using header compression, then these would only need one cell.
> I have seen some papers mentioning this.  I also saw studies indicating
> that the 64KB window size will be too small.

Did you mean <100?  (If not what studies were these?).  That might
make sense since TCP ACKs are 40 bytes and quite common.  Our figures
have shown average packet size of about 200.  This is growing for most
normal IP traffic (we have a specific customer that will be giving us
lots of tinygrams until they change their application, which ias why I
say "most").

You should see more Path MTU discovery, allowing more common use of
TCP MSS of 1024, 4096, and (maybe some) 8192 (+40 or +56).  You'll
still see 40 byte ACKs in the reverse direction.  You'll still have
TCPs that us 552 as well as SLIP connections with 256 byte MTU (or
whatever the exact size is).

If you use RFC1323 (big windows) the ACK grow from 40 to 56 bytes with
the addition of a TCP option to the header.  (I think that's the size).

> So I had the following questions?
> 
> Can RFC1144 be used over ATM?  If the final destination
> lies on the other side of some router, will the negotiation just
> fail for the TCP connection and just not allow compression and not cause anyt
> hing
> to break?

The question is really how often the 40 byte TCP ACK can be compressed
into a single cell using AAL5 with the 8 byte LLC/SNAP header.  I
don't know this off the top of my head.  I think so, but I could be
wrong.  I think the compression can reduce an ACK to 30 bytes,
allowing 10 bytes for AAL5 framing, unless you did RFC1323, in which
case saving one cell in the reverse direction for each 9180 in the
forward direction is.

No chance of compressing the data packets, except perhaps some telnet
keystrokes.

> window size.  If RFC1106 size is used (this uses TCP options), can this be us
> ed
> along with header compression?

RFC1106 is superceeded by RFC1323 (if I remember that number
correctly).  I don't think TCP header compression works with options,
and I doubt it would compress the option, which would put you over the
size of a single cell.

> Thanks,
> Pat Medved
> 
> medved@npr.legent.com

Curtis