Subject: Re: [dccp] Re: DCCP and draft-ietf-v6ops-v6onbydefault-01.txt

From: Eddie Kohler <[email-masked]>
Date: Wed, 14 Jul 2004 20:44:06 -0700

Hi all, responding to a longago mail:

First off, I think that DCCP is more like TCP than UDP.

Second off, I disagree with the draft's approach for TCP.  Maybe this 
discussion has already been had.

The -02 draft suggests, basically, that IPv6 Destination Unreachable is 
a hard error during connection setup, so that the application can cycle 
through different addresses.  It notes also that "TCP MUST NOT abort 
connections when receiving ICMP Destination Unreachable messages that 
indicate "soft errors"," according to RFC 1122.  These are in conflict.

But RFC 1122 also says that TCP "SHOULD make the information [about the 
soft error] available to the application".  This shows a way out of the 
conflict.  We can leave IPv6 Dest Unreach a soft error, like IPv4 Dest 
Unreach, while still supporting address cycling.  Simply specify that 
TCPv6 stacks SHOULD provide an API by which the application can request 
that soft errors end the connection right away (one form of 'making the 
information available').  This change is more incremental than the 
change currently proposed, and less invasive to the stack (no worries 
about SYN-SENT/SYN-RECEIVED state and so forth).

The text I've suggested for DCCP below takes this approach.

Also, an editing comment: the draft seems quite verbose.

Thanks for your solicitation,
Eddie

2.3.4  DCCP Implications

DCCP implementations should let applications request that "soft 
errors", including ICMP Destination Unreachable errors, be reported 
immediately.  Applications that can try multiple addresses to reach a 
given host SHOULD use this API to reduce potential transport-associated 
delay during connection setup.  Applications should generally turn off 
this API once a connection has been successfully initiated.

On Apr 23, 2004, at 1:14 PM, Aaron Falk wrote:

> I didn't see a response to this note.  Would someone like to draft 
> some text and circulate it by the list?
>
> THanks,
>
> --aaron
>
>
> On Mar 31, 2004, at 8:39 PM, Pekka Savola wrote:
>
>> Hi,
>>
>> draft-ietf-v6ops-v6onbydefault-01.txt has brought up some issues wrt.
>> handling of ICMP messages in transport protocols, in section 2.3.  The
>> document is in v6ops WG last call for Informational at the moment.
>>
>> I believe the situation with DCCP is quite similar to UDP:
>>
>> --------------
>> 2.3 Transport Protocol Robustness
>>
>>    Making the same set of assumptions as Section 2.2, regardless of 
>> how
>>    long the network layer takes to determine that the IPv6 destination
>>    is unreachable, the delay associated with a connection attempt to 
>> an
>>    unreachable destination can be compounded by the transport layer.
>>    When the unreachability of a destination is obviated by the 
>> reception
>>    of an ICMPv6 destination unreachable message, the transport layer
>>    should make it possible for the application to deal with this by
>>    failing the connection attempt, passing ICMPv6 errors up to the
>>    application, etc... Such messages would be received in the cases
>>    mentioned in Section 2 in which a node has no default routers and 
>> NUD
>>    fails for destinations assumed to be on-link, and when firewalls or
>>    other systems that enforce scope boundaries send such ICMPv6 errors
>>    as described in Section 3.1 and Section 3.3.
>> [...]
>>
>> 2.3.2 UDP Implications
>>
>>    As noted in [HOSTREQS] section 4.1.3.3, UDP implementations MUST 
>> pass
>>    to the application layer all ICMP error messages that it receives
>>    from the IP layer.  As a result, proper handling destination
>>    unreachability by UDP applications is the responsibility of the
>>    applications themselves.
>> -------------
>>
>> 1) is this being handled differently in DCCP?
>>
>> 2) would you like to propose text to describe the situation with DCCP?
>>
>> On behalf of v6ops WG,
>>  Pekka
>>
>> -- 
>> Pekka Savola                 "You each name yourselves king, yet the
>> Netcore Oy                    kingdom bleeds."
>> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>>

---

