Subject: Re: [Tsvwg] New I-D on cross-layer indications for transport protocols

From: Bob Briscoe <[email-masked]>
Date: Wed, 08 Nov 2006 02:15:41 +0000

Pasi,

I found this useful, learning things I didn't know and organising my 
thoughts a bit.

Suggestions for improving the taxonomy:
--------------------------------------
Define in-band, out of band etc. I had to reverse engineering definitions 
for these from the examples, as I've heard these terms used for other 
meanings than yours (I'm happy with your use of the terms, it's just that 
other people - perhaps sloppily - define them differently).

Suggest including a further distinction within out of band between:
- on path and
- off path.
Ie where the signal passes thru the same routers as the data, or not.

Another obvious distinction would be where the out of band signalling is in 
the reverse direction to the data vs same direction.

Other comments
--------------
I found it unhelpful talking about ICMP as one glob. Different ICMP message 
types would appear at different places in the taxonomy, so they need 
further breakdown to be instructive.

I'm not sure of my facts, but I think the IPSec SPI was included in the 
first 8B of the ESP or AH headers so that it would be copied into ICMP 
messages for return to the sending IP, so IP would know which socket to 
pass the ICMP message to.

One or two more detailed points I'll post later - must rush.

Bob

At 09:55 16/10/2006, Pasi Sarolahti wrote:
>[This mail is also sent to [email-masked] mailing list]
>
>Folks,
>
>Sally Floyd and I submitted a new Internet-Draft titled "Cross-layer
>Indications for Transport Protocols". The draft aims to summarize the
>past work done on this area and describe the known challenges with
>different types of cross-layer notification schemes. This problem area
>was discussed in the ad-hoc TERNLI meeting at the last IETF, and I think
>feelings there were generally positive about having a draft that would
>give an overview of the problem space.
>
>The -00 version is yet missing some bits, but we'd like to get input
>already at an early stage: does the current approach seem viable? What
>is missing (quite a bit, I guess)? Is the past work described correctly?
>Do you think this kind of document would be useful?
>
>Before it gets to the repository, the draft is available at
>http://www.icir.org/floyd/papers/draft-sarolahti-tsvwg-crosslayer-00.txt
>and
>http://www.icir.org/floyd/papers/draft-sarolahti-tsvwg-crosslayer-00.ps
>
>Thanks,
>- Pasi
>

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

---

From: "Dickinson, Fil" <[email-masked]>
Date: Fri, 10 Nov 2006 06:11:46 +1100

Pasi,
I think your approach is good and the document is very useful. I enjoyed
reading it and think it is very easy to understand. I look forward to
seeing the version with the section 6.6 under way, as this is an area
that would benefit greatly from an informative explanation.
Thank you.

-----Original Message-----
From: Pasi Sarolahti [mailto:[email-masked]] 
Sent: Monday, 16 October 2006 7:55 PM
To: [email-masked]
Cc: Sally Floyd
Subject: [Tsvwg] New I-D on cross-layer indications for transport
protocols

Folks,

Thanks,
- Pasi

---

From: Scott W Brim <[email-masked]>
Date: Sat, 11 Nov 2006 12:13:17 -0800

> Suggestions for improving the taxonomy:

First in response to this ... I think the use of in-band and
out-of-band is correct.  What I've seen overall:

  - In-band: being carried in the packets (or circuits).

  - Out-of-band: being carried in different packets.

  - On-path: On-path in a connectionless network means it is using the
    same path in the underlying network.  (On-path for a connection
    means it is using the same connection path.)  

  - Off-path: Off-path in a connectionless network means it is using a
    separate path in the underlying network.  (Off-path for a
    connection means it is using a separate connection path.)  

  - Path-coupled: On-path.

  - Path-decoupled: Possibly but not necessarily off-path.  Cannot be
    assumed to be on-path.

The use of "underlying network" in there brings up the issue of what
scope the draft should cover.  This is a good draft as far as it goes.
you want it to go further?  

So far you are assuming a single "seven layer" (X.200) stack, but in
the real world we often have multiple partial X.200 stacks on top of
each other (known as "layer networks").  For example IP on top of
multi-segment MPLS LSPs on top of Layer 1 VPNs, etc.  Each has some of
the same X.200 "layers".  You get "cross-layer" interactions here too.
For example, activity in an application can request resource changes
in an underlying [G]MPLS-based VPN configuration.  So far, your scope
is interactions between endpoints and "the network", meaning the
immediate IP-oriented layer network.  Do you want to limit your scope
to this, or do you want to include interactions between layer
networks?

