Subject: [NSIS] Reply to the IETF liaison on Flow State Aware/ Q.Flowstatesig

From: JOHN ADAMS <[email-masked]>
Date: Tue, 19 May 2009 06:36:47 +0000 (GMT)

Dear all,

This is a quick note. I am in the process of drafting a reply from the ITU relating to your incoming liaison.
I think this whole process of exchanging information through liaisons is fairly poor in terms of giving any real insights. Hence this note to you all today.

The issues that drive almost all the thinking on this new technology are about saving processing instructions so that FSA performs at scale. At the same time, there are simply some new things that can be achieved with signaling that would not happen without it.

On the issue of scale and the impact of standards on the number of instructions that have to be executed as flow packets (including signalling packets) arrive at a network node, there seems to be clear differences between in-band and path-coupled. With in-band, you already know what to do with respect to packet forwarding. With path-coupled there is some extra "thinking time" to be performed. I hope this helps your understanding of where we have been going.

I did analyse GIST and previously commented on RSVP and included both of these analyses in Q.Flowstatesig. Basically, in addition to the above comment on processing impact, FSA in-band is more like a "broadcast" signal, from one point towards many FSA nodes. As such, it needs to be recognised as a signal, not because of any destination address/ port number settings but through some other method of marking the packet.

For your information (and, as you will see in the reply liaison) we have dropped all text in Q.Flowstatesig asking for a hop-by-hop option method of marking IPv6 signalling packets. Instead we have opted for (a not entirely satisfactory) use of an EXP/LU DSCP. This whole subject is somewhat fraut with difficulties and standardisation timeliness. Unless the IETF and ITU can somehow find a way to fast-track new proposals, I guess the situation will continue to be difficult.

So, in summary, FSA signalling achieves the following
- it helps to minimise processing through the use of classification information contained in the signal
- processing is further minimised by carefully constructing the architecture and corresponding standards
- these two facets are intended to drive the whole technology towards very high link rates (10 gbit/s and higher) while processing every flow
- there are further new features that can be realised through signalling.

I will be bringing a longer version of this note as an IETF draft at the next meeting. I am looking for guidance on what, in the short-term, would be the best way of proceeding in the IETF (short-term being between now and the end of 2009 and with a focus on the work already completed at the ITU) and what would be better in the longer-term to involve everyone more in what seems to be an exciting new technology.

Regards,

John Adams

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 19 May 2009 13:29:49 +0200

Hi John,

I also include IESG in this reply as the liaison statement was sent by
the IESG and not the NSIS WG.

One important comment about how to go forward.

JOHN ADAMS skrev:
> I will be bringing a longer version of this note as an IETF draft at the
> next meeting. I am looking for guidance on what, in the short-term,
> would be the best way of proceeding in the IETF (short-term being
> between now and the end of 2009 and with a focus on the work already
> completed at the ITU) and what would be better in the longer-term to
> involve everyone more in what seems to be an exciting new technology.

John, Internet drafts are not submitted to a meeting. There are no need
for a meeting for us to discuss the draft on the mailing list and make
decisions. So please submit the draft as soon as possible. The sooner
you submit it the sooner we can discuss the content.

Best Regards

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: JOHN ADAMS <[email-masked]>
Date: Tue, 19 May 2009 12:20:48 +0000 (GMT)

Hi Magnus,

OK, thank you. I did not understand that procedural point.

I will prepare and submit as soon as possible.

Regards,

John

________________________________
From: Magnus Westerlund <[email-masked]>
To: JOHN ADAMS <[email-masked]>
Cc: Monique Morrow <[email-masked]>; Thomas Walsh <[email-masked]>; [email-masked]; "[email-masked]" <[email-masked]>; [email-masked]; Larry Roberts <[email-masked]>; IESG <[email-masked]>
Sent: Tuesday, 19 May, 2009 12:29:49 PM
Subject: Re: [NSIS] Reply to the IETF liaison on Flow State Aware/ Q.Flowstatesig

Hi John,

Best Regards

Magnus Westerlund

---

From: JOHN ADAMS <[email-masked]>
Date: Fri, 22 May 2009 12:04:43 +0000 (GMT)

Thank you Monique,

I am not sure about the need to attend the Stockholm meeting, if the purpose of my IETF draft is to
- further clarify what the "short-term" goals are, and have been, at the ITU-T
- indicate the areas of further study that would be welcome as a longer-term activity,jointly developed with the IETF and ITU-T

