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

From: Pasi Sarolahti <[email-masked]>
Date: Mon, 16 Oct 2006 12:55:07 +0300

[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

---

From: <[email-masked]>
Date: Mon, 16 Oct 2006 10:17:34 -0700 (PDT)

Just some thoughts from a relative neophyte:
 
I like the basic taxonomy in section 2. You might consider presenting it in two stages (in-band vs. out-of-band, router support required vs. router support not required), and a table MIGHT be useful here. One of the first questions I found myself asking was to what degree are these characterisics orthogonal? A minor suggestion: When you write "The disadvantage of in-band signaling is that if some routers ...drop a packet...the accompanying data also gets lost..." (ellipses due to my laziness only!) I assume that the issue is that unkown options could cause routers to discard data when the data could otherwise have been successfully transmitted (though the signaling would be lost). Am I wrong here? Is it fair to say that in-band signaling involving only IP requires router involvement (short of dropping packets to signal congestion), and mechanisms relying on he transport protocol (TCP, UDP) do not? Why not make this explicit?
 
I wonder if it might be useful to trry to establish a cross-reference between the issues in section 6 and the mechanisms in section 4. for example, the issue in 6.3 seem to be an issue with in-band signaling.
 
I'm not sure if this is even something that can/should be addressed in your I-D, but I believe the IETF is standardizing 802.1au which is an ECN like mechanism for signaling congestion in layer 2 switches. Wait...I see it at the end of 6.6 (layer 2 queues and operation logic).
 
===
Gregory Woodhouse 
 
"Mathematics is the science of patterns."
--Lynn Arthur Steen, 1988 

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

Folks,

Thanks,
- Pasi

---

From: Pasi Sarolahti <[email-masked]>
Date: Tue, 17 Oct 2006 09:48:04 +0300

On Mon, 2006-10-16 at 10:17 -0700, [email-masked]
wrote:
> I like the basic taxonomy in section 2. You might consider presenting
> it in two stages (in-band vs. out-of-band, router support required vs.
> router support not required), and a table MIGHT be useful here. One of
> the first questions I found myself asking was to what degree are these
> characterisics orthogonal?

This sounds like a useful idea. I agree that a table would be useful.

>  A minor suggestion: When you write "The disadvantage of in-band
> signaling is that if some routers ...drop a packet...the accompanying
> data also gets lost..." (ellipses due to my laziness only!) I assume
> that the issue is that unkown options could cause routers to discard
> data when the data could otherwise have been successfully transmitted
> (though the signaling would be lost). Am I wrong here? Is it fair to
> say that in-band signaling involving only IP requires router
> involvement (short of dropping packets to signal congestion), and
> mechanisms relying on he transport protocol (TCP, UDP) do not? Why not
> make this explicit?

Yes, the main problem behind this is the observation that some nodes in
the network are known to drop packets with unknown IP options. That
specific problem is discussed in more detail later (section 4.3), but I
agree that the beginning of section 3 could maybe be more explicit about
this, and maybe have a forward reference to section 4.3.

> I wonder if it might be useful to trry to establish a cross-reference
> between the issues in section 6 and the mechanisms in section 4. for
> example, the issue in 6.3 seem to be an issue with in-band signaling.

Yep, our intention was to do this. One of the main goals here is to
document the problems that are known to be common for certain classes of
mechanisms.

> I'm not sure if this is even something that can/should be addressed in
> your I-D, but I believe the IETF is standardizing 802.1au which is an
> ECN like mechanism for sFrom [email-masked] Tue Oct 17 03:02:28 2006
Subject: Re: [Tsvwg] New I-D on cross-layer indications for transport protocols
From: Pasi Sarolahti <[email-masked]>
To: [email-masked]
Date: Tue, 17 Oct 2006 09:48:04 +0300
Cc: [email-masked], Sally Floyd <[email-masked]>

On Mon, 2006-10-16 at 10:17 -0700, [email-masked]
wrote:
> I like the basic taxonomy in section 2. You might consider presenting
> it in two stages (in-band vs. out-of-band, router support required vs.
> router support not required), and a table MIGHT be useful here. One of
> the first questions I found myself asking was to what degree are these
> characterisics orthogonal?

This sounds like a useful idea. I agree that a table would be useful.

>  A minor suggestion: When you write "The disadvantage of in-band
> signaling is that if some routers ...drop a packet...the accompanying
> data also gets lost..." (ellipses due to my laziness only!) I assume
> that the issue is that unkown options could cause routers to discard
> data when the data could otherwise have been successfully transmitted
> (though the signaling would be lost). Am I wrong here? Is it fair to
> say that in-band signaling involving only IP requires router
> involvement (short of dropping packets to signal congestion), and
> mechanisms relying on he transport protocol (TCP, UDP) do not? Why not
> make this explicit?

Yes, the main problem behind this is the observation that some nodes in
the network are known to drop packets with unknown IP options. That
specific problem is discussed in more detail later (section 4.3), but I
agree that the beginning of section 3 could maybe be more explicit about
this, and maybe have a forward reference to section 4.3.

> I wonder if it might be useful to trry to establish a cross-reference
> between the issues in section 6 and the mechanisms in section 4. for
> example, the issue in 6.3 seem to be an issue with in-band signaling.

Yep, our intention was to do this. One of the main goals here is to
document the problems that are known to be common for certain classes of
mechanisms.

> I'm not sure if this is even something that can/should be addressed in
> your I-D, but I believe the IETF is standardizing 802.1au which is an
> ECN like mechanism for signaling congestion in layer 2 switches.
> Wait...I see it at the end of 6.6 (layer 2 queues and operation
> logic).

I think it could be useful to mention this as one example of interaction
between L2 and upper layer mechanisms. I guess these need to be
evaluated on a case-by-case basis: 802.1au relates to congestion control
mechanisms, but not so much with the others (such as Path MTU discovery,
etc.).

Thanks, good comments.

- Pasi