From: Ken Birman <kpb3@cornell.edu>
To: 'Dave Taht' <dave@taht.net>,
Matthias Tafelmeier <matthias.tafelmeier@gmx.net>
Cc: Bob Briscoe <ietf@bobbriscoe.net>,
"bloat@lists.bufferbloat.net" <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] DETNET
Date: Sun, 19 Nov 2017 20:24:59 -0000 [thread overview]
Message-ID: <BN6PR04MB11873DFED46A04E004B0ABEE9F2D0@BN6PR04MB1187.namprd04.prod.outlook.com> (raw)
In-Reply-To: <87a7zirue9.fsf@nemesis.taht.net>
The Microsoft SIGCOMM paper on deploying RDMA ran into issues with PPF packets (used by the RDMA technology to prevent buffer overruns): on Ethernet (RoCE) they employ an IP packet associated with Enterprise VLAN functionality, and Microsoft disables that feature on their Azure routers. They work around this by using a different feature of the router: modern datacenter routers support DiffServ, but few data centers use it. So they enabled Diffserv and split TCP/IP off as one traffic class, and treat RDMA as a second traffic class. They use DCQCN, which has its own RDMA flow control management, but as a fallback allow the hardware to still generate PPF packets, using the DiffServ header field to encode the needed PPF "pause sending" information. But to do this they were forced to change some firmware; no idea if this idea of their's will become widely adopted. Anyhow, with this scheme, the PPF packets protect against cases where DCQCN isn't fast enough to react. This was all with 100Gbps RDMA.
If I understood your prioritized queuing use case better I might be able to point to something squarely on topic. If this thread is about a specific scenario, maybe someone could point me to the OP where the scenario was first described?
next prev parent reply other threads:[~2017-11-19 20:24 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-04 13:45 Matthias Tafelmeier
[not found] ` <87shdr0vt6.fsf@nemesis.taht.net>
2017-11-12 14:58 ` Matthias Tafelmeier
2017-11-12 19:58 ` Bob Briscoe
2017-11-13 17:56 ` Matthias Tafelmeier
2017-11-15 19:31 ` Dave Taht
2017-11-15 19:45 ` Ken Birman
2017-11-15 20:09 ` Matthias Tafelmeier
2017-11-15 20:16 ` Dave Taht
2017-11-15 21:01 ` Ken Birman
2017-11-18 15:56 ` Matthias Tafelmeier
2017-12-11 20:32 ` Toke Høiland-Jørgensen
2017-12-11 20:43 ` Ken Birman
2017-11-18 15:38 ` Matthias Tafelmeier
2017-11-18 15:45 ` Ken Birman
2017-11-19 18:33 ` Dave Taht
2017-11-19 20:24 ` Ken Birman [this message]
2017-11-20 17:56 ` [Bloat] *** GMX Spamverdacht *** DETNET Matthias Tafelmeier
2017-11-20 19:04 ` Ken Birman
2017-12-17 12:46 ` Matthias Tafelmeier
2017-12-17 16:06 ` Ken Birman
2017-11-18 17:55 ` [Bloat] DETNET Matthias Tafelmeier
2017-11-18 19:43 ` Ken Birman
2017-11-18 19:47 ` Ken Birman
2017-11-20 18:32 ` Matthias Tafelmeier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BN6PR04MB11873DFED46A04E004B0ABEE9F2D0@BN6PR04MB1187.namprd04.prod.outlook.com \
--to=kpb3@cornell.edu \
--cc=bloat@lists.bufferbloat.net \
--cc=dave@taht.net \
--cc=ietf@bobbriscoe.net \
--cc=matthias.tafelmeier@gmx.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox