I've set up an Exchange 2013 test infrastructure with two CAS front-end and two MBx back-end DAG servers.  The MBx servers are on dedicated hardware.  I've created mailboxes on both sides. To do some simple tests, I sent a message to myself that had 3 attachments that equaled about 5MB total.  I then kept forwarding that message to myself to add some content in the mailbox.  I wouldn't receive all of the messages but all of the sent messages are in the Sent Items folder.

My Sent Items folder has like 25 messages addressed to myself.  My Inbox only has about 5 messages in it.

I did a similar test sending to a mailbox on the other server.  I forwarded the same message 4 times but changed the subject line to '01,'02','03','04'.  The target mailbox received messages 01 and 04 but not the others.  The sent items show all four messages.

As an update, I just received all of the messages in both mailboxes about 10-15 minutes later.  I guess my question is if there is normally this type of throttling being applied.  I don't recall this being an issue in previous versions.

Have you looked at the queues?  Have you used message tracking?

That's right. Check message queues using Get-Queue and look at the message tracking  logs to find out what went wrong. It might also happen that the not received messages are still held in queue.

I looked at the queues at the time that this was happening and both queues (2 MBx servers) were empty.  I started to dig through the protocol logs when I saw the messages finally appeared.  I still asked the question because I was interested in the experience of other early adopters since I'm sure that they have done similar testing.

I can run the tests again and examine the protocol logs to see where the bottleneck is exactly.

The queue viewer should help you with that.

Thx Ed. That is what I used to examine both queues when I saw the issue. I'll retest and send results. Thx for helping so far with this, I appreciate it. :)

You're welcome.  Please feel free to mark any posts as answered or helpful as appropriate.

I took a look at the message headers for the delayed messages.   Interestingly, it shows that after delivering the email from server 1 to server 2, server 2 then waited almost 7 minutes before delivering to itself via Mailbox Transport.

Received: from NJEDSNEXMBX02.contoso.com (10.2.1.114) by NJEDSNEXMBX02.contoso.com (10.2.1.114) with Microsoft SMTP Server (TLS) id 15.0.712.22 via Mailbox Transport; Sun, 14 Jul 2013 18:51:27 -0400
Received: from NJEDSNEXMBX01.contoso.com (10.2.1.157) by NJEDSNEXMBX02.contoso.com (10.2.1.114) with Microsoft SMTP Server (TLS) id 15.0.712.22; Sun, 14 Jul 2013 18:44:39 -0400

Server1 never showed any messages in queue but then I took a look at Server2 queue (as Ed and Milinde recommended) and saw messages backed up for Shadow Redundancy.  There were also quite a few warnings in the application log that the periodic heartbeat to Server 1 failed.  I created two separate Inbound connectors between the two MBx servers and watched as the queue suddenly drained.

I re-ran the tests and all messages were delivered almost instantly regardless of how many that I sent.  I did some more research and see that this is the default behavior for E2K13 Shadow Redundancy which will first confirm that the message is available on both servers before delivering.  This is apparently what was causing the delay even if I was sending to myself.

http://technet.microsoft.com/en-us/library/dd351027%28v=exchg.150%29.aspx

Thx everyone for your help.  Now I just have to figure out why the default connectors were giving me an issue.  Anyway, at least this is one less issue that I will have when these go into production.  :)

The Shadow Redundancy queues being nonzero is normal.

Missed heartbeats are indicative of a network problem somewhere, but probably not related to the issue in this thread.

I added a manual entry to the hosts table of both of the DAG servers and the problem never resurfaced again.

Your symptoms sound like you have network issues.

That tells me that your DNS infrastructure might not be working properly or you have hosts registering NICs that shouldn't be registering.  Do these computers have multiple NICs with addresses that aren't routable?  If so, those shouldn't register in DNS.

You are probably right.  The MBx servers have 1 NIC card each and they are both on the same subnet.  DNS is very small and has shown no other resolution issues in the past couple of years.  I tried the local hosts idea because I had read about this helping with other weird connectivity issues in E2K13. 

NJEDSNEXMBX01

   Connection-specific DNS Suffix  . :
   IPv4 Address. . . . . . . . . . . : 10.2.1.157
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.2.1.1

NJEDSNEXMBX02

   Connection-specific DNS Suffix  . :
   IPv4 Address. . . . . . . . . . . : 10.2.1.114
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   IPv4 Address. . . . . . . . . . . : 10.2.1.116 <-DAG Address
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.2.1.1

get-databaseavailabilitygroupnetwork "NJEDSNEXDAG01\MapiDagNetwork" | fl

RunspaceId         : fe03668a-cc54-4907-a98e-03c7a0ff7813
Name               : MapiDagNetwork
Description        :
Subnets            : {{10.2.1.0/24,Up}}
Interfaces         : {{NJEDSNEXMBX01,Up,10.2.1.157}, {NJEDSNEXMBX02,Up,10.2.1.114}}
MapiAccessEnabled  : True
ReplicationEnabled : True
IgnoreNetwork      : False
Identity           : NJEDSNEXDAG01\MapiDagNetwork
IsValid            : True
ObjectState        : New

Upon further reflection, I've heard about similar issues in Exchange Server 2013, so what you've done is probably appropriate until Microsoft fixes whatever is causing that issue.