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

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) <mmorrow at cisco.com>
To: JOHN ADAMS <j.l.adams1 at btinternet.com>; Thomas Walsh <twalsh at juniper.net>; lars.eggert at nokia.com; nsis at ietf.org
Cc: ghassem at rogers.com; Tina TSOU <tena at huawei.com>; Larry Roberts <larry at anagran.com>
Sent: Friday, 22 May, 2009 11:55:23 AM
Subject: 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:j.l.adams1 at btinternet.com]
Sent: Mon 5/18/2009 11:36 PM
To: Monique Morrow (mmorrow); Thomas Walsh; lars.eggert at nokia.com; nsis at ietf.org
Cc: ghassem at rogers.com; Tina TSOU; Larry Roberts
Subject: Reply to the IETF liaison on Flow State Aware/ Q.Flowstatesig

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