Also, you limit the scope to situations where an end system is
involved.  Is this intentional?  You can get vertical interactions
between control functions within and between layer networks in the
middle of the network, not just at the edges.  You present IP tunnels
as a problem, but they can also be part of the solution.  When you
talk about end systems, is that from the IP point of view?  For the
purposes of this draft, are SIP proxies end-hosts?  

Whatever the scope is, it should be explicit.

Onward, other comments ...

In the Abstract and Introduction, you talk about the "problem", but
not really what it is.  

  - "We analyze the different mechanisms in a framework based on what
    level of network support they require, and discuss the benefits
    and disadvantages different approaches have."

    "level of network support" isn't explained.

  - "The objective is to get a common understanding of the problem
    space ...,"
		          
    What problem space?  Describe it ...  
				    
  - "with pointers to past discussions on this topic, and to describe
    the possible next steps towards removing barriers from explicit
    cross-layer communication in future protocols.

    ... and why this is a problem.  Why would you want to remove these
    barriers?  

Some more possible benefits, depending on scope ...

  - Grids may request resource and even topology changes based on the
    changing needs of their processes.  Same for so-called
    application-layer multicast.
    
  - Leaking routing changes between layer networks, so that upper ones
    can adapt to changes in lower ones.  Is that in scope?

  - Midcom and its children (still growing up).  

Possible problems (depending on scope) ...

  - Oscillations in behavior can result from similar time constants.  

  - Some indications must only flow up, never down.  For example link
    up/down.

Thanks ... Scott

---

From: Pasi Sarolahti <[email-masked]>
Date: Tue, 14 Nov 2006 16:30:21 -0500

> other people - perhaps sloppily - define them differently).

Ok, will do. The taxonomy seems to need some work yet. It would probably
be better to discuss different properties separately (in-band/out-of-
band, level of router involvment, on-path/off-path), rather than doing
it in one flat list as we have now.

Btw, do you have some text in mind for the in-band/out-of-band
definition?

> Ie where the signal passes thru the same routers as the data, or not.

Thanks, good point, this distinction indeed deserves to be mentioned.
Although as was pointed out in another mail, it would be useful to
define and limit the scope of the draft. Maybe "on-path" could be a
helpful limitation, because most of the earlier proposed schemes are
somehow related to the properties of the transport connection path
(available transmission rate, Path MTU, etc.).

> the reverse direction to the data vs same direction.

Ah, right. Will do.

> Other comments

Ok.

> pass the ICMP message to.

Ok.

Many thanks for the comments.

- Pasi

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 15 Nov 2006 16:24:30 +0000

Pasi,

At 21:30 14/11/2006, Pasi Sarolahti wrote:
> > Define in-band, out of band etc.
>

in-band: within the data packet stream
out-of-band: in separate (control) packets

>(available transmission rate, Path MTU, etc.).

I did think that most of the draft was within the on-path scope and this 
was a good limitation. Except you also include reverse messages (against 
the direction of data flow), which are clearly not on-path! Perhaps a good 
limitation would be touching the path at least once and at least one endpoint.

> > the reverse direction to the data vs same direction.

Cheers

Bob

____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not 
necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 22 Nov 2006 11:31:29 -0600

Pasi,

I think this is a very meaningful work. To me the repeated yet fruitless 
effort in this space within IETF in the past just shows two things - a 
undying desire for a solution and the challenge to get a right one.

Maybe another data point in this space: there is an ongoing work in IEEE 
802.21 (Media Independent Handover) that is trying to standardize a set 
of link indications (e.g., link-up, link-going-down, 
link-handover-imminent, etc.) across various IEEE and cellular link 
interfaces (802.11, 802.16, 802.3, UMTS, HRPD, etc.). What probably 
makes that work even more relevant to your this investigation is that 
802.21 also is defining ways for transporting these link indications 
over IP. As a matter of fact, several I-Ds are available and being 
considered in mipshop for this purpose.

I'd appreciate if you could share your view and comment on 802.21.

regards,
-Qiaobing

---

From: Pasi Sarolahti <[email-masked]>
Date: Thu, 23 Nov 2006 23:32:19 +0200

> undying desire for a solution and the challenge to get a right one.

Thanks!

> considered in mipshop for this purpose.

Yep, 802.21 and the related mipshop work should be referenced. To
clarify -- these are to optimize layer 3 mobility using layer 2
indications, aren't they? Not so much about optimizing transport
protocols, although the same triggers delivered further up to transport
could possibly be useful, too.

I'll check out the current MIPSHOP drafts. I've understood that GIST is
one protocol considered for MIH transport, and that should be relevant
also here.

- Pasi