Subject: Re: [PANRG] [tsvwg] Fwd: New Version Notification for draft-herbert-fast-00.txt

From: John Kaippallimalil <[email-masked]>
Date: Tue, 13 Mar 2018 22:30:26 +0000

Tom,
I read this draft and like the overall approach (my point of view is the mobile network).

A few of questions:
1.  I suppose that these tickets do not have to be sent in every packet.
Are they sent statistically, or just in a few packets after a change or some event.

2. my understanding is that routers on path would try to inspect all tickets to determine which ones are for that service provider.  
Would it make sense to explicitly convey that in Option Format/Ticket (4.1) - like a realm / domain name of the service provider.
Or can this be derived from some combination of the option type (hop-by-hop/ destination) and "Type" fields.

3. After an IP address change (mobility event), TCP ramp up affects the flow rate.
Assuming use cases like V2X (and ILA) where mobility events are frequent - 
Could a packet with ticket conveying established flow + QoS info be used to safely continue/not have to ramp up every time there is a change of IP attachment point.

Thanks,
John

-----Original Message-----
From: tsvwg [mailto:[email-masked]] On Behalf Of Tom Herbert
Sent: Thursday, January 11, 2018 3:09 PM
To: [email-masked]; [email-masked]
Subject: [tsvwg] Fwd: New Version Notification for draft-herbert-fast-00.txt

Hello,

I posted this draft on "Firewall and Service Tickets" draft. This is a proposed method to allow hosts and applications to signal the network to make requests for services to be applied to flows. The concept of a rich and extensible  protocol to signal the network was inspired by the SPUD/PLUS work, however this proposal uses IPv6 extension headers instead of UDP shim headers and tries to strictly control exposure application characteristics or content to untrusted parties.

I've cross posted this ti tsvwg an panrg as I'm not yet sure where this work would belong.

Any feedback is very welcome!

Thanks,
Tom

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Thu, Jan 11, 2018 at 11:46 AM
Subject: New Version Notification for draft-herbert-fast-00.txt
To: Tom Herbert <[email-masked]>

A new version of I-D, draft-herbert-fast-00.txt has been successfully submitted by Tom Herbert and posted to the IETF repository.

Name:           draft-herbert-fast
Revision:       00
Title:          Firewall and Service Tickets
Document date:  2018-01-11
Group:          Individual Submission
Pages:          21
URL:            https://www.ietf.org/internet-drafts/draft-herbert-fast-00.txt
Status:         https://datatracker.ietf.org/doc/draft-herbert-fast/
Htmlized:       https://tools.ietf.org/html/draft-herbert-fast-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-herbert-fast-00

Abstract:
   This document describes the Firewalls and Service Tickets protocol. A
   ticket is data that accompanies a packet and indicates a granted
   right to traverse a network or a request for network service to be
   applied. Applications request tickets from a local agent in the
   network and attach issued tickets to packets. Firewall tickets are
   issued to grant packets the right to traverse a network; service
   tickets indicate the desired service to be applied to a packets. A
   single ticket may provide both firewall and service ticket
   information. Tickets are sent in either IPv6 Destination options or
   Hop-by-Hop options.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Tom Herbert <[email-masked]>
Date: Tue, 13 Mar 2018 16:05:02 -0700

> I read this draft and like the overall approach (my point of view is the mobile network).
Hi John,

Thanks for your questions!

> Are they sent statistically, or just in a few packets after a change or some event.
In every packet. This way the network does not need to create flow
state, it just reads and processes the tickets as they presented.

> Or can this be derived from some combination of the option type (hop-by-hop/ destination) and "Type" fields.
I thought about adding an identifier to tickets (like AS number), but
I think that is probably not needed. Tickets are probably only
applicable in edge provider networks, not in core Internet. So there
might be up to two tickets in a packet, one that is relevant to the
source provider and one that is relevant to the remote provider (a
reflected ticket). Tickets also need to be verified probably through
decryption so that would also be able to detect whether it ticket is
valid in the network processing it. It will be an interesting
challenge to see how small the tickets can be made without losing
security or expressiveness.

> Could a packet with ticket conveying established flow + QoS info be used to safely continue/not have to ramp up every time there is a change of IP attachment point.

Yes, they should be. In the case of ILA for instance, the ticket is
created based on identifier addresses which don't change across a
mobile event.

Tom

---

From: John Kaippallimalil <[email-masked]>
Date: Wed, 14 Mar 2018 18:03:06 +0000

Hi, Tom,
Thanks for the answers - some follow up qns & comments below.

