Subject: connection migration

From: Roni Even <[email-masked]>
Date: Wed, 15 Nov 2017 03:24:59 +0000

Hi,
When moving from cell to wifi the reason may be due to cost (money or quota). In this case the  user (client) may want to move to wifi even if it will mean dropping to TCP.

Roni

---

From: Mike Bishop <[email-masked]>
Date: Wed, 15 Nov 2017 03:35:27 +0000

That may well be the case, but it's not the QUIC stack's choice to make.  The application could choose to open a new connection, but that remains outside the scope of the transport and the mapping to it which we're defining.

For HTTP, this is fairly straightforward - it could stop issuing new flow control credit, let currently-in-transit data arrive and any losses recovered, and open a TCP connection to issue a range request starting at whatever data offset it hasn't seen.  But that's still a property of an HTTP management above the HTTP/QUIC mapping.

From: QUIC [mailto:[email-masked]] On Behalf Of Roni Even
Sent: Wednesday, November 15, 2017 11:25 AM
To: QUIC WG <[email-masked]>
Subject: connection migration

Hi,

Roni

---

From: Roni Even <[email-masked]>
Date: Wed, 15 Nov 2017 05:25:03 +0000

So what is the connection migration flow here. The quic stack in the cell network will try to migrate to wifi without application request and fail but will not fall back to TCP.
There may be multiple application running over quic? HTTP and peer to peer at the same time, so who will handle this case?

Roni

From: Mike Bishop [mailto:[email-masked]]
Sent: יום ד 15 נובמבר 2017 05:35
To: Roni Even; QUIC WG
Subject: RE: connection migration

That may well be the case, but it’s not the QUIC stack’s choice to make.  The application could choose to open a new connection, but that remains outside the scope of the transport and the mapping to it which we’re defining.

For HTTP, this is fairly straightforward – it could stop issuing new flow control credit, let currently-in-transit data arrive and any losses recovered, and open a TCP connection to issue a range request starting at whatever data offset it hasn’t seen.  But that’s still a property of an HTTP management above the HTTP/QUIC mapping.

From: QUIC [mailto:[email-masked]] On Behalf Of Roni Even
Sent: Wednesday, November 15, 2017 11:25 AM
To: QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: connection migration

Hi,

Roni

---

From: Mike Bishop <[email-masked]>
Date: Wed, 15 Nov 2017 06:22:50 +0000

Exactly the same way that TCP-to-TCP handoff between these interfaces works today, because (non-MP) TCP isn’t capable of changing to a different interface.  We’re trying to build a better answer, but you’re positing from the start that connection migration fails, so we’re now in “no worse” land.

The QUIC stack in the client device will see a new interface is available.  It attempts to switch to it, because of some local policy.  The transition fails for whatever reason, but the cellular connection is still active.  It is the application’s choice whether it wants to wind down and close that connection and start a new one using TCP, or keep using the old one if the interface remains available.  If there are multiple applications, each application makes that choice independently.

And if the first interface becomes unavailable for whatever reason, the choice is made for it, and the application will have to recover.

From: Roni Even [mailto:[email-masked]]
Sent: Wednesday, November 15, 2017 1:25 PM
To: Mike Bishop <[email-masked]>; QUIC WG <[email-masked]>
Subject: RE: connection migration

Roni

Hi,

Roni

---

From: Roni Even <[email-masked]>
Date: Wed, 15 Nov 2017 07:43:55 +0000

inline

From: Mike Bishop [mailto:[email-masked]]
Sent: יום ד 15 נובמבר 2017 08:23
To: Roni Even; QUIC WG
Subject: RE: connection migration

The QUIC stack in the client device will see a new interface is available.  It attempts to switch to it, because of some local policy.  The transition fails for whatever reason, but the cellular connection is still active.  It is the application’s choice
[Roni Even] which application if there is more than one? In the TCP case you stay in the cell. Here there are two options, stay on the cell with QUIC or move to wifi on TCP
whether it wants to wind down and close that connection and start a new one using TCP, or keep using the old one if the interface remains available.  If there are multiple applications, each application makes that choice independently.

