Stitcher check available bandwidth before reservation

[ahelsing]

Where AMs support this, stitcher could check that an AM has sufficient bandwidth to meet the request, before submitting the request.

IG does not (quite) support this yet. I believe EG does not either. AL2S will not support this.

But if the AMs did support this, then just as stitcher checks for available VLAN tags, it could check for available bandwidth.

Imported from trac ticket #809, created by ahelsing on 05-11-2015 at 10:05, last modified: 05-11-2015 at 12:59

[ahelsing]

Ezra says that this is a common source of problems for him.

He also notes that if there were some way to say in a request RSpec what range of bandwidth would be acceptable, it would be nice if stitcher could auto adjust the BW to match what is possible within that range.

Trac comment by ahelsing on 05-11-2015 at 10:06

[ahelsing]

This isn't really likely even in the future, unless you are defining "available" to be the same as "maximum configurable." As you note, the GENI aggregates don't uniformly support this, which includes the need to track and enforce bandwidth, which is an end-to-end restriction. You can't just add up requests and have "available" equal what is actually unused on links, due to variations in traffic, other non-GENI traffic sharing interfaces, and lack of restrictions on a GENI traffic source exceeding its request in offerred traffic. You need tracking and enforcement at all aggregates too.

Trac comment by hpd on 05-11-2015 at 12:43

[ahelsing]

Right. This is not about 'will my actual BW measured be what I asked for?', but rather 'will the aggregate refuse my request because it thinks it doesn't have enough BW for me'.

Trac comment by ahelsing on 05-11-2015 at 12:59