Reviewable status: 0 of 3 files reviewed, 9 unresolved discussions (waiting on @juagargi)

a discussion (no related file):

Requests and responses for segment and e2e reservations. All of these messages will travel as payload of a hop by hop colibri extension.

Wait, that is not true, right?
The payloads are the l4 payloads in the packet. the HBH extension header does not contain this payload.

proto/colibri.capnp, line 17 at r1 (raw file):

}

struct ReservationIndex {

Does this need to be its own struct?

proto/colibri.capnp, line 51 at r1 (raw file):

# Travel inside a hop by hop colibri extension.
struct SegmentSetupResData {
    setup @0 :SegmentSetupReqData; # the response is sent along the path in the opposite direction as the request

This should be a union, no?

proto/colibri.capnp, line 57 at r1 (raw file):

# Request to renew an existing segment reservation.
# Travel inside a hop by hop colibri extension (SegmentReservationID and index available externally).
struct SegmentRenewalData {

A renewal request should have the same format as the setup, no?

proto/colibri.capnp, line 69 at r1 (raw file):

# Telescoped segment reservation newewal. They travel inside a hop by hop extension.
struct SegmentTelesRenewalData {}   # empty (SegmentReservationID and index from hop by hop extension)

I don't follow the reasoning here, in the renewal there will be a new index.
Every AS needs to agree on a bandwidth again, no?

How can this be empty?

proto/colibri.capnp, line 72 at r1 (raw file):

# tear down a segment reservation.
struct SegmentTeardownData {}   # empty (SegmentReservationID and index from hop by hop extension)

There is no way of indicating what caused the teardown to fail.

proto/colibri.capnp, line 76 at r1 (raw file):

# Segment reservation index confirmation request.
# They travel inside hop by hop colibri extension.
struct SegmentIndexConfirmationData {

The point of index confirmation is to confirm the index, without actually using it.
As soon as an index is used, it is no longer permitted to use previous indexes.

Thus, you cannot simply use the index from the HBH extension/

proto/colibri.capnp, line 81 at r1 (raw file):

# removes a pending segment reservation.
struct SegmentCleanupData {}    # empty (SegmentReservationID and index from hop by hop extension)

How does that work? There is no reservation yet when we do cleanup.

proto/colibri.capnp, line 84 at r1 (raw file):

# Setup an E2E reservation. Sent in a hop by hop colibri extension through a stitched segment reservation.
struct E2ESetupReqData {

The request can already fail, there is no way to indicate the error.

Reviewable status: 0 of 3 files reviewed, 10 unresolved discussions (waiting on @oncilla)

a discussion (no related file):

Yes, poor wording. Should have been:
All of these messages will travel as payload of a packet that will also contain a hop by hop colibri extension.
Editing description in PR.

proto/colibri.capnp, line 17 at r1 (raw file):

Done.

proto/colibri.capnp, line 41 at r1 (raw file):

    minBW @0 :UInt8;
    maxBW @1 :UInt8;
    accBW @2 :UInt8;

I've removed the accBW as it can be derived directly from the allocationTrail (accBW = min(maxBW forall maxBW in allocationTrail)

proto/colibri.capnp, line 51 at r1 (raw file):

Yes. Each AS can keep a copy of the request, and then when the response comes back, recover the copy from the store. The token would be enough if success, otherwise the previous setup.

proto/colibri.capnp, line 57 at r1 (raw file):

I've added the allocation trail and the min and max BW, the only fields that can change from the original setup.

proto/colibri.capnp, line 69 at r1 (raw file):

Done.

proto/colibri.capnp, line 72 at r1 (raw file):

Done.

proto/colibri.capnp, line 76 at r1 (raw file):

Added the index value.

proto/colibri.capnp, line 81 at r1 (raw file):

Added an ID and index.

proto/colibri.capnp, line 84 at r1 (raw file):

My understanding is that when an e2e request is faied, a failed response is sent in the opposite direction.
The response to the request, E2ESetupResData, has an errorCode field.

Reviewed 1 of 3 files at r1, 2 of 2 files at r2.
Reviewable status: all files reviewed, 4 unresolved discussions (waiting on @juagargi and @oncilla)

proto/colibri.capnp, line 41 at r1 (raw file):

alright.

proto/colibri.capnp, line 57 at r1 (raw file):

surely the index can also change.
Also, what about the split class?

Did the restrictions on the renewal change? If so, can you point me to the new spec.

proto/colibri.capnp, line 84 at r1 (raw file):

The request still travels the full path to collect what the remaining ASes would have been willing to permit.

Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @oncilla)

proto/colibri.capnp, line 57 at r1 (raw file):

I only have your thesis as a reference. I understood that during the renewal the min and max BW could be adjusted (and I understood that nothing more), 3.3.2 pp15.
Also, I don't think I understand how the new index is requested.

proto/colibri.capnp, line 84 at r1 (raw file):

I didn't know that. In the thesis, for the ephemeral setup, it specifies only the reservation ID and token, e.g. figure 4.10.
Do you want to extend this with an allocation sequence and error code?

Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @juagargi)

proto/colibri.capnp, line 57 at r1 (raw file):
a reservation is identified by its ID plus its index.

So an AS creates an initional reservation. This will be ID+0. When it wants to renew the reservation. It will try to get reservation ID+1. Then ID+2.. and so on.

From that section:

A renewal request renews a given steady reservation. Renewing a reservation
is done by adding a new index to the given reservation.

Maybe Section 3.2.7 clears things up a bit.

proto/colibri.capnp, line 84 at r1 (raw file):
The failed request can be seen in 4.11, not 4.10.

I admit, this is not formulated well in the thesis:

3.3.5

When a request is failed, the contents are transformed to accumulate the bandwidth
classes that the ASes would have been willing to grant. No reservation is created
and no bandwidth is allocated.

Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @oncilla)

proto/colibri.capnp, line 57 at r1 (raw file):

Thanks for all the clarifications. At the end the renewal looks the same as a setup, I've replaced the request and response of the renewals with the same structures used in the setups.

proto/colibri.capnp, line 84 at r1 (raw file):

Done.
I've now also replaced the e2e renewal with the setup struct, PTAL.

Reviewed 2 of 2 files at r3.
Reviewable status: complete! all files reviewed, all discussions resolved

Reviewable status: complete! all files reviewed, all discussions resolved