From: Roni Even [mailto:[email-masked]]
Sent: Wednesday, November 15, 2017 1:25 PM
To: Mike Bishop <[email-masked]<mailto:[email-masked]>>; QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: connection migration

Roni

Hi,

Roni

---

From: Mike Bishop <[email-masked]>
Date: Wed, 15 Nov 2017 08:18:26 +0000

No; in the TCP case your transport doesn’t have any migration provision, so it’s up to the application whether it wants to wind down the existing connection and start a new one.  If migration fails with QUIC, the situation is exactly the same, and the application decides whether it wants to wind down the existing connection and start a new one.

If there’s more than one application, then the answer to “which application” is “each application” because each application owns its own connections.

From: Roni Even [mailto:[email-masked]]
Sent: Wednesday, November 15, 2017 3:44 PM
To: Mike Bishop <[email-masked]>; QUIC WG <[email-masked]>
Subject: RE: connection migration

inline

Roni

Hi,

Roni

---

From: Roni Even <[email-masked]>
Date: Wed, 15 Nov 2017 10:38:26 +0000

From: Mike Bishop [mailto:[email-masked]]
Sent: יום ד 15 נובמבר 2017 10:18
To: Roni Even; QUIC WG
Subject: RE: connection migration

If there’s more than one application, then the answer to “which application” is “each application” because each application owns its own connections.
[Roni Even] So we can end up with one application on the cell and the other on the wifi. Nice!!!

inline

Roni

Hi,

Roni

---

From: Mike Bishop <[email-masked]>
Date: Wed, 15 Nov 2017 11:02:32 +0000

Your sarcasm notwithstanding, I’ll emphasize that this is identical to TCP today.  Either the applications move, or they don’t.  If the device forcibly brings down the cellular interface’s data connection, the applications will have to move if they didn’t already move gracefully, which is independent of the transport’s properties.

From: Roni Even [mailto:[email-masked]]
Sent: Wednesday, November 15, 2017 6:38 PM
To: Mike Bishop <[email-masked]>; QUIC WG <[email-masked]>
Subject: RE: connection migration

inline

Roni

Hi,

Roni

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 15 Nov 2017 19:42:45 +0800

What Mike said. The scope of QUIC, by definition, is not larger than QUIC.

On Wed, Nov 15, 2017 at 7:02 PM, Mike Bishop <[email-masked]> wrote:

