TCP/IP работает сверху вниз или снизу вверх?

Рекомендую Олиферов почитать. Каждый уровень отвечает за свое. Вообще в стандартной модели ISO/OSI их семь, и обычно эту модель используют, когда говорят про уровни. Сетевой - это уровень 3, ни в какой транспортировке он не участвует, что он делает конкретно - читайте Олиферов и RFC. Ниже сетевого - канальный, он отвечает за фреймы Ethernet (если передача по Ethernet), еще ниже - физический - и вот он как раз отвечает за транспортировку. После транспортного идет уровень сеансовый - он практически нигде не используется сейчас, потом уровень представления - здесь работает SSL и потом уже уровень приложения.

Вся эта модель не более чем условность, нужно её рассматривать, как иерархию структур данных, а вовсе не незыблемые и скрытые друг от друга уровни. В некоторых случаях в направлении отправки пакета может учитываться даже прикладной уровень, а HTTP разбираться непосредственно из Ethernet-кадров. HTTP ничто не мешает содержать Ethernet кадры. NAT определяющий направление отправки по номеру порта TCP и UDP вообще уже стал обыденностью. Прикладных протоколов содержащих IP-адреса и порты, вообще не должно быть в OSI, так как не позволяет абстрагироваться, но их полно. И это вышло боком при появлении IPv6, а с другими протоколами сетевого уровня они вообще несовместимы и на это закрыли глаза. И весь этот бардак нынче зовётся сетевым стеком.
IP конечно содержит механизм фрагментации, но по причине неудачного проектирования используется редко и не для TCP. TCP изначально создан для фрагментации бесконечных потоков данных с проверкой факта доставки, поэтому влезает на сетевой уровень, чтобы знать MTU, а получив некоторые ICMP пакеты даже разрывать соединение(no route, unreachable). Удалённому узлу, TCP тоже сообщает свой MTU.

ip только указывает какому хосту этот пакет относится не более!

1) прикладной уровень (HTTP) использует TCP как сервис (а именно - какое-либо API, предоставляемое ОС, например сокеты Беркли) и выражает желание отправить некоторое количество данных в пункт Б; в теории объем данных может быть любым, т.к. задача именно TCP - разбить данные на куски и прилепить к ним свой заголовок. Полученные куски с заголовками называются TCP-сегментами; в этих заголовках есть все, что необходимо для обеспечения всех гарантий, которые даёт TCP, а именно: а) номер пакета для получения пакетов в порядке их отправления и возможности сборки отправленных данных; б) целостность пакетов и отсутствие в них ошибок; в) номера портов получателя и отправителя (чтобы несколько программ на одной машине могли обмениваться данными); г) флажки для обслуживания TCP-соединения. Вся суть TCP сводится к предоставлению вам, т.е. прикладному уровню, некоего надежного виртуального "провода", которым вы как бы подключили одну программу на одной машине к другой программе на другой машине. В терминах типов коммутации, TCP поверх IP - это коммутация каналов поверх коммутации пакетов.
2) После сборки каждого сегмента TCP использует уровень IP как сервис, и отдает ему сегменты для упаковки в пакеты. Уровень IP нужен для предоставления возможности закинуть (т.е. маршутизировать) любой пакет с текущего узла на любой другой в сети. IP не предоставляет никаких гарантий о порядке прихода пакетов на узел, и даже о том, что они вообще придут (IPv6 также не проверяет целостность пакета), однако с его помощью сетевое оборудование в состоянии выбирать различные (!) пути для доставки пакетов получателю и осуществлять эту доставку. В заголовке IP-пакета, как на письме, указан узел-отправитель и узел-получатель.
После сборки пакета оный отправляется на канальный уровень для доставки по конкретной физической среде.

Теперь представим, если бы этих уровней (TCP/IP) не было. Самое простое, работающее по такой схеме, что приходит на ум - передача данных по COM-порту между двумя машинами. В такой схеме вы, вероятно, получали бы данные в порядке их отправления и возможно даже имели бы контроль ошибок, НО:
а) только одно приложение могло бы передавать/получать данные, т.к. нет виртуальных соединений (нет мультиплексирования);
б) для передачи данных машины нужно соединять физически. Ну или сажать тётеньку, которая бы перетыкала провода, как на первых телефонных станциях с ручной коммутацией каналов.
IP избавляет вас от пункта б), TCP - от пункта а) и тех доп. проблем, которые добавляет IP своим присутствием.