Briefly, I see the current position as this (although I will set this out in the IETF draft)
- the Q.Flowstatesig work has really focused on what may be termed a "within VLAN" solution.
   - meaning that signals, signal indications, Flow-based QoS, and associated monitoring functions all apply within the boundaries of specific VLAN(s) and not outside
   - that the capacity of VLAN links is being managed in a flow state aware way, and such management only extends to flows within such a set of VLAN links
   - that the use of an EXP/LU codepoint would be equally confined and declared as valid and active within such VLAN links (and only within those links).

Briefly again, this scenario could be used to manage content flows that are directly connected to such VLAN(s). For example, if a Service Provider, in conjunction with content partner(s) configures things in this way (that is, utilising a private network to link content sources and users).

What is NOT addressed anywhere in the ITU-T activity is the following
  - content sources outside the private network
  - possible extensions to the signalling (e.g. enabling commands like MONITOR (flow description) WHEN (when condition) UNTIL (until condition)) that could enrich the whole scope of FSA as it applies to the very large number of flows that it can simultaneously process.

Whether there is any point in raising these issues in Stockholm seems to me to be doubtful. My last experience of the IETF (and, for that matter, the one before) is that I get (if I am lucky) about 10 minutes of time to talk about anything. Perhaps the best vehicle is right here...the use of emails to discuss what you think is unclear and what you think could be done in the future.

By the way, I see the current ITU-T activity as an important first step, and it should be concluded quickly allowing us to build on that success and yet with some early opportunities to exploit the technology. 

Regards,

John

________________________________
From: Monique Morrow (mmorrow) <[email-masked]>
To: JOHN ADAMS <[email-masked]>; Thomas Walsh <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]; Tina TSOU <[email-masked]>; Larry Roberts <[email-masked]>
Sent: Friday, 22 May, 2009 11:55:23 AM
Subject: RE: Reply to the IETF liaison on Flow State Aware/ Q.Flowstatesig

RE: Reply to the IETF liaison on Flow State Aware/ Q.Flowstatesig 
John,

Thanks very much for your clarifications!

Several recommendations:

1. Write and submit the IETF draft [s]  as we discussed in San Francisco;

2. Next IETF meeting = July 26-31 [Stockholm, Sweden];

3. Will you be participating in the Stockholm meeting?  ITU-T session in Mar del Plata , 02-10 September 2009?

Look forward to speaking with you further.

Best regards,

Monique

-----Original Message-----
From: JOHN ADAMS [mailto:[email-masked]]
Sent: Mon 5/18/2009 11:36 PM
To: Monique Morrow (mmorrow); Thomas Walsh; [email-masked]; [email-masked]
Cc: [email-masked]; Tina TSOU; Larry Roberts
Subject: Reply to the IETF liaison on Flow State Aware/ Q.Flowstatesig

Dear all,

Regards,

John Adams

---

From: JOHN ADAMS <[email-masked]>
Date: Fri, 22 May 2009 13:06:56 +0000 (GMT)

Monique,

Sorry...one more question you asked..

Yes, I am intending to go to the next ITU-T SG11 meeting in September.

John

Several recommendations:

Best regards,

Monique

-----Original Message-----
From: JOHN ADAMS [mailto:[email-masked]]
Sent: Mon 5/18/2009 11:36 PM
To: Monique Morrow (mmorrow); Thomas Walsh; [email-masked]; [email-masked]
Cc: [email-masked]; Tina TSOU; Larry Roberts
Subject: Reply to the IETF liaison on Flow State Aware/ Q.Flowstatesig

Dear all,

Regards,

John Adams

---

From: "Monique Morrow (mmorrow)" <[email-masked]>
Date: Fri, 22 May 2009 12:55:23 +0200

John,

Several recommendations:

Best regards,

Monique

-----Original Message-----
From: JOHN ADAMS [mailto:[email-masked]]
Sent: Mon 5/18/2009 11:36 PM
To: Monique Morrow (mmorrow); Thomas Walsh; [email-masked]; [email-masked]
Cc: [email-masked]; Tina TSOU; Larry Roberts
Subject: Reply to the IETF liaison on Flow State Aware/ Q.Flowstatesig
 
Dear all,

Regards,

John Adams