From: Pekka Savola <[email-masked]>
Date: Sat, 17 Jul 2004 11:32:16 +0300 (EEST)

Hi,

I also added tcpm WG to Cc: (as you already forwarded this on that 
list later).

As a status update, the TCP part has been put in a separate draft -- 
draft-gont-tcpm-tcp-soft-errors-00.txt.  What is the status wrt. the 
modification you propose in DCCP?

That is, in the IESG evaluation we received feedback that we cannot
publish this document with "solutions" unless the solutions have been
specified in the respective specification (e.g., DCCP drafts, etc.) --
and we'd have to reference them normatively (I think).

More inline on TCP and the genegic approach...

> about SYN-SENT/SYN-RECEIVED state and so forth).

It would indeed be possible to provide an API for the application to
act on the soft error information.  However, I think the application
still cannot ignore the SYN-SENT/SYN-RECEIVED state issues due to
security reasons (otherwise anyone could start aborting the ongoing
connections for those who use the API).

In other words, it would be possible to provide an API (e.g., a socket 
option that could be set) which would abort the connection if it 
receives a soft error in SYN-SENT/RECEIVED states.

Another alternative is to make the change by default, but provide the
identical API (e.g., a socket option) which would prevent the address
cycling -- because one could argue that address cycling is in most
cases a desirable thing to do, and this would be a better "by default"  
behaviour.  Most applications would want to set it in any case, and
doing it by default would achieve a better and easier "application
penetration".

All the approaches have their tradeoffs, of course.  This discussion
needs to be had, possibly in TCPM WG.

---

From: Eddie Kohler <[email-masked]>
Date: Sat, 17 Jul 2004 11:20:05 -0700

Long cc: list... :(

> modification you propose in DCCP?

The DCCP specs do not talk about network layer interactions like ICMP.  That is 
probably a new draft we'll eventually have to work on.

> receives a soft error in SYN-SENT/RECEIVED states.

This is trivial at the application level: simply turn off the "soft errors are 
hard" API once connect() has completed.  I think embedding SYN-SENT/RECEIVED 
knowledge in any kernel/user API is a bad idea.

> cycling -- 

This assumes that all address cycling will happen below the application, which 
is doubtful.

Eddie

---

From: Fernando Gont <[email-masked]>
Date: Sat, 17 Jul 2004 23:12:15 -0300

At 11:20 17/07/2004 -0700, Eddie Kohler wrote:

>>option that could be set) which would abort the connection if it receives 
>>a soft error in SYN-SENT/RECEIVED states.
>
>This is trivial at the application level: simply turn off the "soft errors 
>are hard" API once connect() has completed.  I think embedding 
>SYN-SENT/RECEIVED knowledge in any kernel/user API is a bad idea.

IMHO, requiring an application programmer more knowledge about networking 
and protocol specifics (soft and hard errors, etc.) is not a good idea.

I'd either ease his life, and provide him with a more abstract, 
higher-level API, or would fix things without bothering him.

>This assumes that all address cycling will happen below the application, 
>which is doubtful.

Not sure what you mean. As far as I can understand, Pekka is just 
discussing whether it'd be best for the "change" to kick in by default, or not.

He's still thinking about address-cycling being performed by the application.

Of course, if you provided application programmers with a higher-level API, 
all the soft errors and address cycling issues could be handled bellow the 
application.