> Your sarcasm notwithstanding, I’ll emphasize that this is identical to TCP
> today.  Either the applications move, or they don’t.  If the device
> forcibly brings down the cellular interface’s data connection, the
> applications will have to move if they didn’t already move gracefully,
> which is independent of the transport’s properties.
>
>
>
> *From:* Roni Even [mailto:[email-masked]]
> *Sent:* Wednesday, November 15, 2017 6:38 PM
>
> *To:* Mike Bishop <[email-masked]>; QUIC WG <[email-masked]>
> *Subject:* RE: connection migration
>
>
>
>
>
>
>
> *From:* Mike Bishop [mailto:[email-masked] <[email-masked]>]
> *Sent:* יום ד 15 נובמבר 2017 10:18
> *To:* Roni Even; QUIC WG
> *Subject:* RE: connection migration
>
>
>
> No; in the TCP case your transport doesn’t have any migration provision,
> so it’s up to the application whether it wants to wind down the existing
> connection and start a new one.  If migration fails with QUIC, the
> situation is *exactly the same*, and the application decides whether it
> wants to wind down the existing connection and start a new one.
>
>
>
> If there’s more than one application, then the answer to “which
> application” is “each application” because each application owns its own
> connections.
>
> *[Roni Even] So we can end up with one application on the cell and the
> other on the wifi. Nice!!!*
>
>
>
> *From:* Roni Even [mailto:[email-masked] <[email-masked]>]
> *Sent:* Wednesday, November 15, 2017 3:44 PM
> *To:* Mike Bishop <[email-masked]>; QUIC WG <[email-masked]>
> *Subject:* RE: connection migration
>
>
>
> inline
>
>
>
> *From:* Mike Bishop [mailto:[email-masked] <[email-masked]>]
> *Sent:* יום ד 15 נובמבר 2017 08:23
> *To:* Roni Even; QUIC WG
> *Subject:* RE: connection migration
>
>
>
> Exactly the same way that TCP-to-TCP handoff between these interfaces
> works today, because (non-MP) TCP isn’t capable of changing to a different
> interface.  We’re trying to build a better answer, but you’re positing from
> the start that connection migration fails, so we’re now in “no worse” land.
>
>
>
> The QUIC stack in the client device will see a new interface is
> available.  It attempts to switch to it, because of some local policy.  The
> transition fails for whatever reason, but the cellular connection is still
> active.  It is the application’s choice
>
> *[Roni Even] which application if there is more than one? In the TCP case
> you stay in the cell. Here there are two options, stay on the cell with
> QUIC or move to wifi on TCP*
>
> whether it wants to wind down and close that connection and start a new
> one using TCP, or keep using the old one if the interface remains
> available.  If there are multiple applications, each application makes that
> choice independently.
>
>
>
> And if the first interface becomes unavailable for whatever reason, the
> choice is made for it, and the application will have to recover.
>
>
>
> *From:* Roni Even [mailto:[email-masked] <[email-masked]>]
> *Sent:* Wednesday, November 15, 2017 1:25 PM
> *To:* Mike Bishop <[email-masked]>; QUIC WG <[email-masked]>
> *Subject:* RE: connection migration
>
>
>
> So what is the connection migration flow here. The quic stack in the cell
> network will try to migrate to wifi without application request and fail
> but will not fall back to TCP.
>
> There may be multiple application running over quic? HTTP and peer to peer
> at the same time, so who will handle this case?
>
>
>
> Roni
>
>
>
> *From:* Mike Bishop [mailto:[email-masked] <[email-masked]>]
> *Sent:* יום ד 15 נובמבר 2017 05:35
> *To:* Roni Even; QUIC WG
> *Subject:* RE: connection migration
>
>
>
> That may well be the case, but it’s not the QUIC stack’s choice to make.
> The application could choose to open a new connection, but that remains
> outside the scope of the transport and the mapping to it which we’re
> defining.
>
>
>
> For HTTP, this is fairly straightforward – it could stop issuing new flow
> control credit, let currently-in-transit data arrive and any losses
> recovered, and open a TCP connection to issue a range request starting at
> whatever data offset it hasn’t seen.  But that’s still a property of an
> HTTP management above the HTTP/QUIC mapping.
>
>
>
> *From:* QUIC [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Roni Even
> *Sent:* Wednesday, November 15, 2017 11:25 AM
> *To:* QUIC WG <[email-masked]>
> *Subject:* connection migration
>
>
>
> Hi,
>
> When moving from cell to wifi the reason may be due to cost (money or
> quota). In this case the  user (client) may want to move to wifi even if it
> will mean dropping to TCP.
>
>
>
> Roni
>

---

From: Roni Even <[email-masked]>
Date: Wed, 15 Nov 2017 14:21:09 +0000

Hi,
I apologize if anyone felt that I was being sarcastic. To me it looks that there is some difference. My understanding that there is separation between the transport (QUIC) and the application (HTTP first and other later).
An application can see in the TCP case two options TCP on or TCP off. In QUIC it sees three options QUIC on, QUIC off (no connection), TCP. If one of the physical connection is closed there is no problem. I assumed that both physical connection are kept open (when I enter the house I connect to the AP but the 3G data channel is still open) but the application will try to send data on the wifi network and not on the cellular network since this is the policy, am I wrong?
Roni

From: Jana Iyengar [mailto:[email-masked]]
Sent: יום ד 15 נובמבר 2017 13:43
To: Mike Bishop
Cc: Roni Even; QUIC WG
Subject: Re: connection migration

On Wed, Nov 15, 2017 at 7:02 PM, Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:
Your sarcasm notwithstanding, I’ll emphasize that this is identical to TCP today.  Either the applications move, or they don’t.  If the device forcibly brings down the cellular interface’s data connection, the applications will have to move if they didn’t already move gracefully, which is independent of the transport’s properties.

From: Roni Even [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 15, 2017 6:38 PM

inline

Roni

Hi,

Roni

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 15 Nov 2017 15:43:30 +0000

Roni, if an application decides to switch from QUIC to TCP, there will be no connection migration.  The application will have to establish a new connection over TCP, likely, renegotiate crypto, and whatever QUIC streams were in progress will not just migrate and continue over TCP somehow.  Seamless connection migration between QUIC and TCP is certainly outside of the charter.

Apologies, if I misunderstood your intent, and you were talking about something other than how to migrate connections from QUIC to TCP.

  *   Igor

From: Roni Even [mailto:[email-masked]]
Sent: Wednesday, November 15, 2017 10:21 PM
To: Jana Iyengar <[email-masked]>; Mike Bishop <[email-masked]>
Cc: QUIC WG <[email-masked]>
Subject: RE: connection migration

Hi,

inline

Roni

Hi,

Roni

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 16 Nov 2017 08:24:30 +0800

Speaking as a curious individual, but not more.

On Wed, Nov 15, 2017 at 11:43 PM, Lubashev, Igor <[email-masked]>
wrote:

> Roni, if an application decides to switch from QUIC to TCP, there will be
> no connection migration.  The application will have to establish a new
> connection over TCP, likely, renegotiate crypto, and whatever QUIC streams
> were in progress will not just migrate and continue over TCP somehow.
> Seamless connection migration between QUIC and TCP is certainly outside of
> the charter.
>

It's probably good for me to say that as I understand it, migration, and
especially migration between transport protocols, is a session protocol
thing, and we really don't have a session protocol level in the Internet.
We rely on applications making decisions like this, rather than trying to
make decisions lower in the stack for the application.

When we have MP-TCP, as I understand it, TCP itself barely changes, so
that's less true, but it's still close.

I rely on working groups to make informed decisions about stuff like this,
but I wouldn't be surprised to see an MP-QUIC to be look sort of like
MP-TCP, when the working group starts making decisions about multi-path.

And I see migration as roughly multipath when an application uses one path
at a time, at the 10,000-meter level.

I could be wrong, but that's my guess.

IMO.

Spencer

Apologies, if I misunderstood your intent, and you were talking about
> something other than how to migrate connections from QUIC to TCP.
>
>
>
>    - Igor
>
>
>
>
>
> *Sent:* Wednesday, November 15, 2017 10:21 PM
> *To:* Jana Iyengar <[email-masked]>; Mike Bishop <[email-masked]>
> *Cc:* QUIC WG <[email-masked]>
> I apologize if anyone felt that I was being sarcastic. To me it looks that
> there is some difference. My understanding that there is separation between
> the transport (QUIC) and the application (HTTP first and other later).
>
> An application can see in the TCP case two options TCP on or TCP off. In
> QUIC it sees three options QUIC on, QUIC off (no connection), TCP. If one
> of the physical connection is closed there is no problem. I assumed that
> both physical connection are kept open (when I enter the house I connect to
> the AP but the 3G data channel is still open) but the application will try
> to send data on the wifi network and not on the cellular network since this
> is the policy, am I wrong?
>
> Roni
>
>
>
> *From:* Jana Iyengar [mailto:[email-masked] <[email-masked]>]
> *Sent:* יום ד 15 נובמבר 2017 13:43
> *To:* Mike Bishop
> *Cc:* Roni Even; QUIC WG
> *Subject:* Re: connection migration
>
>
>

---

From: Roni Even <[email-masked]>
Date: Thu, 16 Nov 2017 01:29:49 +0000

Hi,
Just for clarification,  I was wondering about migration from the cellular network to wifi, for example when walking from the street to my work office if my office FW will block QUIC how will it happen that multiple application running over QUIC on Cellular will all switch to TCP over WIFI and I will not see some of the applications  that will continue  running QUIC over Cellular while the rest will switch to TCP over WIFI.
Roni

From: Spencer Dawkins at IETF [mailto:[email-masked]]
Sent: יום ה 16 נובמבר 2017 02:25
To: Lubashev, Igor
Cc: Roni Even; Jana Iyengar; Mike Bishop; QUIC WG
Subject: Re: connection migration

On Wed, Nov 15, 2017 at 11:43 PM, Lubashev, Igor <[email-masked]<mailto:[email-masked]>> wrote:
Roni, if an application decides to switch from QUIC to TCP, there will be no connection migration.  The application will have to establish a new connection over TCP, likely, renegotiate crypto, and whatever QUIC streams were in progress will not just migrate and continue over TCP somehow.  Seamless connection migration between QUIC and TCP is certainly outside of the charter.

It's probably good for me to say that as I understand it, migration, and especially migration between transport protocols, is a session protocol thing, and we really don't have a session protocol level in the Internet. We rely on applications making decisions like this, rather than trying to make decisions lower in the stack for the application.

When we have MP-TCP, as I understand it, TCP itself barely changes, so that's less true, but it's still close.

I rely on working groups to make informed decisions about stuff like this, but I wouldn't be surprised to see an MP-QUIC to be look sort of like MP-TCP, when the working group starts making decisions about multi-path.

And I see migration as roughly multipath when an application uses one path at a time, at the 10,000-meter level.

IMO.

Spencer

  *   Igor

From: Roni Even [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 15, 2017 10:21 PM
To: Jana Iyengar <[email-masked]<mailto:[email-masked]>>; Mike Bishop <[email-masked]<mailto:[email-masked]>>
Cc: QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: connection migration

Hi,

inline

Roni

Hi,

Roni

---

From: Ian Swett <[email-masked]>
Date: Wed, 15 Nov 2017 20:36:59 -0500

This is a policy question more than a QUIC transport one, but a good
behavior in such a situation is to finish any in-flight communications(ie:
HTTP requests) and then send new traffic over Wifi.

Applications have to deal with this exact situation today, because they do
not have migration.

On Wed, Nov 15, 2017 at 8:29 PM, Roni Even <[email-masked]> wrote:

> Hi,
>
> Just for clarification,  I was wondering about migration from the cellular
> network to wifi, for example when walking from the street to my work office
> if my office FW will block QUIC how will it happen that multiple
> application running over QUIC on Cellular will all switch to TCP over WIFI
> and I will not see some of the applications  that will continue  running
> QUIC over Cellular while the rest will switch to TCP over WIFI.
>
> Roni
>
>
>
> *From:* Spencer Dawkins at IETF [mailto:[email-masked]]
> *Sent:* יום ה 16 נובמבר 2017 02:25
> *To:* Lubashev, Igor
> *Cc:* Roni Even; Jana Iyengar; Mike Bishop; QUIC WG

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 16 Nov 2017 09:38:16 +0800

Hi Roni,

that's for sure it an interesting use case but that is not the kind of migration that would actually influence the quic protocol design because effectively you’ll have to „simply“ open a NEW TCP connection. I guess this use case is rather in scope for the taps working group though.

Mirja

> Am 16.11.2017 um 09:29 schrieb Roni Even <[email-masked]>:
> 
> Hi,
> On Wed, Nov 15, 2017 at 11:43 PM, Lubashev, Igor <[email-masked]> wrote:
> 	• Igor

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 16 Nov 2017 10:45:54 +0800

Just to chime in,

On Thu, Nov 16, 2017 at 9:38 AM, Mirja Kühlewind <
[email-masked]> wrote:

> Hi Roni,
>
> that's for sure it an interesting use case but that is not the kind of
> migration that would actually influence the quic protocol design because
> effectively you’ll have to „simply“ open a NEW TCP connection. I guess this
> use case is rather in scope for the taps working group though.
>

As responsible AD for QUIC and TAPS, I agree with Mirja - interesting, but
more appropriate for TAPS.

And thanks for raising the question, Roni. I bet you're not the only person
thinking about this.

Spencer

> > Just for clarification,  I was wondering about migration from the
> cellular network to wifi, for example when walking from the street to my
> work office if my office FW will block QUIC how will it happen that
> multiple application running over QUIC on Cellular will all switch to TCP
> over WIFI and I will not see some of the applications  that will continue
> running QUIC over Cellular while the rest will switch to TCP over WIFI.
> > Roni
> >
> > Roni, if an application decides to switch from QUIC to TCP, there will
> be no connection migration.  The application will have to establish a new
> > I rely on working groups to make informed decisions about stuff like
> this, but I wouldn't be surprised to see an MP-QUIC to be look sort of like
> > And I see migration as roughly multipath when an application uses one
> path at a time, at the 10,000-meter level.
> >
> > I apologize if anyone felt that I was being sarcastic. To me it looks
> that there is some difference. My understanding that there is separation
> between the transport (QUIC) and the application (HTTP first and other
> later).
> > Your sarcasm notwithstanding, I’ll emphasize that this is identical to
> TCP today.  Either the applications move, or they don’t.  If the device
> situation is exactly the same, and the application decides whether it wants
> to wind down the existing connection and start a new one.
> >
> > [Roni Even] which application if there is more than one? In the TCP case
> QUIC or move to wifi on TCP
> > So what is the connection migration flow here. The quic stack in the
> cell network will try to migrate to wifi without application request and
> fail but will not fall back to TCP.
> > There may be multiple application running over quic? HTTP and peer to
> peer at the same time, so who will handle this case?
> >
> > Roni
> >
> > That may well be the case, but it’s not the QUIC stack’s choice to
> make.  The application could choose to open a new connection, but that
> remains outside the scope of the transport and the mapping to it which
> we’re defining.
> >
> > For HTTP, this is fairly straightforward – it could stop issuing new
> flow control credit, let currently-in-transit data arrive and any losses

---

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 16 Nov 2017 10:08:28 +0100

Spencer,
>     Roni, if an application decides to switch from QUIC to TCP, there
>     will be no connection migration.  The application will have to
>     establish a new connection over TCP, likely, renegotiate crypto, and
>     whatever QUIC streams were in progress will not just migrate and
>     continue over TCP somehow.  Seamless connection migration between
>     QUIC and TCP is certainly outside of the charter.
> 
> 
> thing, and we really don't have a session protocol level in the 
> Internet. We rely on applications making decisions like this, rather 
> than trying to make decisions lower in the stack for the application.
> 
> this, but I wouldn't be surprised to see an MP-QUIC to be look sort of 
> like MP-TCP, when the working group starts making decisions about 
> multi-path.
> 

I totally agree with you. Connection migration as it is currently 
discussed in the QUIC documents focuses on a narrow subset of the real 
problem. Connection migration works well in the case of NAT rebinding or 
when there is an explicit move from one IP address to another. In 
practice, there are many situations where a endhost cannot know whether 
it should use interface A or interface B. On wireless devices such as 
smartphones interfaces are not either up or down. When a host moves, 
when one of its interfaces moves from the up state to the down state, 
there is a period during which it is partially up (e.g. it works but 
with a very high latency due to link layer retransmissions or many 
losses). Experience with Multipath TCP has shown that to cope perfectly 
with those situations that are frequent with mobile hosts, it is 
important to be able to use the multipath capabilities to transmit over 
two paths simultaneously.

We have already proposed a Multipath extension to QUIC that allows to 
cope with those problems. In Prague, Multipath QUIC was on the agenda 
but there was no time to present it :

https://datatracker.ietf.org/doc/slides-99-quic-sessb-first-experiments-with-multipath-quic/

We have improved the design and documented it in an internet draft that 
was announced on the list :

https://datatracker.ietf.org/doc/draft-deconinck-multipath-quic/

This solution is implemented and works well. More details are available 
in a forthcoming paper :

Q. De Coninck, O. Bonaventure, Multipath QUIC: Design and Evaluation", 
to be presented the 13th International Conference on emerging Networking 
EXperiments and Technologies (CoNEXT 2017).

a preprint is available from http://multipath-quic.org
code will be available after the presentation from the same website

As the working group is focusing on basic v1 features we did not request 
specific slots to present this approach, but I would encourage the 
working group to think beyond connection migration and consider 
multipath capabilities as a much desireable objective.

Olivier

-- 

We will be moving on November 15th, 2017. Please update your records with 
our new address. 
1 Avenue Jean Monnet,
1348 Louvain-la-Neuve,
Belgium

-- 

------------------------------
DISCLAIMER.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. 
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and 
delete this e-mail from your system. If you are not the intended recipient 
you are notified that disclosing, copying, distributing or taking any 
action in reliance on the contents of this information is strictly 
prohibited.