[OpenAFS-devel] datagrams really arent big enough?

[Chas Williams]

In message <200011100201.VAA26953@oo.yi.org>,Default writes:
>Have you run it with this configuration?
>server --- ethernet ---- router ---- ethernet ----- client 

we have this configuration already.  i have no clients with the 
modified mtu support on the other side (since everyone on the
other side of the router is ethernet, they will never use
rx packets bigger than ~1400.  

>that were only about four packets deep.  So if you tried to send a jumbogram >
>four frags, it would overflow the queue and one frag would get dropped.  Rx 
>will dutifully resend the jumbogram, IP will fragment, blast out the frags, 
>overrun the router's input queue, and so on -- forever.  Now, my information 

rx compares the interface mtus of the peer and server and chooses the smaller.
so any configuration of server -> router -> client will work fine.  the
problem will occur when you have server -> router -> router -> client
were the intermediate network between the routers has a smaller mtu
than the destination networks (a strange configuration since your routers
will have to fragment ip often and performance will be a dog, but i have
seen it)

>Hm.  Ok.  I'm not convinced by *should*, though.  Even with the improved 
>congestion control, once a RX packet's size is chosen, that packet's size
>can't be reduced on subsequent resends, if I'm reading this code correctly.

i believe it can.  check rx.c, somewhere around

    else if (nNacked && call->nNacks >= (u_short)rx_nackThreshold) {
        /* Three negative acks in a row trigger congestion recovery */
...
        call->ssthresh = MAX(4, MIN((int)call->cwind, (int)call->twind))>>1;
        call->cwind = MIN((int)(call->ssthresh + rx_nackThreshold),
                          rx_maxSendWindow);
        call->nDgramPackets = MAX(2, (int)call->nDgramPackets)>>1;

>Do you really want IP-over-ATM jumbograms of 16KB each?  That would equal one 
>9188 byte ip datagram and one ~7000 byte datagram for each packet.  It would 
>save some protocol processing overhead, as IP reassembly is cheaper than RX, 
>but as far as bandwidth efficiency goes, it would be better to stick with 
>RX_MAX_FRAGS equal to 6.

no i dont want jumbograms of 16k.  i want them to utilize my mtu size.
a jumbogram will never exceed max(peer_interface_mtu, client_interface_mtu)
settings RX_MAX_FRAGS to 11 WONT cause rx to send 16k packets unless your
interface mtu is big enough.