--
Fernando Gont
e-mail: [email-masked] || [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Sat, 17 Jul 2004 23:05:43 -0300

>doing it by default would achieve a better and easier "application

And would not require changes in existing applications to achieve what is 
likely to be what most applications want to do.

---

From: Eddie Kohler <[email-masked]>
Date: Sat, 17 Jul 2004 21:02:47 -0700

Seems like these two comments are in conflict:

> IMHO, requiring an application programmer more knowledge about 
> networking and protocol specifics (soft and hard errors, etc.) is not a 
> good idea.
> He's still thinking about address-cycling being performed by the 

If the app cycles between addresses, then the app needs more knowledge about 
networking than most currently do.  The TCP option is incremental on top of 
address cycling.

> Of course, if you provided application programmers with a higher-level 
> API, all the soft errors and address cycling issues could be handled 
> bellow the application.

We agree!

Here's my proposal.

1. "Kernel" socket APIs for TCP are extended with an option that allows the app 
to specify whether "soft" errors should be treated as "hard".

2. A higher-level API is designed that handles multi-protocol DNS resolution and 
address cycling, and that calls the "kernel" socket API as appropriate to turn 
"soft" errors into "hard" ones during connection setup (_iff_ there are multiple 
addresses to try).  In pseudocode:

      open_socket_from_name(DNS_name) ::=
          get list of addresses;
          create socket;
          if (more than one address) {
              // Address cycling: first time through, treat soft errors as hard,
              // so cycling happens faster.
              make soft errors hard on socket;
              for (each address) {
                  try connecting to current address;
                  if (connect succeeded) {
                      make soft errors soft on socket;
                      return socket;
                  }
              make soft errors soft on socket;
          }
          // Second time through, treat soft errors as soft, to avoid failing.
          // Alternately might cycle through addresses a number of times until
          // some timeout occurs.
          for (each address) {
              try connecting to current address;
              if (connect succeeded)
                  return socket;
          }
          destroy socket;
          return connection failure;

This type of structure seems like the right thing for many apps, but not all. 
But there are a lot of potential parameters, and experience is required.  So you 
should only specify it in a library API.

Eddie

---

From: Fernando Gont <[email-masked]>
Date: Sun, 18 Jul 2004 05:47:52 -0300

At 21:02 17/07/2004 -0700, Eddie Kohler wrote:

>If the app cycles between addresses, then the app needs more knowledge 
>about networking than most currently do.

That's part of what I meant in my other post: Don't have applications do 
all these things, or they'll be working close to the network. Then whenever 
you want to change some protocol behaviour, it will likely affect the 
applications (which it shouldn't!).

>1. "Kernel" socket APIs for TCP are extended with an option that allows 
>the app to specify whether "soft" errors should be treated as "hard".
>
>2. A higher-level API is designed that handles multi-protocol DNS 
>resolution and address cycling, and that calls the "kernel" socket API as 
>appropriate to turn "soft" errors into "hard" ones during connection setup 
>(_iff_ there are multiple addresses to try).  In pseudocode:
>

That's one of the ways it could be implemented. And I think indeed proposed 
this in March, when Pekka triggered discussion on this in the TCPM WG list.
(As a refinement, in case all connection attempts are aborted due to soft 
errors, the last for() loop could cycle several times, imposing an 
API-defined delay between each connection attempt).

>This type of structure seems like the right thing for many apps, but not all.

Are you thinking about any specific application?

>But there are a lot of potential parameters,

Correct. That's why I said "just because it's more abstract it doesn't mean 
it will be less powerful" in my previous post.

>and experience is required.  So you should only specify it in a library API.

Now, back to the current scenario: We have one problem, only one API, and 
do not want all existing apps to have to be modified.

The long term solution (which would probably avoid future posible problems) 
would be that of having applications use a High-Level API. But there has to 
be some work-around before there's such a High-Level API. The proposed 
solution tries to solve the problem without bothering application programmers.

Thanks for your comments!

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 19 Jul 2004 15:45:08 +0200

Fernando Gont wrote:

...
> API, all the soft errors and address cycling issues could be handled 

This is so kind of blindingly obvious that I'm surprised we are
even discussing it as a matter of principle...

Apps in Java already assume that such problems (including the
minor matter of which IP version to use) are solved inside the
Java run time system. Many major middleware packages include an
abstraction layer that hides the network (the new XIO package
in the Globus grid toolkit is an example).

Whether we can standardize such an abstraction, or only make
recommendations, is another question.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 19 Jul 2004 21:46:11 -0300

>even discussing it as a matter of principle...
[....]
>recommendations, is another question.

That's precisely the point: don't make the Sockets API less abstract than 
it currently is, and don't bother programmers with stuff they shouldn't be 
required to know.
And propose the idea of a Higher-Level API, so that applications won't be 
influenced by changes in protocol specifics next time we're are faced with 
a protocol specific issue.

BTW, what do you think of the proposed solution?