>        In every packet. This way the network does not need to create flow state, it just reads and processes the tickets as they presented.
For each packet the router would need to decrypt and then apply that policy for admission control/shaping/scheduling.
The cost of decrypting per packet vs. memory lookup of state info seem to have different trade-offs.
For infrequent packets / datagrams - carrying state in each ticket would be efficient, but may not be the same for a high bandwidth flow.
Also routers (like mobile network UPFs) hold state anyway for implementing forwarding policy based on subscription (bandwidth, delay, jitter classes based on QCI).

My intention with FAST ticket was to convey relative handling preferences for a connection session (PDU) that has multiple flows (connection session has policy, but not each flow) 
As documented in the draft, the current mechanism of using DPI for this would not work if the packets are encrypted.

>        Yes, they should be. In the case of ILA for instance, the ticket is created based on identifier addresses which don't change across a mobile event.
The identifier address don't change, but the underlying resource /links and routers change - and with slow/start that would be taken into consideration.
Is the point that the ticket would be valid for that identifier. And when presented to the new router, it would grant resources accordingly and thus slow start is not needed.

But I'm not sure its that simple - the scheduler would want to maximize utilization while being fair - so if new flows come in suddenly during high utilization, it would need more than this I think?

BR,
John 

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Tuesday, March 13, 2018 6:05 PM
To: John Kaippallimalil <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [tsvwg] Fwd: New Version Notification for draft-herbert-fast-00.txt

Hi John,

> Are they sent statistically, or just in a few packets after a change or some event.
In every packet. This way the network does not need to create flow state, it just reads and processes the tickets as they presented.

> Or can this be derived from some combination of the option type (hop-by-hop/ destination) and "Type" fields.
I thought about adding an identifier to tickets (like AS number), but I think that is probably not needed. Tickets are probably only applicable in edge provider networks, not in core Internet. So there might be up to two tickets in a packet, one that is relevant to the source provider and one that is relevant to the remote provider (a reflected ticket). Tickets also need to be verified probably through decryption so that would also be able to detect whether it ticket is valid in the network processing it. It will be an interesting challenge to see how small the tickets can be made without losing security or expressiveness.

> Assuming use cases like V2X (and ILA) where mobility events are 
> frequent - Could a packet with ticket conveying established flow + QoS info be used to safely continue/not have to ramp up every time there is a change of IP attachment point.

Yes, they should be. In the case of ILA for instance, the ticket is created based on identifier addresses which don't change across a mobile event.

Tom

---

From: Tom Herbert <[email-masked]>
Date: Wed, 14 Mar 2018 11:59:39 -0700

> As documented in the draft, the current mechanism of using DPI for this would not work if the packets are encrypted.
SInce tickets are not transferable the identity of the bearer needs to
be checked. Minimally this would be the source address in the network
that ticket was created. It should also include the remote address so
that remote peers can't easily reuse tickets to other destination.
Anything more specific would require DPI.

> Is the point that the ticket would be valid for that identifier. And when presented to the new router, it would grant resources accordingly and thus slow start is not needed.

No, it's independent of slow start. I don't foresee tickets being very
dynamic, altough the underlying routing could be.

> But I'm not sure its that simple - the scheduler would want to maximize utilization while being fair - so if new flows come in suddenly during high utilization, it would need more than this I think?
I'm not sure. I think congestion control is still valid.

---

From: John Kaippallimalil <[email-masked]>
Date: Wed, 21 Mar 2018 10:21:57 +0000

Tom,

>   No, it's independent of slow start. I don't foresee tickets being very dynamic, altough the underlying routing could be.

Re: slow start when the identifier does not change (as in ILA) but the underlying resource/links change as a result of mobility
Checking with transport area experts - it looks like right way is to go to slow start.

Transport area experts may be able to shed more light on this.

John

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Wednesday, March 14, 2018 2:00 PM
To: John Kaippallimalil <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [tsvwg] Fwd: New Version Notification for draft-herbert-fast-00.txt

On Wed, Mar 14, 2018 at 11:03 AM, John Kaippallimalil <[email-masked]> wrote:
> My intention with FAST ticket was to convey relative handling 
> preferences for a connection session (PDU) that has multiple flows (connection session has policy, but not each flow) As documented in the draft, the current mechanism of using DPI for this would not work if the packets are encrypted.
>
SInce tickets are not transferable the identity of the bearer needs to be checked. Minimally this would be the source address in the network that ticket was created. It should also include the remote address so that remote peers can't easily reuse tickets to other destination.
Anything more specific would require DPI.

> Is the point that the ticket would be valid for that identifier. And when presented to the new router, it would grant resources accordingly and thus slow start is not needed.

No, it's independent of slow start. I don't foresee tickets being very dynamic, altough the underlying routing could be.