Subject: Re: [Sigtran] Repost - More M2PA 7 questions]

From: [email-masked]
Date: Fri, 7 Mar 2003 18:01:18 +0530

Brian,

> > > IF M2PA delays acking a data message, and then gets a Retrieve BSNT,
> > > there would be a problem with returning the number of the last message
> > > for which the ack was sent.
> > >
> > > For example, say messages up to number 35 have been received and
> > > delivered to MTP3 (where they may or may not be queued). But the acks
> > > have been sent out up to number 34. For some reason, M2PA is delaying
> > > the ack of number 35. Now if M2PA receives a Retrieve BSNT from MTP3. If
> > > M2PA returns the number of the last message acked (34), the other end
> > > would retransmit beginning with 35 and there could be a duplication. And
> > > duplication is very bad.
> >
> > Why not send return the FSN on the last message passed on to MTP3 instead ?
> > If we are explicitly acknowledging all received packets, half of the packets
> > sent on the network would be acknowledgements. Instead, we can wait for a
> > particular time duration to see if the acknowledgement can be piggybacked on
an
> > outgoing MSU. In case no MSU been sent by the Local M2PA before timeout, an
> > explicit ack should be sent to the Peer. Whenever a Retrieve BSNT from MTP3
is
> > received, the sequence number returned is the FSN value of the last Message
> > given to MTP3 and not the last Message acknowledged to Peer M2PA.
> > The advantage here is that in the scenario where both peers are exchanging
MSUs
> > at a high rate, no explicit acknowledgement would be sent on the network.
>
> Many MSUs are quite short comparted to the MTU of the connection.

  Rather than
> delay acknowledgements, I acknowledge immediately and let SCTP running
> modified Nagle/Minshall algorithm determine optimal bundling.  This addresses
> both bundling of acks and bundling of many MSUs into a single SCTP packet.
> M2PA cannot be expected to perform the bundling operation itself: bundling of
> packets is something for which SCTP (or other transport) is responsible.
> M2PA lacks access to the information necessary to make a good decision on
> bundling.

I agree that SCTP might bundle the M2PA Acknowledgements along with other MSUs.
But there is no need to always acknowledge in the first place. The BSN field in
the Data Message is meant for the purpose of piggybacking acknowledgments only.
Your proposal would render this field useless. In addition to this, the
cumulative ack feature is also not being utilized. Moreover the Ack might be a
small data packet itself, but given the fact that an ack would be sent back for
each and every received MSU can make it a big overhead at High Data Rates. The
argument that M2PA does not have enough information to piggyback is invalid
since the acks are at M2PA itself.

Hence sending ack for each received data message is grossly unoptimized and can
be easily optimized by delaying the acks and sending cumulative acks. The
technique is not new and is used in all transport layer protocols. If you
disagree, can you please state the advantages of sending a per message ack or a
scenario where delaying the ack by a suitable duration (say half of T7) may be
problematic.

> So, I agree with Tom as below: "the right way to deal with this is to send the
> ack right away."
>
> --brian
>
> >
> > >
> > > But IMHO the right way to deal with this is to send the ack right away.
> > >
> > > tomG.
> >

Regards
Anshoo.

DISCLAIMER: This message is proprietary to Hughes Software Systems
Limited (HSS) and is intended solely for the use of the individual
to whom it is addressed. It may contain  privileged or confidential
information  and should not be circulated or used for any purpose other
than for what it is intended. If you have received this message in error,
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. HSS accepts
no responsibility for loss or damage arising from the use of the information
transmitted by this email including damage from virus.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Mar 2003 07:43:59 -0700

anssharma,

[email-masked] wrote:                                                     (Fri, 07 Mar 2003 18:01:18)
> Your proposal would render this field useless.

No.  Just because you acknowledge messages immediately does not mean that you
have no MSUs in the TB to put them into (or piggyback them as you say).

> In addition to this, the cumulative ack feature is also not being utilized.

No.  A block of received messages can be acked immediately with a single ack.

> Moreover the Ack might be a small data packet itself, but given the fact
> that an ack would be sent back for each and every received MSU can make it a
> big overhead at High Data Rates.

Poor logic above led to wrong conclusion.

> The argument that M2PA does not have enough information to piggyback is
> invalid since the acks are at M2PA itself.

No. M2PA has no knowledge of congestion windows, bytes in flight, last acked
packet fill, and possibly path MTU, which are all necessary to make an
informed bundling decision.

> be easily optimized by delaying the acks and sending cumulative acks.

No.  All you will due is hurt Q.703's queuing model.

> The technique is not new and is used in all transport layer protocols.

Q.703 does not delay acks.

> If you disagree, can you please state the advantages of sending a per
> message ack or a scenario where delaying the ack by a suitable duration (say
> half of T7) may be problematic.

Your retransmission buffer fill will increase at the M2PA sender causing
false indications of transmit congestion and impairing network performance.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran